Home / Articles / Application behaviour policies / Versions / v1.1.0
Application behaviour policies: what changed in v1.1.0
From v1.0.0 (2026-10-22, dc7c24807) to v1.1.0 (2026-10-22, 97ba9ddcc), paragraph by paragraph.
23 paragraphs added, 1 removed, 4 changed in place, 48 unchanged. About 1,201 words added and 22 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
1 unchanged paragraph
Summary: We write Agent Behaviour Policies to see what an agent can reach, what it was asked to do, and the gap between the two, because whoever takes the agent over inherits its reach and ignores its mandate. A remote code execution flaw does exactly that to an application. With php2shell, anyone on the internet who could only read a website's pages could, on an unpatched server, run commands as the website itself, with everything the website can reach. So the same method applies. An application behaviour policy writes down, for one application, what it can reach: its files, its database, its mail, its network, its secrets, the other systems that trust it; what it is for; the gap; the barrier in front of each row; and the blast radius of each row if the whole application were taken over, with whether there is a way back. Decision and workflow policies say who accepts that blast radius and in what order things happen. This matters today for a practical reason. Organisations took websites offline as a precaution, and the question in front of them now is not only whether they have patched. It is: if this site were taken over anyway, what would we lose? With the map, the decision to bring a site back is a decision about known rows, with the cheap ones cut first and the signals to watch named. The worked example is invented; the method, the PHP evidence and our own sites are not. Updated with the story site's compromise map: as of 20:50 UTC, millions of attempts, three vendors reporting exploitation without naming a victim, and no named organisation saying php2shell was the way in. That silence lowers the likelihood; it does not change the blast radius.
1 unchanged paragraph
> Updated at 21:30 UTC. With the story site's new compromise map: what it searched, what it found, three readings of the silence, and whether this is where everyone should be looking. The report that the fix might be incomplete has also been answered.
8 unchanged paragraphs, under In short {#in-short}
• Millions of attempts, no named compromise. A finding in itself, as of 20:50 UTC on 22 October.
• The silence lowers the likelihood, not the blast radius. And it may be partly silence.
2 unchanged paragraphs, under The question in front of the offline sites {#question}
Now they want them back. The obvious question is "have we installed the fix?", and it is necessary. It is not sufficient. The fact-checkreport deskthat still has "thethe fix maymight be incomplete"incomplete was answered by PHP's security team on the morning of 22 October as an open,unrelated unshowncrash report;bug, but there will be another flaw after this one; and some sites run on versions of PHP that have no ready-made fix. The question that actually lets someone sign off a restore is a different one: if this website were completely taken over anyway, today, what would we lose, and could we get it back?
1 unchanged paragraph
What the compromise map shows {#compromise}
[figure ay-layers.webp] From attempts to a named compromise, as of 20:50 UTC on 22 October: millions of attempts against sensors, honeypots and edges; three security vendors reporting exploitation without naming a victim; one named organisation saying it was attacked, with the attack stopped; and none saying php2shell was the way in. Behind it, 184 vault sources, 773 watched pages from 474 publishers in 57 countries, 3,444 news items scanned and 295 named sites probed every 30 minutes. | comparison
There is also a second half to the bring-back decision: how likely is the takeover? This evening the story's site published a page that answers that as well as anyone can today: the compromise map. It takes one statement, "No named organisation has said it was compromised through php2shell", as of 20:50 UTC on 22 October, and lays out the evidence behind it, row by row: 33 statements, each with who said it, when, in their words, and where the capture is.
What it searched is the part I want people to notice. The evidence vault's 184 sources. A source watch of 773 pages from 474 publishers in 57 countries and 34 languages, checked hourly, with 339 pages read in their own language. 3,444 news items scanned from 1,621 publishers. And 295 sites somebody had named as taken offline, probed every 30 minutes.
And what it found, in layers:
• Attempts: millions. Cloudflare's chief executive, Amazon, watchTowr, CERT.LV and others report attempts against sensors, honeypots and their edges.
• Exploitation reported, no victim named: three vendors. Hadrian, Patchstack and Amazon say exploitation is happening. None names a victim.
• Named organisations saying they were attacked: one. The Czech Technical University said it faced an attack that was "part of worldwide attempts to hit PHP sites", and that "the active attack was stopped". Whether it succeeded is not stated.
• Named organisations saying php2shell was the way in: none. One Japanese company reported a break-in without stating a cause; another first blamed the PHP flaw, then corrected itself: the attackers had used a flaw in its own service.
• No success known. CISA, the PHP Foundation, Huntress and the governments or national agencies of Germany, the Netherlands, Japan, Switzerland, Belgium and Austria say they know of no successful attack, each within what it can see.
• The official signals. At 18:16 UTC, CISA's catalogue of known exploited vulnerabilities did not list either flaw. CISA's own assessment on the CVE records says exploitation: none; automatable: no; technical impact: total. And FIRST's exploit prediction score puts the modelled probability of exploitation activity in the next 30 days at 0.053 and 0.058.
The page is careful, and so should we be: this is "a time-bounded absence, not a confirmed fact". One statement from one organisation would end it, and the page lists what would: a named organisation's own notice, a cause stated by the companies that reported incidents, a listing in the catalogue, a regulator's breach notice, a vendor naming a victim with consent.
Three readings of the silence {#silence}
Even so, I think it is an important finding. About 31 hours after the flaws were disclosed, with exploit attempts in the millions and, by one scanner's count on the day of the release, more than a million and a half hosts still unpatched, you would expect to see compromises. We do not. There are three readings, and they are not exclusive:
1. The flaws are harder to use than they look. The CVE records rate the attack complexity high, and the site's fact-check desk records the researchers' view that triggering the bug is much easier than turning it into code execution. Add the edge protections that went up within hours. If that is the explanation, the likelihood is lower than the 9.2 suggests, and so is the risk. 2. Compromises are happening and not being disclosed. Most organisations have no obligation to say quickly, and in public, that they were broken into; where a rule exists, it usually runs to a regulator first and in days, not hours. This is the same pressure I keep writing about with software companies, from the SaaS apocalypse onwards: they have every reason to stay quiet if they can. It is also why I keep coming back to aviation, which, as I argued in a policy beside the prompt, got safe because crashes became news. In software, most crashes still do not. 3. The attackers are quiet too. That is the strange part. Mass exploitation is often noisy: defacements, ransom notes, botnets, sales of access. Quiet is what a careful attacker with a valuable target would choose, but it is not what we normally see.
For the application behaviour policy, the conclusion does not depend on which reading is right. The silence lowers the likelihood; it does nothing to the blast radius. A site owner who reads the compromise map can reasonably decide that the probability of a takeover today is lower than the headlines suggested, and still has to know what a takeover would cost. And because public silence is not evidence that nothing happened to you, your own footprint is the only evidence that is about your site.
Is this where everyone should be looking? {#watching}
There is a wider question too. php2shell has had governments telling organisations to switch websites off, and live pages in the national press. In the same weeks, as I noted in the attack surface you do not have, CISA's catalogue was filling with flaws in VPN gateways, mail gateways and firewalls that were exploited, some as zero-days. If php2shell, with millions of attempts, has no named victim yet, while quieter flaws in edge devices are in the catalogue because they were used, then attention and actual exploitation may be pointing at different places. I am asking another researcher to collect the flaws of the last week and what is known about their exploitation, so we can answer that with data rather than impression.
27 unchanged paragraphs, under The same method, a different subject {#method}, Three policies, not one {#three}, A worked example {#example}…
1. Patch. To PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a supplier's fixed build. On an older branch with no fix, the rest of this list matters more, not less.
2. Map the reach. One row per thing the application can do, from the server itself: its user, its files, its database grants, its mail, its network routes, its credentials.
3. Write the mandate. What the site is for, in a few lines, from the people who own it.
4. Cut the cheap rows. Outbound traffic, write access to code, mail, cloud credentials, mounted backups. Each is a configuration change with a large effect on the blast radius.
5. Name the signals. For each row left open, the trace it would leave if used. For php2shell, the story's site already collects detection signals with their sources: a PHP worker starting a shell, memory errors outside any script, crashes in clusters, uploads to pages that take none. Add the rows' own: new outbound connections, new files in the code directories, new administrator accounts, mail volume.
6. Decide. The owner named in the decision policy accepts the blast radius of what remains, or does not.not, with the likelihood as the evidence stands: for php2shell, the compromise map.
7. Restore, and read the footprint. In the first hours, then weekly. A row the footprint never uses is a candidate to cut; a row used outside the mandate is a near miss.
7 unchanged paragraphs, under What is new, and what is not {#new}, What this does not claim {#limits}
• The PHP facts are as the story's site records them. Its evidence was last captured at 11:34 UTC on 22 October.
• The PHP facts are as the story's site records them. The compromise map is as of 20:50 UTC on 22 October, at site v0.5.9.
• The three readings are mine. The compromise map makes no assessment of risk, and says so.
1 unchanged paragraph, under Where this comes from {#sources}
My voice memo of 22 October 2026; the method in footprint and blast radius and the code you do not ship; the impact ledger, detection signalssignals, fact-check and fact-checkcompromise map of php.oct.2026.newsroom.sgit.ai at v0.5.5;v0.5.9, read from its repository at 21:06 UTC; and this site's own deployment. Related: PHP October 2026, at 8pm, approved business mandates, the rules of the game, the attack surface you do not have. Written up and checked by this site's agent, newsroom.writer; the editorial responsibility is mine.