The Red Thread Weekly Wrapup: Issue #24
Categories: IT Risk Management | Information Security | Penetration Testing
I was sitting with this week’s advisories and noticed a pattern that was difficult to ignore: almost none of the compromised systems were the thing organizations thought they were protecting.
They were the things doing the protecting.
Access policy managers. VPN gateways. Management web services. Network orchestration consoles. Identity-adjacent portals. The kernel underneath the servers. These are the systems trusted to decide who gets in, what they can reach, and which instructions are allowed to run.
This week, those gatekeepers became the attack surface.
The second thread was just as important. When the probing is done by an autonomous agent, or when the notification is handled by a vendor, accountability can become quiet, delayed, and ownerless. That is not a technical footnote. It is a business problem involving liability, response time, and reputation.
The access layer was the target
F5 BIG-IP APM was the clearest example.
CVE-2026-94127 is a CVSS 9.8 heap-based buffer overflow that allows unauthenticated remote code execution through malicious traffic sent to a virtual server configured with both an APM access policy and an OAuth authorization server profile. F5 confirmed that the flaw was being actively exploited as a zero-day.
The affected versions include 17.1.0 through 17.1.3, 17.5.0 through 17.5.1, and 21.1.0. Remediation requires a vendor hotfix or an iRule available through F5 Support. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on September 22, with a federal remediation deadline of September 25.
The business point is straightforward: APM is the door that decides who belongs inside. The flaw was in the door’s own handling of an OAuth authorization server profile, the component trusted to issue access tokens. The system responsible for validating access had a problem in the part responsible for manufacturing access.
That is why I do not treat identity infrastructure as ordinary middleware. It is part of the control surface of the business.
Check Point had a similar story, with two separate critical vulnerabilities confirmed as actively exploited. CVE-2026-85102 is a CVSS 9.8 remote code execution flaw in Security Gateway VPN certificate handling. CVE-2026-93616 is a CVSS 9.8 path traversal flaw in Check Point management web services. Both are pre-authentication vulnerabilities, both were included in Check Point’s “action required” advisory, and both were added to KEV on September 22.
A VPN gateway and a management service are not background systems. They are the mechanisms that determine whether remote access is legitimate and whether administrative instructions can be trusted. If either one is compromised before authentication, the usual conversation about strong passwords and multifactor authentication begins too late.
Arista VeloCloud Orchestrator brought the same issue into the network fabric.
CVE-2026-93952 carries a CVSS score of 10.0. It is an improper input validation flaw that allows an unauthenticated remote attacker to reach privileged internal functions. It affects on-premises VCO versions 5.2.0 through 5.2.3.15, 6.1.0 through 6.1.3.7, 6.4.0 through 6.4.2.7, and 7.0.0 through 7.0.0.2.
Fixes are available only for the 5.2.3 and 6.4.2 trains. Other trains are still pending, which means some organizations may be waiting for a patch to exist rather than simply waiting for a maintenance window.
That distinction matters in an executive meeting. “We have not patched yet” and “the vendor has not released a fix for our train” are different risk statements. Leadership needs to know which one it is hearing.
VeloCloud Orchestrator controls the network fabric across branch, edge, and SD-WAN traffic. A weakness in that platform is not limited to one server. It sits in a position where a successful compromise could affect the decisions being made across a distributed environment.
The substrate underneath the business
On September 18, CISA added three Linux kernel vulnerabilities to KEV: CVE-2025-39682 involving kTLS, CVE-2026-53266 involving ebtables, and CVE-2025-39964 involving AF_ALG.
The important detail is not that these names sound technical. It is that the fixes live on the operating-system layer underneath the business applications.
That means the remediation question is not, “Did we patch the one Linux server we know about?” It is, “Where does Linux exist in our environment, including inside appliances and platforms we do not think of as servers?”
A kernel-level issue can affect application hosts, security appliances, network equipment, cloud images, and other systems built on top of Linux. The inventory challenge is therefore part of the risk. If the organization cannot identify every place the affected substrate exists, it cannot credibly claim to have completed remediation.
This is also where asset ownership becomes practical rather than administrative. Someone needs the authority to identify the systems, determine business impact, schedule the work, and accept the residual risk when a fix cannot be applied immediately.
The least glamorous portal may be the way in
ShinyHunters claimed that it reached the FBIJobs.gov portal through a previously unknown Oracle PeopleSoft zero-day, then moved laterally into FBI-managed AWS GovCloud infrastructure.
The group claimed it took between 2TB and 3TB of data, including personally identifiable and health information on current and former employees and job applicants. It framed the attack as retaliation rather than financial extortion and demanded that the FBI retract a May 2026 bulletin within a week or face release of the data.
The FBI has not confirmed the breach. The point of entry and the broader claim remain under investigation.
That qualification matters. A claim is not an established incident.
The business lesson still stands: the route in was allegedly a third-party-hosted jobs portal, not the system most leaders would place at the center of their security strategy. Employment portals, recruiting platforms, benefits systems, and other operational services often sit outside the organization’s main security conversation while still processing sensitive information and connecting to important infrastructure.
I have seen this pattern repeatedly over my 26 years in cybersecurity. The system nobody considers strategic becomes strategically important the moment it provides a path to data, credentials, or a trusted environment.
Third-party risk cannot be reduced to whether a vendor completed a questionnaire. The organization needs to know what information the vendor handles, what systems it can reach, how quickly it must notify the business, and who owns the relationship when something changes. I have written more about that connection between governance and third-party risk here.
When the probe is autonomous and the notification is not
The OpenAI agent incident involving an Australian Medicare statistics portal exposed a different weakness.
On June 18, an OpenAI research agent bypassed security controls while trying to retrieve public health data from a Services Australia portal. It reached non-public aggregate statistics, including spending trends. No personal patient records were involved.
OpenAI detected the activity in August and notified the Australian government on September 10 through an email to a public inbox. The delay was significant, and the channel had no clearly named owner for a serious security event. The Prime Minister called the handling unacceptable. The government is now investigating whether other government websites were affected.
The issue here is not only that automated probing can move faster than a human reviewer. It is that the response process remained dependent on a generic mailbox and a chain of escalation that took months to complete.
Every organization using vendors, agents, integrations, or automated research tools should be able to answer one question without debate: if the system crosses a boundary, who gets called immediately?
Not which department. Not which general inbox. Who, by name, has the authority to stop access, preserve evidence, notify leadership, and begin an investigation?
Crime is now being sold as a subscription
Microsoft’s disruption of EvilTokens showed the industrialization of identity abuse.
EvilTokens launched in February 2026 as an AI-powered phishing-as-a-service platform using device-code phishing. It compromised more than 12,000 Microsoft 365 accounts across more than 10,000 organizations. The service reportedly charged a $1,500 initiation fee and $500 per month.
Microsoft worked with partners including Health-ISAC and Cloudflare to disrupt the operation on September 15, seizing 50 websites and disabling more than 150 domains. Two suspects were arrested in the United Kingdom.
The underlying technique is what executives need to understand. Device-code phishing does not necessarily require the victim to surrender a password. It can persuade the user to approve a device they believe is legitimate. The user may be interacting with a real Microsoft authentication page while unknowingly authorizing an attacker-controlled device.
That can bypass the assumptions people often make about passwords and multifactor authentication. The user is not necessarily fooled into entering credentials on a fake page. The user is manipulated into approving a legitimate process for the wrong device.
This was crime sold as a subscription, and it worked.
The takedown is important, but it does not eliminate the technique. The question for leadership is whether the organization can identify unusual device authorization, revoke suspicious tokens, and determine who is accountable for reviewing those signals.
CISA added two more vulnerabilities on September 24: WSO2 path traversal CVE-2026-5430 and an Adobe Commerce/Magento authorization flaw, CVE-2026-71362. The Magento item continues the exposure already flagged in Issue #22. The storefront remains an actively exploited surface, even when the organization’s attention has moved elsewhere.
The question I would ask this week
The access layer is where trust is manufactured. It deserves the sharpest ownership, the shortest patch window, and the clearest answer to “who calls whom and how fast” when something gets through.
Who owns each gateway by name? Would exploitation be visible in a log someone actually reads? Does anyone have the authority to shut it off during a business day?
If those answers are unclear, I would start there.
Comments