The Red Thread Weekly Wrapup: Issue #23
Categories: IT Risk Management | Information Security | Penetration Testing
I was reviewing this week’s incidents and kept coming back to the same question: who authorized the path?
Nothing here required a novel exploit. Each incident ran through an access route that someone deliberately built to be open. An API was designed to answer requests. A legal-request process was designed to comply. A CDN key was created to serve content. A plugin system was designed to update automatically. An identity platform was built to grant access.
The leadership question is not simply, “Was it patched?” It is more useful to ask who authorized the path, how broad the access is, whether anyone would know it was used, and how quickly the organization could shut it off.
That distinction has held up across every incident I have reviewed this week.
Cisco ISE: the identity gate became the door
Cisco disclosed CVE-2026-76460 this week, a critical authentication-bypass vulnerability in Cisco Identity Services Engine and ISE-PIC. The flaw carries a CVSS score of 10.0, is under active exploitation, and allows an unauthenticated remote attacker to reach the web-based management interface through a crafted API request.
Cisco says successful exploitation may provide root-level command execution. There is no workaround. Patching is the required fix.
The fixed releases are Cisco ISE 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7, and 3.5 Patch 4. Version 3.0 is out of support and has no fix, which turns a technical vulnerability into a replacement or migration decision.
Cisco’s advisory and the active-exploitation reporting deserve immediate attention from any organization running ISE or ISE-PIC. Cisco also advised reviewing access.log files on every node for suspicious usernames. If malicious activity is suspected, the guidance includes re-imaging nodes and restoring from backup because an attacker with root access may be able to remove evidence.
The business impact is larger than one compromised appliance. ISE is the policy brain that decides which devices and users may reach which network resources. It is an enforcement point for Zero Trust. Root access there is standing authority to move through everything downstream.
This is also the fourth September flaw involving root-level access to a management plane, following Cisco FMC, Cisco Secure Email Gateway, and Check Point SmartConsole. I do not treat that pattern as a reason for panic. I treat it as a reason to ask whether management interfaces are isolated, monitored, and included in emergency response plans.
CenterPoint Energy: the API answered too many questions
CenterPoint Energy confirmed in a September 14 SEC filing that an unauthorized third party obtained customer personal information through an external-facing system. The company serves approximately seven million metered customers and reported roughly $9.3 billion in revenue.
A threat actor claimed to have obtained 7.49 million records by iterating through millions of IDs on a public API. Reports described names, phone numbers, service and billing addresses, account numbers, billing amounts, and partial Social Security numbers. The reported exposure window ran from August 17 through September 1.
The company has confirmed the unauthorized access, while the exact record count and technical details remain tied to the attacker’s claims and independent reporting. CenterPoint has said electric and gas service was not affected and does not expect a material financial impact.
The important point is not whether the final number is 7.49 million or materially lower. The important point is that the endpoint was designed to answer requests at scale, and nobody had asked whether it should still do that.
An API that lacks effective authorization, rate limiting, anti-automation controls, and appropriate monitoring can become a data extraction service. A web application firewall may help, but it cannot compensate for an access model that assumes the requester is entitled to every record they can enumerate.
This is where data governance and third-party risk become practical rather than administrative. I need to know what information the API exposes, why the API exists, who owns it, how access is logged, and how quickly the organization can disable it without disrupting essential services.
My data governance framework and third-party risk article goes deeper into the connection between data classification, vendor access, monitoring, and offboarding. The same discipline applies to internally built interfaces. If an organization cannot identify the data behind an endpoint, it cannot make a defensible decision about its risk.
Revolut: a legal request is a privileged access path
Attackers reportedly impersonated a government agency and sent fraudulent legal or law-enforcement requests to Revolut Bank UAB, its Lithuania-based subsidiary. The requests were processed for approximately five months before the fraud surfaced.
Approximately 680 customers, reportedly high-value crypto account holders, had passports, email addresses, phone numbers, and financial information exposed. A threat actor later demanded $3 million and threatened to sell the data, although Revolut says it has not received direct contact.
The reported initial access involved a government employee’s compromised email account, reportedly obtained through an infostealer. Researchers identified more than 300 compromised credentials associated with the relevant ministry domain, and a related campaign allegedly extracted data from an Italian law-enforcement agency.
The broader lesson does not depend on the final forensic details. A legal-request intake process is a privileged access path. It is authorized to release customer data, operates on the assumption that the requester is legitimate, and may be trusted precisely because it appears official.
A valid government domain is not proof that a request is valid. Email authentication can confirm where a message came from without proving who authorized it. A process that releases sensitive records should require independent validation, appropriate approval levels, a clear record of what was released, and retained evidence supporting the decision.
I would ask any executive team a simple question: could you produce a reliable log of every customer record released through legal or regulatory requests last quarter? If the answer is no, the problem is not merely email security. It is governance.
Brevo: the vendor sat between the company and its customers
On September 14, attackers used a compromised, long-lived Cloudflare API key to deploy a malicious Worker through Brevo’s CDN environment. The Worker injected ClickFix scripts into content delivered through the edge, affecting more than 100,000 customer websites for approximately five and a half hours.
The attackers did not need to alter Brevo’s origin servers. They used the vendor’s trusted position between the origin and the visitor to rewrite what people saw in transit. Some visitors received fake Cloudflare verification pages instructing them to run malicious commands. Logged-in WordPress administrators were also targeted with an attempt to install a persistent backdoor plugin.
Brevo revoked the credentials, purged edge caches, removed attacker-controlled content, and removed the hardcoded key from source code. Those actions contained the immediate problem. They do not remove the governance question.
A marketing or email vendor is not a peripheral relationship if it can alter content, execute code, or place a script in front of customers. I would want to know which vendors can change customer-facing content on my behalf, whether their keys are scoped, how long those keys live, how they are rotated, and whether their use generates an alert.
Plugin4Shell: auto-update is also an execution path
Plugin4Shell is a zero-click remote code execution flaw affecting the plugin workflows of Claude Code, OpenAI Codex, GitHub Copilot, and Gemini CLI. The issue is not that these tools use plugins. The issue is how they verify that the installed plugin is the code that was approved.
The agents check out a pinned Git commit but do not adequately verify that the working directory contents match the expected pin. An attacker who controls a repository can manipulate Git references or branch names to cause malicious code to execute while the marketplace still appears to point to a trusted commit.
Because plugins may update in the background, a compromised plugin can be enough. No user action is required to approve the malicious change.
Claude Code fixed the issue in version 2.1.179, and Codex fixed it in version 0.146.0. Gemini CLI is deprecated and has no patch; users are directed to migrate. GitHub Copilot remains unpatched in relevant configurations.
Developer tooling now carries the same trust profile as production infrastructure when it can access source code, secrets, cloud credentials, or deployment systems. Automatic updates are not inherently unsafe, but they are execution paths. Someone must decide what is trusted, what is verified, and what happens when verification fails.
The KEV list is an authority signal
CISA added three relevant vulnerabilities to its Known Exploited Vulnerabilities catalog on September 16.
Cisco ISE CVE-2026-76460 is the most consequential for organizations using identity infrastructure. Acronis Backup CVE-2026-87886 is a local privilege-escalation flaw affecting the cPanel and WHM plugin and Plesk extension. A single phished hosting account combined with that escalation could expose backups and workloads across tenants. Limited targeted exploitation has been reported.
Google Pixel CVE-2026-58704 is a permission-bypass vulnerability requiring no user interaction and is reportedly under limited targeted exploitation.
A KEV listing is not just another item in a vulnerability dashboard. It is a signal that the access path is being used in the real world. I would expect a named owner, a remediation decision, evidence of completion, and a documented exception if the fix cannot be applied immediately.
The through-line this week is simple: trust is not the problem, but unaudited authority is. Every open API, legal-request channel, vendor key, automated update, and identity platform creates a path someone can use.
The right leadership questions are who authorized the path, how broad it is, whether its use would be visible, and how quickly it can be shut off. If you are reviewing those trusted access paths, I am open to comparing notes.
Comments