Black October? The Week AI Changed the Cybersecurity Conversation

So, apparently the internet had a rather terrible week

If you followed cybersecurity news in mid-October, you might have wondered whether the internet had decided to test everyone's incident-response plans at once. Critical flaws in widely used software, compromised cloud systems, malicious releases and concerns about autonomous AI agents appeared within days of one another. The UK's National Cyber Security Centre issued an urgent PHP warning, while Microsoft reported that attackers were using agentic AI to accelerate their operations. There was barely time for one security headline to settle before another arrived.

Timeline of selected October 2026 cybersecurity disclosures and incidents: Zeabur, OVHcloud, Railway, PHP, GitLab, Node.js, LiteLLM, Microsoft Storm-0940, eMudhra, US banks, and LiteLLM incident update.
Timeline: selected October 15–23 events and disclosures. Dates include incident activity and publication; GitLab’s 2014 reference denotes affected versions, not a confirmed introduction date.

The sequence started before October 21. Zeabur disclosed unauthorized access to cloud infrastructure on October 15; OVHcloud found that malicious binaries had replaced some official command-line downloads on October 19; and Railway identified an attack on October 20 that exposed a subset of stored customer secrets, prompting advice to rotate credentials. Then October 21 brought critical PHP vulnerabilities that could, under certain conditions, permit unauthenticated remote code execution. AI-assisted research contributed to the PHP findings, and the Node.js project also released fixes, including for a Brotli decoder flaw reported by OpenAI Codex Security researchers.

GitLab issued patches the same day for a maximum-severity remote-code-execution flaw affecting versions as far back as GitLab 7.0, released in 2014; that is the affected version range, not proof that the flaw itself dates to 2014. LiteLLM disclosed a credential-stealing release, later traced to an administrative key exposed in May and never revoked. Separately, weaknesses in eight eMudhra intermediate certificate keys led to revocations and browser trust measures; the company said those intermediates had issued no end-user certificates and announced its exit from the global SSL/TLS certificate business on October 22.

The AI dimension made the week harder to ignore. Microsoft attributed an AI-accelerated campaign using the ARTEX penetration-testing framework to Storm-0940, which it assesses to be a China-state-aligned actor; in some attacks, privileged cloud access was obtained in under three hours. Axios also reported that US banks had encountered unvetted third-party AI agents accessing customer accounts, sometimes apparently going beyond users' instructions. These were different incidents, not one coordinated attack. But taken together, they help explain why some observers have called this period 'Black October'.

Is it really Black October, or are we becoming exceptionally good at panicking?

Having read all that, one might be tempted to switch off the router, retreat to a lakeside cottage, and spend the weekend appreciating a system that still works perfectly well without an internet connection - a wood-fired sauna. Security researchers may instead be wondering what happened to their weekend. Neither response gets us very far without distinguishing a newly discovered vulnerability from a successful compromise. Some of the week's stories were disclosures followed by patches; others were breaches whose origins lay months earlier. LiteLLM's exposed key dated to May, and Microsoft's observed campaign began in September. Ten headlines in a week do not necessarily mean ten attacks began that week.

There is another possibility worth considering. What if part of this apparent crisis reflects how much better we have become at finding weaknesses? Think about the technological distance travelled since 2014. Software engineering, cloud computing and automated testing have advanced enormously, while much of today's infrastructure still depends on codebases developed over many years. Vulnerability research has always required human expertise, but AI can now help researchers navigate large systems, generate tests and investigate interactions that were previously expensive to examine. The PHP and Node.js disclosures provide concrete examples of AI-assisted security research, even though we should not assume that AI discovered every flaw in the week's news.

The complication is that this improvement works in both directions. An authorized penetration tester can use agentic AI to examine a system more thoroughly and quickly, while a malicious actor can use comparable capabilities to scale reconnaissance and exploitation. Microsoft's investigation into Storm-0940 shows this is already more than a hypothetical concern. One thing I have learned from discussions at GPT-Lab is that the distinction between white-hat and black-hat activity is not the tool, but the intention and authorization behind its use. AI does not choose which hat to wear. For researchers, this opens new ways to study complex software and new questions about verifying AI-generated findings. For service providers, it means that testing, patching and dependency management can no longer be occasional exercises performed just before an audit.

And this may be where the next challenge lies. AI can help security researchers examine edge cases and validate potential weaknesses faster, but its findings still need reproducible evidence and expert scrutiny. For industry, the bottleneck may no longer be only finding a flaw; it may be knowing where an affected component is deployed, deciding how urgently it matters and getting a reliable fix into production. Better discovery is genuinely valuable, provided the capacity to assess and repair what is found improves alongside it.

So where does this leave us?

At GPT-Lab, colleagues working on the EVIL-AI research project have been exploring how AI systems could be used for harmful or unauthorized purposes. From discussions around their research, I have come to appreciate how difficult it can be to investigate malicious behaviour responsibly, particularly when working within a lawful research environment where experiments must remain carefully controlled. This does not mean anyone anticipated the specific incidents of October 2026, but the broader concerns are becoming increasingly relevant. What interests me is the shift from AI as a system that finds or recommends actions to one that can carry them out. An agent may possess valid credentials and access legitimate tools while still behaving in ways its user never intended. The reports involving financial institutions raise this issue from the customer's perspective, while Microsoft's investigation illustrates how permissions already granted to trusted applications can be exploited by attackers.

The banking reports and Microsoft's campaign should not be treated as the same kind of threat. In one case, the question is whether a third-party agent follows the account holder's intentions; in the other, Microsoft describes a hostile actor abusing access that a trusted application already possessed. Both illustrate why authentication alone is not enough. A valid token may prove that software can connect to a system, but it does not settle whether each action it takes is appropriate. If agents can investigate and act at machine speed, the controls around their authority must be able to keep up.

This puts responsibility back on those who design and operate services: limit permissions, review what agents are authorized to do, rotate exposed credentials, protect release pipelines and make security testing continuous. We also need to be precise about the evidence: a disclosure is not automatically an attack, and legitimate access is not automatically legitimate behaviour. Perhaps the internet has accumulated a considerable amount of technical debt, and AI is now becoming remarkably good at examining the bill. But as AI gains the ability to act as well as inspect, the question becomes sharper: who has the authority to use that capability, what stops it from exceeding that authority, and how quickly can we fix the weaknesses it finds?

References

Security incidents: Zeabur | OVHcloud CLI | Railway | LiteLLM

Software advisories: UK NCSC (PHP) | OpenAI (PHP) | Node.js | GitLab

Digital trust and AI: eMudhra incident | eMudhra announcement | Microsoft / Storm-0940 | Axios / banking agents | GPT-Lab EVIL-AI

About the author

Navneet Arora

Project Researcher

Scroll to Top