The labs making software easier to break are also selling the tools to defend it. This month’s security incidents show why that business model deserves scrutiny—and why the answer cannot be another black box with a bigger API bill.
There is an awkward sales pitch taking shape in the AI industry: the models are becoming powerful enough to find the cracks in your infrastructure, so you should probably use the models to help seal them.
I call the resulting bill the AI security tax. It includes more than a subscription. It is the engineering time, inference spending, emergency patching and operational complexity required to keep up with machines that can investigate software continuously. Small teams pay it in nights and weekends. Large organizations pay it through another layer of security infrastructure.
October’s incidents make that prospect concrete. They also make it easy to tell a story that is too neat: one global AI attack wave, one foreign culprit, one vendor with the cure. The evidence supports a more interesting argument. Old bugs, compromised trust, stolen credentials and increasingly capable agents are interacting. They do not all have the same cause.
Reporting checked on 24 October 2026. This is an analysis of the major incidents and Linux vulnerability families relevant to this wave, not an exhaustive catalog of every Linux CVE. Dates below distinguish original disclosure from renewed attention. Incident details and vendor patch status can change.
A crowded month, several different failures
On 21 October, PHP shipped emergency fixes for two unauthenticated remote-code-execution flaws: CVE-2026-109618 and CVE-2026-109619, both rated 9.2. One involves memory corruption during out-of-memory handling; the other involves stale request state. These are runtime problems, so fixing application code alone is insufficient. CERT-EU’s advisory sets out the affected branches and the urgency.
There is a documented AI connection here. OpenAI says Calif used GPT-5.6 Sol in the research, while Wiz independently reported both flaws. PHP’s maintainers led the fixes and release. Credit belongs to that coordinated human-and-model effort, not to a chatbot acting alone.
The first fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Distribution vendors may backport fixes under different package versions. Importantly, CERT-EU updated its advisory on 23 October to add CVE-2026-115560, a third RCE issue involving an unusual configuration. PHP considered that risk unlikely and did not schedule an emergency release; the advisory provides an interim mitigation. A story frozen on Wednesday’s patch announcement would already be incomplete. Check the official PHP releases and the current vendor guidance.
The Linux story is bigger than one scary headline
The newest critical kernel reports deserve attention. Slovakia’s CSIRT warned on 23 October about publicly exposed vulnerability reports, including two KSMBD file-server issues rated 9.0: ZDI-CAN-33549 and ZDI-CAN-33774. Their prerequisites differ: one involves SMB Direct/RDMA; the other concerns protocol dispatch and has a write path tied to share access. Exposure depends on the service and configuration actually in use. ZDI’s own inventory confirms the identifiers and scores.
At the advisory’s publication, those two reports did not have CVE identifiers. That distinction matters. A critical issue does not become harmless while it waits for a CVE, and a critical score does not establish that every Linux machine is exposed. Administrators should restrict affected service access and track their distributor’s actual fix status.
There is also a critical assigned CVE in the recent Linux discussion: CVE-2025-39682, a kernel TLS receive-path flaw. NVD lists a 9.8 score and a CISA known-exploited reference. It was originally published in September 2025, rather than first discovered this October. Red Hat assesses its products differently, illustrating why a universal score and a vendor’s practical exposure assessment can disagree.
Those are only part of the relevant Linux picture:
Copy Fail — CVE-2026-31431
AI-assisted discovery of a kernel page-cache flaw, publicly disclosed on 29 April. It enables local privilege escalation on affected kernels. A remote attacker still needs an initial route to local execution. Researcher disclosure.
Dirty Frag / Fragnesia — CVE-2026-43284, CVE-2026-43500, CVE-2026-46300
Related page-cache privilege-escalation issues disclosed in May. Networking components and configuration affect reachability; Microsoft’s investigation distinguishes observed activity from unconfirmed exploitation of individual variants. Microsoft investigation.
CrackArmor
Nine AppArmor vulnerabilities, represented by eleven patch-level CVE identifiers. Ubuntu documents local-user prerequisites and differing impact across releases, including policy bypass and privilege escalation. Ubuntu’s full matrix.
The networking quartet — DirtyAH6, TUNderflow, PPPoEject, DiagSpill
CVE-2026-80844, CVE-2026-81000, CVE-2026-68121 and CVE-2026-74469. September reporting describes local-root paths with different namespace, capability and module requirements. Red Hat bulletin.
Vghost — CVE-2026-74580
A vhost flaw that can permit local privilege escalation, with VM-escape risk in particular configurations. Tencent’s advisory explicitly says its checked CVM environment was not exposed to the VM-escape path. Tencent advisory.
Other kernel paths — CVE-2026-53266, CVE-2025-39964
The first concerns ebtables SNAT under specific bridge rules; the second concerns concurrent AF_ALG writes. Their requirements and consequences differ. SNAT assessment; AF_ALG assessment.
The practical lesson is to distinguish remote entry from what happens after entry. A local-root vulnerability can be devastating on a shared server, build runner or agent host, even when it does not let an arbitrary internet visitor log in. An application flaw or stolen account can supply the initial foothold. Treating every kernel headline as a universal remote takeover obscures the systems that actually need attention first.
The padlock can fail without the encryption breaking
The certificate incident is a different kind of failure. Mozilla says it received a report on 17 October that private keys for eight eMudhra intermediate certificates had been compromised. An attacker able to intercept a connection could potentially use fraudulently issued certificates to impersonate a site. Mozilla blocked the affected certificates through OneCRL that evening and later updated Firefox and its trust-store components. Its response also records a follow-up Android fix.
A certificate authority’s signing key is an authority to vouch for identities. Compromising it attacks that trust decision. It does not mean that someone has mathematically defeated TLS encryption. Nor does Mozilla’s account establish that an LLM caused the compromise.
OpenSSL issues belong in this picture too, but should not be confused with the CA incident. Its September advisory set includes X.509 extension handling, certificate-processing resource exhaustion, QUIC and other cryptographic-library defects. The OpenSSL advisory index separates affected versions and severity. A malicious certificate can expose a software bug even when the certificate should never be trusted.
Node.js’s 21 October security release brings these layers together: it updates the bundled CA material for eMudhra and fixes independent DNS, TLS hostname-verification and other runtime problems. A Brotli decoder flaw, CVE-2026-111497, could permit memory corruption and remote code execution when an application processes attacker-supplied compressed data; the project credits OpenAI Codex Security researchers. Node’s security notice rates its most severe issues High. The published fixed releases are 26.12.1, 24.22.1 and 22.23.4. Official release archive.
API keys are becoming a strategic resource
The LiteLLM compromise makes the credential problem particularly tangible. The malicious 1.107.0 package reached public registries on 21 October. Microsoft found Python-startup hooks that could activate a credential collector without an application explicitly importing LiteLLM. Model-provider keys were part of a much broader target set that included developer and cloud credentials. Removing one package is therefore not equivalent to restoring trust in the machine. Microsoft’s investigation explains the exposure and recovery implications.
LiteLLM’s own later investigation traces the upstream compromise to an exposed master key that was not revoked, followed by access to powerful developer credentials and the release process. It also reports a focus on obtaining upstream inference API tokens. The canonical incident account corrects some early assumptions. It is a reminder to follow the investigation, not preserve the first explanation that went viral.
An AI credential can now buy more than a fraudulent cloud bill. It can buy reasoning, coding assistance and a place to hide another operator’s activity. If access is resold, the legitimate account holder may bear costs and enforcement risk while someone else uses the capability. Exactly who bought a particular stolen key, and what they used it for, still requires evidence.
What the evidence says about Chinese labs
There is a documented basis for concern about unauthorized distillation. In its September report, Anthropic describes campaigns it attributes to China-based labs and explains how proxy services can use fraudulent accounts, stolen payment details and stolen API credentials to supply access. The same report describes malicious AI-assisted operations by several kinds of actors, not a single national group. These are Anthropic’s attributed findings, rather than an independent verdict about every alleged participant. Read the threat report.
OpenAI’s 30 September disclosure attributes a core cluster of a reasoning-extraction campaign to individuals associated with Moonshot AI. Crucially, it says that campaign did not break encryption, compromise a database or directly access stored user conversations. Its mechanism was manipulation of model interactions. OpenAI’s account should not be retold as a different kind of breach.
The NSA, FBI and CISA also issued a joint September warning about industrial-scale distillation by China-based AI companies. The government advisory announcement establishes that this is a serious, publicly documented concern. Distillation itself remains a legitimate training technique; the questions are authorization, access and how the data was obtained.
My assessment: stolen inference credentials and unauthorized distillation are a credible part of the threat economy. The sources above do not establish that Chinese labs orchestrated the PHP bugs, the eMudhra key compromise, the KSMBD disclosures or the LiteLLM attack. Connecting those events into one campaign would require evidence linking operators, infrastructure or the use of stolen credentials. Shared incentives are a reason to investigate, not a substitute for attribution.
When the other side can run a swarm
The important shift is economic. A model can inspect code, propose tests and help investigate the result. Put it inside a tool-using agent and it can repeat that loop. Put many agents in parallel and an operator can explore several hypotheses at once. That does not make every attempt correct or every target vulnerable. It makes sustained investigation cheaper.
There is a concrete defensive example in OpenAI’s 23 October containment report. The company describes fleets of agents testing purpose-built copies of its infrastructure, with source and configuration access, monitoring and scoped objectives. It reports VM-escape and isolation findings, plus work on kernel issues including CVE-2026-74753, CVE-2026-80521 and CVE-2026-80841. These controlled experiments are not evidence that an unsupervised public bot can breach any server. They show why defenders are taking sustained machine-assisted testing seriously.
For a small operator, this changes what being uninteresting buys you. Obscurity is weaker when checking another host costs little. The attacker can keep trying while your team is doing its actual job. The defensive response needs to shorten the path from a credible signal to a verified fix, rather than merely generate more alerts.
Useful defensive agents need boundaries
In my view, the first useful security agent is a meticulous investigator. It maps deployed software and reachable services, connects advisories to the actual environment, and produces evidence a maintainer can act on. A second role is testing a proposed fix in a disposable environment. Neither needs unrestricted production credentials.
The adoption sequence should be deliberate:
- Observe: collect inventory, versions and logs using narrow, read-only access.
- Verify: establish whether the vulnerable code path is present and reachable. A version string alone may miss a distributor’s backport.
- Test: reproduce and validate in a controlled copy, with budgets and scope enforced outside the model.
- Change: require approval for consequential production actions, then use a staged rollout and a tested rollback.
- Measure: check the running system, retained evidence, service health and whether exposure actually decreased.
Logs, tickets and repository files can contain attacker-controlled text. A defender that treats that text as authority can become another attack surface. Limited identities, isolated tools, restricted network access and independently enforced action rules matter even when the model sounds confident. Faster reasoning does not make broad permissions safer.
The lab sells the capability. Then it sells the shield.
This is where the business model becomes uncomfortable. The same companies developing capabilities that can lower the cost of attack are positioning those capabilities as essential defensive tools. Customers can end up paying an ongoing bill to manage a risk that the product category itself is accelerating.
There is a real commercial structure beneath that concern. Anthropic’s Glasswing announcement committed up to $100 million in model credits and $4 million in donations to open-source security organizations; it also described paid usage after the preview support. In October, existing Glasswing members were moving into the expanded Cyber Verification Program. The program page is both a serious defensive initiative and part of a market for advanced security capability.
Calling this an AI security tax does not require claiming the labs invented decades-old bugs or deliberately organized attacks. It identifies an incentive: as powerful models spread, demand for model-assisted defense can grow, and the capability providers can capture that spending. The public should be able to scrutinize access restrictions, pricing, safety claims and the evidence that the promised protection works.
There is a fair counterargument. Defensive research can turn a temporary discovery advantage into permanent public patches, including fixes that protect people who never buy a model subscription. That benefit is real. It argues for judging the industry by deployed fixes and safer defaults, rather than treating either fear or optimism as sufficient evidence.
The bottleneck is everything after discovery
Models can produce findings faster than maintainers can necessarily review them. Anthropic’s disclosure dashboard, in its explicitly dated 2 October snapshot, reported 6,157 disclosed findings across 591 projects and 516 known upstream patches. The dashboard warns that counts have different validation stages and that a patch count does not show how widely fixes have been installed. Its methodology matters as much as the headline number.
The lesson is not to subtract those numbers and announce thousands of exploitable, unpatched servers. It is that discovery, confirmation, upstream repair and deployment are separate jobs. Funding only the first job pushes work onto the people responsible for the rest.
My preference is a security market that pays for outcomes: reproducible reports, maintainer capacity, public fixes, usable update paths and independently tested containment. Customers should be able to take their evidence to another provider. Small maintainers should not need an enterprise AI contract to keep a widely used library safe.
The next era of security will likely include models watching for models and agents testing defenses against other agents. But a durable defense cannot depend entirely on who can afford the biggest swarm. It also needs less exposed infrastructure, credentials with less power, software that fails more safely, and people authorized to act on good evidence.
The question is no longer just whether AI can find the hole. It is who gets the fix, who controls the defense, and who receives the invoice.
Editorial note: this article separates verified incident reporting, vendor attribution and the author’s analysis. The conceptual illustrations were generated with ChatGPT; the infographics were authored from the linked records. No exploit was run against a live system for this article. Before acting, consult the current advisory for your exact product and configuration.
