Reduced, Not Safe
In October, the warning about a shared base could see down to configuration settings. It vouched for one step. The precaution needed nothing finer.
A warning about a shared base can grade exposure finely and still vouch for a single step. On 21 October, the PHP project published its advisory for two critical flaws. It listed settings that “reduce exposure to specific attack paths but do not make an installation safe”. Only an update, it said, was a complete solution. While the update could not yet be applied, one decision needed no finer distinction than the warning drew: going offline. That is the decision that arrived together.
This week’s anchor edition found that what stopped together on 21 October stopped by precaution, decided by those who ran the systems. This piece asks why the precaution could arrive together. The primary sources I read do not establish that compromise in production did. The piece was developed with AI writing assistance under human verification and editorial control.
One disclosure before the argument. Part of the evidence comes from a security firm. Since March 2026, it has belonged to the group that makes the image tool named in the method note. I read its report in the original and use only what the firm says it observed and concluded.
What the advisory would vouch for
The advisory graded exposure in its first lines. Every installation serving web requests was at risk. It judged the risk “highest for mod_php”, a way of embedding PHP in the web server itself.
For operators who could not update at once, it then listed changes to configuration. Among them: remove the memory limit, cap request size at 8 MB for applications that take no uploads, switch off the feature that reports upload progress. Some came with their limits spelt out. Switching off upload progress “blocks the confirmed session paths but not other variants”.
In this piece, resolution means how fine a distinction is, as in a photograph, not how a flaw gets fixed. The advisory’s resolution reached the configuration. The resolution it would vouch for stopped at the update. One release note put it in a single line: “There are no complete mitigations, updating is the only safe choice.”
Two days later, the same setting came back with a different label. For a third flaw, the project suggested switching it off until the next regular release. That would “fully protect” against an unlikely path to remote code execution. The setting was the same. The flaw was different and so was what the project could stand behind.
This series has a name for the point where one can say who decided: the locus de autoridade atribuível. In October there were two such points. The project decided what counted as safe. Each operator decided whether its services stayed available. An operator who stayed online on a partial measure took on a risk the project would not vouch for. Going offline removed public exposure, not the flaw. It held whatever the configuration.
How the step travelled
Before the release, the warning was coarser still. At 15:13 local time on 21 October, the Dutch government announced that several of its websites were being taken offline as a precaution. The fix was due later that afternoon. The advance notice had said the affected versions would come with it. The government’s note drew one line: sites that did not use PHP were not affected.
After the release, the guidance I read carried the project’s step forward. CERT-EU, which serves the EU institutions, repeats verbatim the advisory’s clause on partial measures. Where patching is not feasible, it says organisations should consider isolating internet-facing applications from public networks. The Canadian Centre for Cyber Security went further on 21 October: where immediate patching was not feasible, organisations should isolate affected applications.
On 22 October, the Dutch National Cyber Security Centre published a decision tree. Its explanations turn on a few questions. Who manages the PHP in use? Does a patched version exist? Who manages the product that embeds it? Can that PHP be reached from outside? In those explanations, I found no question about the settings the advisory listed. For older versions without a patch, the guide says to take systems offline as soon as possible. Elsewhere, it names going offline as the most disruptive of several mitigation options and calls for measures based on a risk assessment.
For anyone who could not patch at once, one decision needed no finer knowledge than where PHP ran: go offline until the fix. That held before the release and after it. It did not require showing that any attack would work there.
Get André Afonso Silva’s stories in your inbox
Join Medium for free to get updates from this writer.
What the attack needed
Six days after the release, the firm that published the original research on the flaws reported what its honeypots had seen. Honeypots are servers set up to attract attacks. None of the chains it captured reached the final stage.
One chain failed early. Its first full stage carried about 12 MB of padding. On one honeypot, a configured request-size limit of 8 MB made PHP skip that body, so the attack never reached the code it targeted. Eight megabytes is the figure the advisory had suggested for applications without uploads. It sat in the list the advisory said would not make an installation safe.
A newer chain went further. Its first stage reached the memory exhaustion it was built to cause. The next stage, meant to leak process memory, failed in every run the firm captured.
The firm points to differences between deployments. The leak stage was calculated for one official build with a 128 MB memory limit. One honeypot ran the same PHP version from a different build, with extra extensions and a 64 MB limit. In the firm’s words, copying public proofs of concept “does not address the work needed to turn a configuration-specific exploit into a reliable operational kit”. The firm expects these barriers to diminish over time.
These are one firm’s observations of its own honeypots. In this series’ terms, the published account is testimony about records I have not seen. It does not show how other installations behaved either. A public authority had said something similar four days earlier. On 23 October, the Dutch centre wrote that exploiting the flaws “is complex” and that large-scale exploitation was less likely than first estimated.
Two resolutions
Set the attack beside the precaution. The attack depended on configuration: a size limit, a memory limit, a build. The precaution needed only the warning’s own distinction: where PHP ran. On the firm’s account, diversity above the shared base held the attack back. It did nothing to the precaution, because going offline does not depend on how an installation is configured. The sources I read do not show how each operator chose what to take down.
Nothing here faults the refusal to call partial measures safe. A limit that stopped one chain says nothing about the next one. The firm itself says some attackers have the expertise to adapt the chain.
The Essência Framework 2.0 records a limit: “How shared substrate produces failures that arrive together rather than in sequence is not yet established in this work.” The Framework discusses suppliers that run on the same model or the same cloud. Reading a server language through it is my extension. October suggests one path, read from a single case. The warning vouched for a step. Every decision finer than that step belonged to whoever took it. The decisions that arrived together were the ones that needed nothing finer.
The next warning
The same month brought a warning about another shared base, this time with a date in place of a patch. On 27 October, in the final version of its post-quantum roadmap, the US National Institute of Standards and Technology set two dates. It will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under its standards and guidelines after 2035. Deprecated, in its terms, means the algorithm may still be used, but the data owner “must examine this risk potential and decide whether to continue”. Next week asks what the dates do to anyone who still rests on that base.
Safe, in October’s advisories, was not a reading taken from any installation. It was a step their authors would vouch for on every installation at once.
References
PHP. (2026, October 20). Upcoming critical PHP security release. php.net. https://www.php.net/archive/2026.php#2026-10-20-1
PHP. (2026, October 21). Security advisory: Critical remote code execution vulnerabilities, update now. php.net. https://www.php.net/archive/2026.php#2026-10-21-5
PHP. (2026, October 21). PHP 8.5.12 released! php.net. https://www.php.net/archive/2026.php#2026-10-21-4
PHP. (2026, October 23). Informational advisory: Session upload progress. php.net. https://www.php.net/archive/2026.php#2026-10-23-1
Rijksoverheid, Ministerie van Algemene Zaken. (2026, October 21). Aantal websites Rijksoverheid preventief offline na kwetsbaarheden PHP. https://www.rijksoverheid.nl/actueel/nieuws/2026/10/21/aantal-websites-rijksoverheid-preventief-offline-na-kwetsbaarheden-php
CERT-EU. (2026, October 23). Security Advisory 2026–018: Critical vulnerabilities in PHP (v1.2; first published October 20). https://cert.europa.eu/publications/security-advisories/2026-018
Communications Security Establishment Canada, Canadian Centre for Cyber Security. (2026, October 21). Statement regarding critical vulnerabilities in PHP affecting websites and online services. https://www.cyber.gc.ca/en/news-events/statement-regarding-critical-vulnerabilities-php-affecting-websites-online-services
National Cyber Security Centre, Netherlands. (2026, October 22). PHP vulnerabilities: what can you do? (Decision tree + explanation). https://www.ncsc.nl/api/media/sites/default/files/NCSC%20Guide%20Decision%20tree%20+%20explanation%20PHP%20vulnerabilities.pdf
National Cyber Security Centre, Netherlands. (2026, October 21; updated October 23). Update: PHP vulnerabilities remain a reason for immediate patching. https://www.ncsc.nl/en/alerts/update-php-vulnerabilities-remain-a-reason-for-immediate-patching
Shriki, Y., Dorfman, S., Blachsan, A., & Samuel, Y. (2026, October 27). PHP2Shell: Exploitation attempts and remediation trends. Wiz. https://www.wiz.io/blog/php2shell-exploitation-so-far
Google LLC. (2026, March 11). Google completes acquisition of Wiz [Press release]. Alphabet Investor Relations. https://abc.xyz/investor/news/news-details/2026/Google-Completes-Acquisition-of-Wiz-2026-ta7OaU2uA0/default.aspx
Moody, D., Perlner, R., Regenscheid, A., Robinson, A., & Cooper, D. (2026, October). Transition to post-quantum cryptography standards (NIST IR 8547). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/ir/8547/final
Essência AI. (2026, October 26). Essência Framework, version 2.0. https://essencia.ia.br
On method
Written with the support of Claude (Anthropic) and ChatGPT (OpenAI) for text and Gemini (Google) for the image. The full cognitive signature (intent, constraints, judgment under uncertainty, veto and responsibility) is mine, and so are the errors. Facts are verified against primary sources before they enter, and where verification was not possible the text says so.
I publish this note every week because this series argues that a document produced because someone asked for it is worth less than a record produced in the ordinary course of work. Nobody asked me for this note.
Essência AI Insights is a weekly series on governance, systemic risk and institutional infrastructure for emerging technologies. Written by André A. Silva
Tags
Artificial Intelligence · AI Governance · Cybersecurity · Vulnerability Management · Systemic Risk
