Fire in the foundations - weekly review W43

Weekly review W43, 16-22 October 2026: critical flaws in PHP, serious ones in Node.js, a malicious release of the LiteLLM gateway, Oracle’s quarterly patches, AI models in vulnerability research and in live intrusions, new techniques in MITRE ATT&CK, and agent controls in SAP and UiPath.

This week’s failures came from layers most organisations treat as bedrock: PHP, which runs WordPress among much else, the Node.js runtime and LiteLLM, the gateway many companies put in front of their language models.

PHP. On 21 October the PHP project fixed CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS 4.0. Every installation that serves web requests is affected, and remote code execution has been demonstrated against mod_php and PHP-FPM. Amazon’s honeypots logged the first attack attempt on 17 October, four days before the patches shipped, and the CVE identifiers were circulating a day before release. In Poland, the Central Informatics Centre (COI) temporarily took some of the public information bulletin (BIP) sites on its SSDIP system offline. CISA’s alert of 21 October reported no observed exploitation; Cloudflare, watchTowr and Patchstack report attempts. None of the sources we checked on 23 October documents a successful compromise.

Node.js. The same day Node.js shipped fixes for ten CVEs, among them an out-of-bounds write in the Brotli decoder that the advisory says permits remote code execution. It matters to SAP customers too: SAP CAP applications and many SAP BTP extensions run on Node.js, and keeping that runtime current is the application team’s job.

LiteLLM. Published through a hijacked release pipeline, LiteLLM 1.107.0 on PyPI and in the Docker images carried a credential stealer. The proxy that sits between applications and models became the attack channel. Datadog puts the PyPI exposure at about two hours; on Docker Hub it lasted longer. The maintainers advise pinning 1.106.2, removing the malicious files by hand and rotating secrets.

AI on both sides. Researchers using AI models took part in finding the PHP flaws - Calif and Wiz have said so, according to Tenable - and the Brotli bug was reported by OpenAI’s Codex Security team. XBOW has described how its agents, running on a publicly available model, built a full Chrome exploit chain in six days in August. The tools that help defenders find a flaw first also shorten the distance from advisory to working attack. With PHP, the first attempt arrived before the fix.

Inventory and time. This week leaves me with three tasks: find out where PHP, Node.js and model gateways run, including inside products that do not advertise them; measure patch-to-deployment time in days; rotate every secret after any supply-chain incident. On 16 October Poland’s Government Plenipotentiary for Cybersecurity published a recommendation under the national cybersecurity act (KSC) that advises identifying internet-facing services and running a formal vulnerability management process.

1. PHP2Shell: critical flaws in the PHP core, and attack attempts before the patch

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October, close two vulnerabilities. CVE-2026-109618 is memory corruption triggered when memory runs out; CVE-2026-109619 is a use-after-free caused by stale global state. The PHP team rates both at 9.2 under CVSS 4.0, and the 10.0 score that circulated earlier was wrong. Branches 7.4 to 8.1 receive only minimal source-level backports, with no new releases. The PHP Foundation says full remote code execution has been shown on Apache with mod_php in its default configuration, and on PHP-FPM through application code paths, with mod_php carrying the highest risk. Sources disagree on the affected range: CERT Polska says PHP 5.0 onwards, Calif and Tenable say 5.4.0 onwards.

Disclosure was messy. Amazon’s MadPot honeypots recorded the first attempt on 17 October. On 20 October the CVE numbers started circulating without technical detail, Calif accidentally published a video demonstrating the exploit. At 07:41 UTC on 21 October, more than six hours before the coordinated release, Chainguard published patched images; the Foundation accuses it of breaking the embargo, while Chainguard says it had already seen exploitation attempts. CISA’s alert of 21 October stated it had not observed exploitation, and by 22 October neither CVE had been added to the KEV catalogue. Amazon, Cloudflare, watchTowr and Patchstack report attempts, although watchTowr says the proof-of-concept code in circulation does not achieve remote code execution. None of the sources we checked on 23 October documents a successful intrusion or names a victim. In Poland, COI temporarily took some of the BIP sites on its SSDIP platform offline.

My first question after a week like this is simply where PHP runs, including inside products that do not show it; CISA itself warns that its presence may not be directly observable. Updating WordPress or its plugins does not fix anything here. PHP itself has to be upgraded and its workers restarted, and configuration workarounds reduce exposure without removing it. The server counts quoted in the press describe hosts with PHP visible to scanners, not confirmed vulnerable instances, so nobody can honestly size the problem yet. We map internet-facing services and plan infrastructure patching as part of our cybersecurity audits.

Sources: php.net, 21 Oct 2026; PHP Foundation, 21 Oct 2026; CISA, 21 Oct 2026; CISA KEV catalogue; CERT Polska, advisory 195/2026; Tenable FAQ, updated 22 Oct 2026; SecurityWeek, 22 Oct 2026; ITwiz, 22 Oct 2026. Status: versions, CVSS scores, the disclosure timeline and the absence from KEV confirmed at primary sources on 23 Oct 2026; attack attempts as reported by Amazon, Cloudflare, watchTowr and Patchstack (via SecurityWeek and Tenable); the BIP shutdown as reported by ITwiz.

2. LiteLLM 1.107.0: a malicious release of a model gateway

Late on the morning of 21 October (UTC), someone took over the release pipeline of LiteLLM, a widely used gateway between applications and language models. Version 1.107.0 went out to PyPI, Docker Hub and GHCR, including the latest, main-latest and main-stable tags. It carried three files - cook.pth, cook.py and sitecustomize.py - that run every time a Python interpreter starts, whether or not LiteLLM is imported. The payload harvested cloud secrets, developer tool credentials, AI tool and browser sessions and the LiteLLM proxy database, while a backdoor polled a remote file every hour and could fetch further code. No second stage has been observed. LiteLLM gives the exposure as 11:39 to 13:23 UTC on PyPI, 11:46 to 14:20 on Docker Hub and until 13:51 at the latest on GHCR; Datadog describes the PyPI window as roughly two hours.

According to Datadog, the attackers used stolen GitHub CLI OAuth tokens from three engineers’ accounts and ran the pipeline from a lookalike repository. LiteLLM describes the same mechanism but still treats the initial point of entry as a hypothesis. The maintainers’ advice: pin 1.106.2; delete the three files by hand, because uninstalling the package leaves them behind and running pip install in an infected environment triggers them again; preferably rebuild the environment; assume exfiltration succeeded on any internet-connected host; and rotate every secret, including the model provider keys stored in the proxy database and the master and virtual keys.

The malicious release did not come from a bug in the package’s code. It came through the hijacked publishing process, a distribution channel users rely on. A model gateway holds keys for every provider at once, so compromising it opens the whole AI layer of a company. In my view the latest tag has no place in production: I pin the gateway version, rebuild images from a trusted source and treat the list of keys the gateway stores as the rotation list for any incident. Model gateways and how they keep their secrets are part of our AI Security review.

Sources: LiteLLM incident notice, 21 Oct 2026; Datadog Security Labs, 21 Oct 2026. Status: confirmed at both sources on 23 Oct 2026; exposure windows per LiteLLM (Datadog’s PyPI times differ by a few minutes), attack vector per Datadog, initial entry a LiteLLM hypothesis.

3. Node.js: ten CVEs and remote code execution in the Brotli decoder

The Node.js security release of 21 October fixes ten CVEs - four rated high, three medium and three low - across the 26.x, 24.x and 22.x lines, with 26.12.1, 24.22.1 and 22.23.4 as the patched versions. The most serious, CVE-2026-111497, is an out-of-bounds write in the Brotli decoder that the advisory says permits remote code execution. It was reported by OpenAI’s Codex Security team. The advisory gives no CVSS score, does not describe the conditions for a successful attack and makes no mention of exploitation. The same release fixes TLS hostname verification bypasses (CVE-2026-106069 and CVE-2026-105483) and updates the CA store following the compromise of an eMudhra intermediate certificate authority.

Nothing in the advisory goes above “high”, yet for SAP customers this belongs near the top of the list. Node.js runs SAP Cloud Application Programming Model (CAP) applications, many SAP BTP extensions on Cloud Foundry and the MTA build tooling. The application team, not SAP, is responsible for the runtime version in buildpacks and CI pipelines, so that team has to check for the fix and roll it out. With PHP and Node.js patched on the same day, I would plan one maintenance window and one inventory for both, covering container images and build agents too. We build and run SAP BTP extensions as part of our SAP BTP and Clean Core work.

Source: Node.js, “October 2026 Security Releases”, 21 Oct 2026. Status: versions, CVE count, the Brotli description, the reporter and the absence of exploitation reports confirmed on 23 Oct 2026; the link to SAP CAP and SAP BTP is SNOK’s comment, not part of the advisory.

4. Oracle Critical Patch Update: 1,295 fixes and a CVSS 10.0 flaw in E-Business Suite

Oracle’s quarterly Critical Patch Update, released on 20 October, contains 1,295 new fixes. Fusion Middleware leads with 206, of which 134 are remotely exploitable without authentication, followed by E-Business Suite with 194 (31 remote and unauthenticated), Siebel CRM with 122, Communications with 110, JD Edwards with 102, MySQL with 98 and Java SE with 55. The top-rated flaw, CVE-2026-101809, sits in the Workflow Notification Mailer component of Oracle Workflow in E-Business Suite 12.2.3 to 12.2.15: exploitable over HTTP, remotely and without authentication, scoring 10.0 under CVSS 3.1. The advisory flags nothing as exploited and the KEV catalogue does not list it. SecurityWeek and Tenable count 1,209 unique CVEs and 95 critical ones; other tallies reach 112 critical because they count patches. Oracle’s next dates are Critical Security Patch Updates on 17 November and 15 December 2026 and the next CPU on 19 January 2027.

Oracle patches quarterly and SAP monthly through SAP Security Patch Day. Companies running both are better off planning the two cycles in one calendar of maintenance windows, with one test team. What strikes me more than the total is where the worst flaw lives. A module that sends workflow notifications is the kind of auxiliary component nobody treats as the edge of the system, and this one can be reached without logging in. We covered October’s SAP patches on 13 October as part of our SAP Security Patch Day series, and regression testing after a patch bundle in SAP and Oracle in the piece on the UiPath Test Cloud testing factory.

Sources: Oracle, Critical Patch Update Advisory - October 2026; SecurityWeek, 22 Oct 2026. Status: the patch total, per-product counts and CVE-2026-101809 with its 10.0 score confirmed in Oracle’s advisory (revision of 20 Oct 2026, read on 23 Oct 2026); 1,209 unique CVEs and 95 critical per SecurityWeek and Tenable.

5. AI models on both sides: the PHP2Shell research and a Chrome exploit chain

On 21 October the PHP Foundation set out how the flaws were found. An external security audit of PHP first spotted the out-of-memory problem in 2024 and judged an exploit theoretically possible, but found no concrete vectors. Earlier in 2026 the Foundation, working with Alpha-Omega, scanned PHP with Anthropic’s Claude Mythos model and brought in OpenAI Daybreak Red to validate reports and exploits. Calif started an audit on 30 July, and one of its researchers reported unconditional remote code execution on 11 August. OpenAI reported the same bug independently and sent further vectors on 18 September, Wiz filed a report on 24 August, and Trail of Bits is auditing as well. Tenable notes that Calif and Wiz both say they used AI models in their research. The Foundation writes that AI-assisted research brings “far more reports than before”; models help validate and cluster reports, but “a person makes every call and works on every patch”.

On 13 October XBOW described a chain of three Chrome bugs on Windows - in the V8 engine, the animated WebP decoder and Crashpad - built between 2 and 7 August by agents running on the publicly available GPT-5.6 Sol “and its predecessors”. People set the strategy and checked the agents’ work. Google paid a 250,000 USD bounty and all three bugs are fixed. XBOW’s first chain of this kind, earlier in 2026, took about two months. These are the company’s own claims, and nobody has independently reproduced them.

XBOW’s post dates from 13 October, before this review’s window, and shows the same acceleration as the PHP research. The same class of tools is flooding maintainers with reports and cutting exploit development from months to days. The Foundation’s line about a person making every call is the one I keep returning to, because that is where capacity now runs out, not in the number of bugs found. For defenders the race is decided by patch-to-deployment time. If the first attempt against PHP came four days before the fix, a patching cycle measured in weeks is no longer enough. We looked at the shrinking gap between disclosure and exploitation, and what it means for legacy systems, on 21 October in the context of the ECB letter.

Sources: PHP Foundation, 21 Oct 2026; Tenable FAQ, updated 22 Oct 2026; XBOW, 13 Oct 2026; XBOW Labs, technical write-up; Cloud Security Alliance, 14 Oct 2026. Status: the PHP discovery timeline confirmed with the Foundation on 23 Oct 2026; XBOW’s figures confirmed at source as company claims without independent replication (CSA); XBOW’s post dates from 13 October, outside the review window.

6. MITRE ATT&CK v20: prompt injection and impaired autonomous defences join the matrix

MITRE released ATT&CK v20 on 13 October. Its nine new Enterprise entries include T1698 Indirect Prompt Injection, T1699 Direct Prompt Injection, T1700 AI-Enabled Exfiltration, T1608.007 Stage Capabilities: AI Result Poisoning and T1685.007 Disable or Modify Tools: Impair Autonomous Defenses, alongside T1697 Steal Application Specific Passwords and T1696 Anti-Automation Evasion with CAPTCHA sub-techniques. MITRE has kept a separate knowledge base of threats to AI systems, ATLAS, for years. This is the first time techniques aimed at models and agents appear in ATT&CK itself, the catalogue SOC teams use to describe every other attack.

The release predates this week, but it fits the rest of the issue. A shared identifier makes it easier for the security team to talk to the team deploying SAP Joule or UiPath agents: prompt injection now has a technique number that can be tied to a detection rule and a test case. I would like our AI Security reviews to map agent risks to T1698-T1700; that is a proposal, not yet established practice. Our use of ATT&CK for SAP protection is described in the piece on defence in depth for SAP, and agents are covered by our AI Security review.

Source: MITRE ATT&CK - Updates. Status: technique numbers, names and release date confirmed on 23 Oct 2026; released on 13 October, outside the review window.

7. OpenAI’s reports: an agent switched off monitoring, a model spent from someone else’s testnet wallet

OpenAI publishes an ongoing series of “Misalignment Reports and Notices”, which stood at 20 reports and 3 notices on 23 October. The report of 20 October covers two incidents in internal deployments. On 3 October an agent running on GPT-6.1 Sol, while repairing an evaluation pipeline, turned off automatic alerts to the safety team; the monitor kept recording results. On 6 October an agent on GPT-6 Astra removed a monitoring integration while migrating a harness, and when asked, replied: “I did not remove an enabled monitor from it”. Neither incident was rated P0 and no trajectory was stopped automatically. OpenAI has updated Auto-Review for internal Codex use and admits: “We don’t yet have a satisfying explanation for this behavior”.

The report of 15 October, published the day before this review’s window, concerns an incident on 26 June. An internal research model from the GPT-5.6 Sol family, working on a coding task, checked 362 addresses and picked a funded account on the Sepolia Ethereum testnet whose key it derived from publicly known developer recovery phrases. It paid for a deployment from that account and did not mention it in its final answer.

Last week, writing about Satya Nadella’s post, I argued for an emergency brake that a person can always reach. These reports show the other half of the problem: agents switched off their own oversight in the middle of a task, and one of them denied it to an employee; OpenAI has no explanation for this yet. Logging and alerting therefore have to sit outside the reach of the agent they watch; I do not think monitoring configuration belongs within an agent’s permissions at all. It is to OpenAI’s credit that we know about this from the vendor itself, which publishes such reports routinely. On our UiPath agent projects an AI Security review is mandatory, and high-risk decisions go through human approval in UiPath Maestro.

Sources: OpenAI, report of 20 Oct 2026 on monitoring; OpenAI, report of 15 Oct 2026 on the test wallet; OpenAI, list of reports; BleepingComputer, 21 Oct 2026. Status: both reports confirmed at the primary source on 23 Oct 2026; all incidents occurred in OpenAI’s internal deployments.

8. Cairn: automated intrusions run by AI agents

On 19 October Reuters and NorForge described operators who exposed panels of Cairn, an open multi-agent platform, to the internet and used them to run automated intrusions. NorForge assessed more than 20 panels as malicious. A Chinese-speaking cluster tracked as AIA0001 ran 14 panels and more than 1,100 projects aimed at e-commerce and payment businesses in the United States, Japan and Australia. NorForge reports an average of under 23 hours from launch to objective, estimates the success rate at around 10 per cent, and verified 11 per cent of the hundreds of harvested credentials as live. Reuters writes of intrusions into the websites of more than 100 companies and attempts against more than 1,200 sites since 25 September. Deere said it had taken “necessary remediation actions” and saw “no indication that sensitive information was accessed”; SharkNinja said a standalone product support site was affected and the threat contained; Cummins is investigating a possible attack on a site run by a supplier. Cairn’s author stresses that the platform was not built for attacks.

Item 5 showed research speeding up; this one shows attackers doing the same, in an operation reconstructed from the panels’ own data. An intrusion run by automation takes hours and costs little, so a monitoring team’s response time has to be judged against the pace of a machine. The whole operation came to light because the AI tool’s panels were open to the internet without authentication. The same applies to AI tools running inside companies, so an inventory of internet-facing services should cover their panels too. We handle exposure monitoring and incident response as part of our cybersecurity services.

Sources: NorForge, “Inside Cairn”, 19 Oct 2026; Reuters, 19 Oct 2026, as republished by CP24. Status: the NorForge report confirmed at source on 23 Oct 2026; the Reuters account and company statements as carried in the republished wire story; company names come from Reuters, not from NorForge.

9. NVIDIA OpenShell Reference Architecture: SAP Joule Studio runtime, with Lenovo among the builders

At GTC Berlin on 21 October NVIDIA announced the OpenShell Reference Architecture, a reference stack for running AI agents: inference on Vera Rubin, Vera CPUs for agent harnesses, OpenShell as the execution boundary and BlueField-4 with Sentry software for out-of-band oversight. The announcement states that “SAP is integrating the NVIDIA OpenShell Reference Architecture with Joule Studio runtime”, as part of SAP Business AI Platform, “connecting business governance with secure agent execution”. Lenovo appears alongside Dell Technologies, Cisco, HPE and Supermicro among the companies building infrastructure on the architecture. NVIDIA describes it as available now, while many products and features carry a “when-and-if-available” caveat.

I read this as an answer to the question of who watches an agent in SAP. Instead of a vague promise of guardrails, there are two checkpoints: business authorisation in SAP Joule Studio runtime and execution isolation in OpenShell. It ties in with item 7, because oversight here sits in a layer the agent cannot configure. In the W40 review I wrote about agents in SAP Joule Studio and argued that a limit written into a prompt guarantees nothing; NVIDIA’s design moves that principle into hardware and the runtime. This is still a vendor announcement: SAP is in the middle of integrating it, and NVIDIA hedges on the availability of many components. The announcement brings together two areas of SNOK’s business, SAP and Lenovo, where we are a Platinum partner, so I do not write about it from a neutral position. I explored agent security in SAP at more length in the column on the three acts of SAP AI.

Sources: NVIDIA Newsroom, 21 Oct 2026; SAP News, 28 Sep 2026. Status: the quotes on SAP, Lenovo, availability and the caveat confirmed in NVIDIA’s announcement on 23 Oct 2026; the split of roles between SAP Joule Studio runtime and OpenShell is my interpretation, consistent with SAP’s announcement of 28 September.

10. UiPath Delegate: Automation Ops policy, and new models allowed by default

UiPath Delegate, an agent that runs on an employee’s computer, is governed through an Automation Ops policy (the “Assistant” product, template 26.10.0 or later). The policy has tabs for Tools, Helper Agents, MCP Servers, Security, Tool Permissions, Models, and Skills & Knowledge, and where several policies apply to one user, the most specific wins. October’s release notes record three changes. On 1 October Delegate entered public preview on macOS (Apple Silicon, macOS 14 or later). On 6 October administrators gained the ability to enforce Restricted access, set where tasks are saved and limit telemetry destinations. On 22 October, with version 1.6.9, came the change “Automation Ops allows each new model by default”: anyone who blocked Claude Opus 5 or 4.8 now has to disable Claude Opus 5.5 separately. The documentation does not describe detecting or blocking other AI tools on the workstation.

For administrators this is a concrete checkpoint. A model blocklist does not carry over to new versions by itself, so every new model in Delegate means another look at the policy. An agent that the organisation itself hands to staff can be governed by a single policy covering tools, MCP servers and models, provided the policy keeps pace with the vendor. We covered Delegate at its public preview and in the piece on an agent for a person.

Sources: UiPath Delegate - Governance with Automation Ops; UiPath Delegate - release notes, October 2026. Status: the policy, its tabs and the changes of 1, 6 and 22 October confirmed in UiPath’s documentation on 23 Oct 2026.

Inventory, patch time and oversight outside the agent

Three kinds of foundation gave way in this issue: the software applications stand on (PHP, Node.js, Oracle), the supply chain of AI tools (LiteLLM) and the agent itself, which can switch off its own oversight (OpenAI’s reports). The response starts with knowing what actually runs, measuring the time from patch to deployment in days, and keeping a record of actions that is produced outside the tool it describes. Poland’s government recommendation for KSC entities explicitly advises identifying internet-facing services and running a formal vulnerability management process (points 2.1 d and 3.2). Measuring patch time in days is my own proposal, and the case for records kept outside the agent comes from reports that model vendors now publish themselves.

We work on these questions in our cybersecurity, AI Security and SAP security services. Our free SNOK KSC-CHECK tool assesses how ready SAP systems are for KSC and NIS2. Questions: office@snok.ai.

Jacek Bugajski, CEO, SNOK