The most unsettling part of this week's cybersecurity news is how little the person giving an instruction may need to understand about carrying it out.

AI is shortening the distance between intention and action. That is extraordinary when somebody wants to build a business, understand a problem or defend a system. It is frightening when somebody wants to steal, sabotage or extort.

The PHP security emergency now being discussed under the informal banner of “Black October” makes that tension difficult to ignore. My concern goes beyond a programming language. We have concentrated enormous amounts of our lives inside systems that promise convenience, while the tools for finding their weaknesses are becoming faster and more accessible.

Who carries the consequences when those systems fail? And will “AI did it” become the easiest explanation in the room?

What happened with PHP, and what “Black October” means

The dates matter. This article is dated 24 October in Australia; the emergency PHP fixes were released on 21 October 2026. PHP's official advisory identifies two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which can permit remote code execution without logging in. In ordinary language, that can mean an outsider making a vulnerable server run their code. PHP security advisory

The affected component is the PHP runtime, a shared foundation beneath many applications. Cloudflare says it observed attack traffic and deployed protective firewall rules before public disclosure. It also explicitly tells customers to patch despite those protections. Attempted exploitation, successful compromise and a precautionary shutdown are different events; they should never be casually counted as the same thing. Cloudflare's account of the response

There is a subsequent development too. On 23 October, PHP issued additional guidance about session upload progress and an unusual configuration-dependent execution risk. Administrators should consult that follow-up as well as the original patch notice. A headline saying “fixed” is a poor substitute for keeping up with the vendor's current advice. PHP's 23 October advisory

“Black October” is a label circulating around several incidents and disclosures, rather than an official finding that one AI campaign compromised the internet. Reporting and commentary have grouped different stories together. That makes it a useful description of the mood, but weak evidence of a common cause. The Atlantic's interview with PHP package maintainer Ondřej Surý

Intention used to need more expertise

For most people, wanting to do something technically difficult used to mean learning how, hiring somebody or finding a ready-made tool. Those routes still exist. AI adds an increasingly capable intermediary: describe an objective, let the system propose steps, and have it help carry them out.

That is the shift I find so significant. Somebody can have determination without having the technical competence that previously constrained what they could achieve. In some tasks, AI supplies part of the missing capability.

There is evidence beyond speculation. Anthropic's August 2025 threat report described a criminal with basic coding skills selling AI-generated ransomware and documented AI use in data theft and extortion. These are the provider's reported observations, not proof that every novice can compromise any target. Anthropic threat intelligence report

The UK's National Cyber Security Centre likewise says frontier AI makes sophisticated attacks easier, faster and cheaper for less-skilled actors. It also says defenders can benefit. That second point matters: the same reduction in effort can help people find and fix weaknesses. NCSC guidance on frontier AI

Calling this completely unprecedented needs care. Automation, exploit kits and criminal services lowered barriers long before conversational AI. What feels like a historical break to me is the flexibility: a general-purpose system can explain, adapt, write code and help coordinate work through an ordinary conversation. The operator's ambition can increasingly exceed their understanding.

That does not make expertise obsolete. It makes ignorance less reliable as a limit on harmful intent.

Centralisation turns one weakness into everybody's problem

There are different kinds of concentration. Millions of independently hosted websites can share the same vulnerable software. That is a common dependency, even when their data sits in separate places. A cloud provider, identity service, bank or exchange can introduce a different kind of concentration: many people relying on one operator or control plane.

These risks can overlap. Five applications may look independent while sharing a hosting account, administrator identity, recovery inbox or software dependency. The apparent separation disappears when that shared layer fails.

Centralised services can afford excellent security teams and respond quickly. Running everything yourself can introduce worse maintenance and recovery problems. I am not arguing that size automatically means insecurity, or that decentralisation magically prevents a breach.

I am arguing that convenience has encouraged us to accept too many connected points of failure. We should ask what one compromise can reach, what remains available afterwards, and whether recovery depends on the same account that has just been lost.

The uncomfortable question is not simply “Do I trust this company?” It is “How much of my life stops working if that trust is misplaced?”

What if your bank gets hacked?

Imagine opening your banking app and finding that it is unavailable. Your wages, bills and day-to-day payments depend on a service you cannot currently use. Even before the facts are clear, the disruption is personal.

A website outage, stolen customer records, compromised payment systems and fraudulent transfers are distinct possibilities with different consequences. A vulnerable public website does not establish that a bank's core ledger has been breached. The PHP reports do not justify claiming that any particular bank has lost customer funds.

But the hypothetical exposes an important weakness in how we talk about digital trust. Customers often learn about the architecture only after it fails. Until then, the brand, the app and the underlying systems all appear to be one reassuring service.

I would want concrete answers: Which systems were affected? Was information accessed? Were transactions altered? What services remain usable? What can customers do safely now? What evidence supports the explanation?

“An advanced AI attack” answers none of those questions by itself.

“AI did it” must not become an accountability escape hatch

AI can be part of a real attack. It can also become a convenient phrase that makes a familiar failure sound unavoidable.

A breach might involve an external attacker, a malicious insider, stolen staff credentials, a compromised supplier or several of those together. A legitimate account can be used by its owner or by somebody who stole access. Finding AI-generated material somewhere in the chain does not settle who initiated the compromise or which controls failed.

I would not assume an insider was responsible. I would not accept that possibility being dismissed just because AI appears in a press release either.

Accountability should follow evidence: access records, administrative actions, credential use, deployment history, incident timelines and independent investigation where warranted. Organisations should distinguish what they know from what they suspect.

The attacker remains responsible for choosing to attack. The organisation should still explain how it managed access, maintenance, detection and recovery. A supplier should explain its own role. Those responsibilities can coexist; the existence of a powerful tool does not erase them.

My position is simple: naming AI should make an incident explanation more specific, never less accountable.

The defensive AI contradiction

There is another frustration in this debate. You try to use an AI service to assess resources you own or are authorised to test, and it may refuse because the activity resembles something an attacker could do.

The underlying difficulty is real: much of security work is dual use, and a service cannot establish permission merely because somebody claims to own a target. But a blanket refusal can leave a small operator struggling to improve their defences while a determined attacker looks elsewhere.

Providers should offer workable routes for legitimate security research: clear scopes, verified authorisation where appropriate, controlled environments and useful explanations of what assistance is available. Refusal should not be the only product experience offered to people trying to protect their own systems.

That is my criticism of how access can work in practice. It is not a claim that every hosted model blocks every security assessment. The NCSC's guidance explicitly recognises AI-assisted defensive work, including vulnerability discovery. NCSC: frontier AI and defence

Why open models matter

Open-source and open-weight models offer another route for legitimate defenders. Where the model and licence permit local operation, an organisation can choose its infrastructure and keep sensitive material within its own environment rather than sending it to a hosted assistant.

Those labels are not interchangeable. Downloadable weights do not automatically make the entire system open source, and licences, acceptable-use terms and model safeguards still matter. Meta's Llama documentation, for example, provides downloadable models and hosting resources under its applicable licences. Llama model and hosting documentation

Local operation gives a defender more control over a workflow; it does not guarantee stronger reasoning, accurate findings or unrestricted output. It also creates work: securing the model service, maintaining it and checking its conclusions. A hallucinated vulnerability can waste time, while a missed one can create false confidence.

Even with those limits, I believe having a choice matters. Defensive capability should not depend entirely on the changing judgement of one remote provider. The NCSC's assessment also recognises that open models can lower barriers for both defence and attack. NCSC assessment to 2027

Do not put all your eggs in one basket

AI-generated editorial illustration for etech consulting: separate dependencies can limit the consequences of one failure. This is a conceptual image, not a depiction of a real incident or a guarantee of protection.

For me, the practical lesson reaches beyond software. Think about your data, money, crypto and other assets in terms of dependency and recovery. How much could one compromised account, device or organisation put out of reach?

For data, an independent backup and a tested restore process matter more than the number of cloud logos on the invoice. A backup that an intruder can erase through the same administrator account is still tied to the original point of failure.

For access, consider the recovery chain. Separate services offer limited independence when they all reset through one inbox or one compromised device. Strong, distinct authentication and carefully protected recovery methods are part of meaningful separation.

For money and payments, think about continuity as well as theft: what happens if a provider is unavailable when a bill needs paying? The appropriate arrangement depends on your circumstances. Opening more accounts without securing and monitoring them can create problems of its own.

For crypto, separate tokens do not necessarily mean separate custody risk. Several assets in one exchange account still depend on that account and operator. Self-custody changes the dependency, but introduces the possibility of lost keys, irreversible mistakes and insecure recovery. It is a trade-off, not an automatic safety upgrade.

The goal is manageable independence: enough separation to survive a failure, with a recovery plan you can actually use. Complexity that nobody understands can become another vulnerability.

An extraordinary time, with very human responsibilities

I am excited by what AI makes possible. More people can build, learn and solve problems that would previously have been beyond their reach. The same capability can serve intentions we would rather never see put into action.

The answer cannot be to pretend that skill barriers still protect us, concentrate everything for convenience, and then accept “AI did it” when something goes wrong.

We should demand evidence after breaches, usable tools for legitimate defence, and systems designed so one failure does not spread everywhere. We should also support the people maintaining the shared software on which those systems depend.

Black October may be the name people remember. I hope the lesson lasts longer: powerful tools do not remove human responsibility, and trust is stronger when it comes with a way to recover.

Sources and editorial note

Research checked on 24 October 2026, Australia/Sydney. This is an opinion article. The bank scenario is hypothetical; no specific bank compromise, insider involvement or loss of funds is alleged. Incident guidance can change after publication.

PHP: emergency security advisory and subsequent updates — authoritative PHP notices dated 21 and 23 October 2026.

Cloudflare: protections against php2shell — its account of mitigations, observed attack traffic and the need to patch.

The Atlantic: interview with Ondřej Surý — context for the “Black October” label and package-maintainer workload; some access may require a subscription.

Anthropic: detecting and countering misuse, August 2025 — provider-reported cases of AI-assisted cybercrime.

NCSC: frontier AI and its assessment to 2027 — capability, defensive opportunities and open-model considerations.

Meta: getting started with Llama — model access and hosting resources.

Both illustrations were generated with AI for this article. They depict concepts, not documented attacks.