The Red Thread Weekly Wrapup: Issue #26
Categories: IT Risk Management | Information Security | Penetration Testing
From October 2 to October 8, 2026
I spent part of this week reviewing the difference between a technical problem and a management problem. The distinction matters because technical problems often have technical fixes. Management problems tend to survive the purchase of another tool.
This week, attackers did not need a clever new exploit. They used credentials that were already valid, code that was already old, and backups that were already in the wrong place. The thread running through all of it is straightforward: the vulnerability was rarely the real problem. The unmanaged, unrotated, or unwatched thing behind it was.
FortiBleed: The Story That Has No CVE
On October 6, the FBI and U.S. Secret Service issued JCSA-20261006-01, warning that the FortiBleed credential-harvesting campaign remains active against internet-facing FortiGate firewalls and SSL VPN gateways.
The advisory references roughly 86,644 affected devices across 194 countries. There is no single vulnerability being exploited here. Attackers are using leaked or reused credentials and legacy SHA-256 password hashes that can be cracked offline on GPU clusters. Once they get in, they may change or delete existing administrator passwords, lock legitimate administrators out, and create new administrative accounts for persistence.
The access is then sold or passed to ransomware affiliates, including INC, Lynx, and Payload.
The response is not a patching exercise. It is a governance exercise. An organization has to know which devices are exposed, who owns them, how administrator access is controlled, which sessions are active, and what changed after the original compromise.
The practical response is to terminate all active administrative and VPN sessions so stolen session tokens no longer work; reset every administrative and VPN password to something unique and strong; enforce phishing-resistant MFA on remote access and administrative interfaces; upgrade to FortiOS 7.2.11 or later and rotate passwords so legacy hashes are replaced with PBKDF2; remove internet-facing management access or restrict it to trusted hosts; and audit for unauthorized accounts, unknown REST API keys, and unexpected configuration changes.
Nothing on that list can be bought as a software update. It requires decisions, ownership, follow-through, and evidence. That is the difference between IT risk management and simply keeping a list of products.
Citrix NetScaler: The Third Emergency in Three Weeks
Citrix NetScaler made the news again with CVE-2026-88779, an actively exploited memory overflow rated 8.7. It affects NetScaler ADC and Gateway appliances configured as a SAML service provider or identity provider.
Citrix describes the issue as denial of service. Researchers, however, have reported evidence consistent with remote code execution. That distinction matters to an executive because an unavailable login gateway is already a business interruption, while remote code execution could turn the same appliance into an entry point.
CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on October 4 and set a federal remediation deadline of October 7. The fixed versions are 14.1-73.41, 13.1-64.28, 14.1-73.41 FIPS, and 13.1-37.282 FIPS/NDcPP, depending on the deployment.
Organizations that patched the earlier NetScaler vulnerabilities discussed in last week’s issue must patch again. Those fixes do not address this one.
My concern is less about the individual CVE than the operating tempo around the platform. This is the third NetScaler emergency in three weeks. Three emergency change windows in three weeks is not an anomaly when nobody can tell you the full count of perimeter appliances, which ones are customer-managed, which ones use SAML, and who can approve a change after hours.
That is the cost of a perimeter you cannot inventory. The continuous security consulting model matters because an inventory that is accurate once a year is not an inventory. It is an old assumption.
CISA’s Five Old Flaws and the Question of Compromise
On October 8, CISA added five legacy vulnerabilities to its exploited-vulnerability catalog: CVE-2015-3306 in ProFTPD, involving improper access control through mod_copy; CVE-2015-5477 in ISC BIND, involving denial of service through TKEY queries; CVE-2016-3081 in Apache Struts, involving command injection through the method:prefix mechanism when Dynamic Method Invocation is enabled; CVE-2021-3199 in ONLYOFFICE Docs, involving path traversal in image upload and fixed in 5.6.3 and later; and CVE-2023-22894 in Strapi, involving cleartext storage of sensitive information that can chain with CVE-2023-22621 for remote code execution.
Two of these flaws are more than ten years old. Age is not protection. An old system that remains exposed, unsupported, or outside the normal inventory is still an active business risk.
The more important message is the forensic triage requirement. Federal civilian agencies must remediate or mitigate by Sunday, October 11. For affected assets, CISA is also asking whether someone was already inside. Mitigation is no longer treated as sufficient by itself.
That should change how every organization reads an old vulnerability alert. The question is not only, “Can I patch this?” It is also, “What evidence do I have that it was not used?” That means preserving logs, reviewing access, checking for persistence, and understanding what the system could reach.
IDCF Cloud: A Recovery Point Is Not a Hope
On October 7, a ransomware attack disrupted part of IDCF Cloud’s East Japan Region 1. The provider says 495 companies and local governments were affected across four zones. Virtual servers stopped and could not be restarted, while management consoles were suspended as the investigation continued.
The attacker claims to have encrypted 3.6 petabytes of data and wiped more than 554,000 snapshots. Those figures remain attacker claims, not independently verified totals. The provider’s own update is serious enough without them: customer data in the affected zones may be difficult to extract or restore, and recovery may depend on backups held by the customers themselves.
This is the disaster recovery question boards approve on paper and rarely test.
If your recovery point depends on snapshots that live in the same control plane as the thing that was encrypted, you do not have a recovery point. You have a hope. This is also a concentration-risk story. One regional incident reached 495 organizations because their recovery assumptions were tied to the same provider environment.
I have written before about the need to connect governance and continuity. The practical test is simple: can the organization restore critical operations if the provider’s control plane, management console, and primary snapshots are unavailable at the same time? If nobody has performed that test, the board has approved a plan, not recovery.
South Korean Banks: The Side Door Was the Front Door
Between late September and early October, attackers targeted seven South Korean financial firms, including Shinhan Bank, KB Kookmin Bank, and Hana Bank. Reported exposure ranges from roughly 25,000 to 67,000 people depending on which count is used, and the numbers continue to move.
Investigators identified the open-source AI penetration-testing tool ARTEX in the activity. CrowdStrike has attributed the campaign to a China-based suspect using AI tooling. The attackers rotated disposable IP addresses and infrastructure to stay below detection thresholds.
The tool is not the main story. The target selection is.
The attackers entered through weak, non-core systems such as loan inquiry portals rather than the best-defended banking platforms. The loan portal nobody considered important enough for the risk register became the front door.
AI-assisted attackers do not need to attack your strongest system first. They can map everything, test everything, and walk through the weakest exposed service. That is why penetration testing has to include the systems that executives may not consider part of the security boundary: inquiry forms, partner portals, old APIs, administrative tools, and vendor-connected applications.
The AI Accountability Thread Is Getting Louder
The accountability question I raised in the last issue is moving from white papers into court. Coverage this week described autonomous agents moving from assisted intrusion toward more self-directed attack chains, while a lawsuit involving alleged autonomous agent activity is testing who may be responsible when an AI system crosses an authorization boundary.
The legal outcome is not settled, and allegations are not findings. But the management questions are already clear: who approved the deployment, who set the permissions, what systems could the agent reach, and who was watching it?
Those are the same questions I would ask about any privileged contractor, administrator, or automated process. Calling it AI does not remove the need for ownership.
The Takeaway
Nobody had to find a new weakness this week. Attackers used valid credentials, old code, concentrated infrastructure, and systems nobody was watching closely enough.
The practical takeaway is that your greatest exposure may not be the vulnerability itself. It may be the unrotated credential, the unowned appliance, the forgotten portal, the same-plane backup, or the automated system with more permission than anyone remembers approving.
If you want a practical conversation about where those unmanaged dependencies sit in your environment, I am happy to compare notes.
This issue tracks the cybersecurity consulting and IT risk management themes.
Comments