Home / Articles / PHP October 2026, update 2 / Versions / v1.1.0
PHP October 2026, update 2: what changed in v1.1.0
From v1.0.0 (2026-10-24, 264ddad06) to v1.1.0 (2026-10-24, 78539ac8d), paragraph by paragraph.
49 paragraphs added, 37 removed, 2 changed in place, 10 unchanged. About 2,408 words added and 1,674 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
PHP October 2026, day three: where the story and the newsroom covering it stood at 23:30 UTC on 23 October, the scheduled agents running, the observability built in a day, and what waits on me
Summary: The first of what I want to be a daily post on the php2shell story and the newsroom covering it, taken at 23:30 UTC on 23 October, when the conductor agent read every one of the team's twenty sessions. On the story, the line that matters held: no named organisation has said it was compromised through php2shell, CISA's catalogue of exploited flaws still listed neither CVE, and the Dutch NCSC's inventory showed 109 of 751 products fixed. On the newsroom, the day's 84 commits moved the work from sessions I start by hand to agents woken on a schedule: the scheduled curator promoted 33 captures into the evidence vault, now at 260 sources, and the scheduled source watch moved into a pack-mode vault that clones in 95 seconds instead of 13 minutes and 47 seconds. The site also learned to watch itself: a telemetry app where every chart is a filter, a risk graph you can explore one step at a time, a Sherpa that answers readers' feedback, and four mockups for a redesign. And the honest part: 15 of the 20 agents were waiting on a decision from me.
[figure dy-telemetry-filters.webp] The PHP site's telemetry app (v0.4.0) on 23 October: 1,093 events from 13:43 UTC on 22 October to 20:26 UTC on 23 October, split by who sent them (readers, the editor, power users and the team, synthetic readers and crawlers), with every chart and cell a filter: click to keep, shift-click to exclude. | screenshot
PHP October 2026, update 2: the story held, a site that watches its own readers, agents on a schedule, and the decisions that wait on me (23 October, 23:30 UTC)
Summary: The second update on php2shell and the newsroom covering it, as of 23:30 UTC on 23 October. The story held: no named organisation has said it was breached through php2shell, CISA still lists neither flaw as exploited, and 109 of 751 affected products in the Dutch NCSC's inventory are fixed. The newsroom changed more. In a day and a half it built tools to see who reads the site and what works on it, private by design, and they found that the front page leaks: 81% of readers who start there read nothing else. An outside collaborator's five ideas turned the risk graph into a tool within hours. Scheduled agents now keep the evidence current, and our biggest data vault went from a 13-minute download to 95 seconds. And 15 of the 20 agents were waiting on a decision from me.
> Update 2. Following update 1, PHP October 2026, at 8pm on 22 October, here is where things stood at 23:30 UTC on 23 October. The updates so far are listed at the end.
[figure dy-telemetry-filters.webp] The PHP site's telemetry dashboard (v0.4.0) on 23 October: 1,093 page views from 13:43 UTC on 22 October to 20:26 UTC on 23 October, split into readers, the editor, power users and the team, synthetic readers and crawlers, with every chart and number a filter. Here: readers in the United Kingdom, phones left out, in three clicks. | screenshot
1 unchanged paragraph, under In short {#in-short}
• The story held. No named organisation compromised through php2shell; neither CVE in CISA's catalogue; 109 of 751 products fixed.
• The agents run on a schedule now. The scheduled curator promoted 33 captures; the evidence vault reached 260 sources.
• The source watch moved to pack mode. A fresh clone in 95 seconds instead of 13 minutes and 47 seconds.
• The site watches itself. Telemetry where every chart is a filter, and journeys drawn as a Sankey.
• The risk graph became a tool. 713 nodes and 1,418 edges, explored one step at a time, with its gaps computed.
• Readers have a Sherpa. Feedback answered point by point, and a redesign out for review.
• The story held. No named organisation breached through php2shell; neither flaw on CISA's exploited list; 109 of 751 products fixed.
• The site now watches its own readers, privately. And the first thing it showed is that the front page leaks.
• A reader's ideas became a tool in hours. The risk graph, rebuilt from a collaborator's five ideas.
• Readers have a guide. A new agent answers their feedback point by point.
• Agents on a schedule keep the evidence current. 33 new captures on 23 October.
1 unchanged paragraph
Why this hour {#why-this-hour}
I want one of these a day, a fixed snapshot rather than a running commentary, so that anyone can go back and see where things stood. For 23 October the best moment is 23:30 UTC, when the conductor agent refreshed the team's status page, reading all twenty agent sessions, the repository and the scheduled tasks without asking any agent. Everything below is as of that snapshot unless it says otherwise; a few things that landed in the hour after are marked as such.
1 unchanged paragraph, under The story {#the-story}
The journalist agent's state of affairs is a versioned page, so the day can be read as a delta. Version 1, at 14:11 UTC, from the evidence vault and the source watch:
• Compromises named: 0. Three candidates open (ČVUT, which stopped an attack it links to worldwide PHP attempts; GMO's FX VPS, with the cause not stated; DMM, with PHP not confirmed) and one ruled out (Valtec, which corrected itself).
• CISA's catalogue of known exploited vulnerabilities: neither CVE listed, unchanged since the evening of 22 October.
• NVD: CVSS 3.1 9.8, beside the CNA's CVSS 4.0 9.2.
• Public repositories mentioning the flaws: 735, up from 586 the evening before; a count of search results, not of working exploits.
• The Dutch NCSC's inventory: 109 of 751 products fixed, 389 still under investigation.
Version 2 followed just after midnight, from an evidence vault of 295 sources, with six of the curator's new claims held back as worded and the reason given. The line that matters most held all day: no named organisation said it was broken into through php2shell.
The agents run on a schedule {#scheduled}
Yesterday I wrote about this workflow as almost working. By the end of the day it was further along than that article said, and I should correct it here: I read the schedule vault, which the agents had not yet adopted, and the agents were already running without it.
• The scheduled curator, on Sonnet, with its key from the QR handshake, woke at its five times and promoted 33 captures from the source watch's queue: the evidence vault reached 260 sources, with 28 new claims, six of them disputed. 164 queue rows were still waiting, at about 18 a wake.
• The scheduled source watch became active at 07:00, 09:30, 12:00, 14:30 and 17:00 London time. Its evening pass was on its third attempt at 23:23 UTC, after two container restarts lost the first two, which is exactly the failure I described.
• Just after midnight, the schedules themselves moved out of the schedule vault and into the repository: each scheduled agent now has a card with its objective, its wake times and its wake prompt word for word, and a run record for every wake.
Pack mode {#pack-mode}
The source watch had grown to the point where it hurt: over a gigabyte, slow to clone and slow to pull. The researcher measured pack mode, the same vault stored as packs rather than as individual objects: a fresh clone in 95 seconds against 13 minutes and 47 seconds, the whole history pushed in 96 seconds, and the normal vault's object listing now timing out on the server. With two writers on the pack vault, a pull of the scheduled session's commit took 176 seconds and a one-file correction was pushed in 77. The watch moved into its pack-mode copy, 7r83qic5, and the scheduled curator followed it. The curator's first session advised against moving the evidence vault yet: a pack vault does not open in the browser, and the site's vault pages need that.
The site watches itself {#telemetry}
In a day and a half the dev desk built the observability I had been asking for. Every session on the site is now a reader, the editor, a power user or team member, a synthetic reader, or a crawler, declared by the browser where it can be and inferred before that. The telemetry app, v0.4.0 by the evening, makes every chart and every cell a filter, colours by any breakdown, and draws journeys as a Sankey and as a page network. Its stats are in a public vault, 0cfkdcvh, updated at every drain. The first thing it showed was uncomfortable and useful: the front page leaks. In the journeys, 134 sessions ended after their first page.
[figure dy-telemetry-journeys.webp] How sessions move through the PHP site, step by step: 113 sessions entered on the front page, and 134 left at the second step; colours are the site's sections. From the telemetry app, 23 October. | screenshot
The risk graph as a tool {#risk-graph}
A collaborator's ideas (CI-002) turned the risk graph from a picture into a tool. Every edge now says how it is known: read from a capture, read from the fix commit, or inferred by an agent, and the inferred ones are drawn dashed and can be hidden. The fix commit's 270 tests are nodes. You can start from one thing, a CVE, a risk, a file, a test, and follow it one step at a time, or climb from a file to the risks and controls above it. And a gaps page is computed at every build. On 23 October it said: no control is joined to code or a test, no code has an owner, and 14 risks have no story. That is the kind of honest gap list I want every system to have.
[figure dy-risk-explore.webp] Exploring the PHP story's risk graph from one node: 713 nodes and 1,418 edges in all; from CVE-2026-109618, the fix, the tests that check it and the risks it touches, with inferred links dashed and hideable. 23 October. | screenshot
Readers, collaborators and a redesign {#readers}
A new agent joined: the Sherpa, which walks with the reader. It answers readers' feedback point by point (UF-001 to UF-003 on 23 October, with two interface bugs reproduced), keeps a friction log of what gets in readers' way, with who can fix each, and sets collaborators' ideas against what the site already does. The designer put a redesign out for review: two dials, who you are and how much of the site you see (Focus, Standard, Everything), and four mockups built from the live data. No reader page has changed yet; the picks are mine.
[figure dy-redesign-a.webp] Mockup A of the PHP site's redesign, for review: a board member's front page, built from the live data of release v0.9.2, with the Focus, Standard and Everything dial and an answer in thirty seconds. Not the live site. | screenshot
The journalist agent keeps the state of affairs as a versioned page, so the day can be read as the difference between two versions. Version 1, at 14:11 UTC:
• Organisations that have said they were breached through php2shell: none. Three cases still open (ČVUT, which stopped an attack it links to worldwide PHP attempts; GMO's FX VPS, with no cause stated; DMM, with PHP not confirmed) and one ruled out (Valtec, which corrected itself).
• CISA's catalogue of known exploited vulnerabilities: neither flaw listed, unchanged since the evening of 22 October.
• NVD's score: 9.8 out of 10 (CVSS 3.1), beside the 9.2 (CVSS 4.0) the PHP project gave it.
• Public code repositories mentioning the flaws: 735, up from 586 the evening before. A count of search results, not of working exploits.
• The Dutch NCSC's inventory of affected software: 109 of 751 products fixed, 389 still under investigation.
Version 2 followed just after midnight, from 295 sources, with six of the curator's new claims held back and the reason given. The line that matters most held all day: no named organisation said it was broken into through php2shell. That is a time-bounded absence, and the site says so; one statement from one organisation would end it.
A site that watches its own readers {#telemetry}
The biggest change of the day was on the newsroom's side. In a day and a half, the dev desk agent built the tools I had been asking for: a way to see who reads the site and what works on it, without tracking anyone.
Private by design. Every page sends one anonymous event: the page, the site that referred the reader, a country and city from a lookup, the language, the kind of screen and a random id that lives in that browser tab. No IP address, no cookie, no name. The event is encrypted in the reader's browser before it leaves, and sent to a write-only lane on a private vault: the lane accepts writes and answers every one the same way, so nobody can read anything back through it. Only the holder of the vault can read the events.
Not everyone who opens a page is a reader. The first night looked busy: 356 page views from one session. It was Google's crawler, working through 252 pages. So every session is now in one of five groups: readers, the editor, power users and the team, synthetic visitors (agents and tests, including our own), and crawlers. Of the 1,093 page views by 20:26 UTC, crawlers were 565 and readers 233. Without the groups, every chart would have been mostly Google.
[figure dy-telemetry-who.webp] All 1,093 page views by group: 233 by readers in 168 sessions, 110 by the editor, 9 by power users and the team, 176 synthetic, 565 by crawlers. | screenshot
[figure dy-telemetry-timeline.webp] Page views per hour from 13:00 on 22 October to 20:00 on 23 October, by group: the crawler working through the night, readers steadiest in the UK morning and afternoon. | screenshot
A public face and a private dashboard. The counts, and only the counts, go into a public vault anyone can open, with a world map of where readers are. The full events stay private, in a dashboard that opens straight from its own vault and works like Kibana: click any bar, country, cell or node to keep only that; shift-click to leave it out; every number follows.
[figure dy-telemetry-map.webp] Readers by country, on a log scale: eighteen countries, the United Kingdom first by far, then the United States and Norway. | screenshot
What it found: the front page leaks. The journeys view follows sessions page by page. 113 reader visits started on the front page, and 81% of them read nothing else; the front page is read most and sends the fewest readers on. Of the sites that send readers, kode24.no, a Norwegian developer site, sends ones who stay: more than a third read a second page, against one in five from LinkedIn. That is the kind of finding a newsroom needs on day two, not in month three.
[figure dy-telemetry-journeys.webp] How reader sessions move through the PHP site, step by step: most start on the front page, and most of those end there, at the grey block marked (left). | screenshot
[figure dy-telemetry-network.webp] The same moves as a network: each page a node sized by the sessions that saw it. The front page is the hub; the one route that bypasses it runs from a source page to the claims. | screenshot
[figure dy-telemetry-what-works.webp] What works, page by page: right is read more, up is where readers go on. The front page is far right and low: read most, sending about one in five on. | screenshot
How it was built in a day and a half. This is the part I find most powerful. The dev desk did not build a telemetry platform. It assembled one from pieces we had already made into commodities: encrypted vaults that keep their history; write-only append lanes that let a browser send encrypted rows to a vault it cannot read; keys that live inside the vault, so whoever can open it can process it from the browser with no server; and apps that live in a vault of their own, versioned there, and open the data where it sits. No database, no analytics vendor, no server to run. When the pieces are commodities, a capability like this is a day and a half of conversation with an agent, not a project.
A reader's ideas, turned into a tool in hours {#ci-002}
One of the workflows I am proudest of is what happens when a collaborator writes in. On 23 October, the same outside collaborator who had sent the first set of ideas wrote back after seeing the risk graph and the redesign mockups. The Sherpa agent turned the message into CI-002: ten numbered items, each with the collaborator's own words, where the site stands today with links, what is missing, what the Sherpa recommends, and who could take it. Five of them went to the dev desk as a brief.
The result, the same day: the risk graph, 713 nodes and 1,418 edges connecting stakeholders, risks, weaknesses, the fix and its tests, became a tool. Every link now says how it is known (read from a capture, read from the fix commit, or inferred by an agent, drawn dashed and hideable). You can start from one thing, a CVE, a risk, a file, a test, and follow it a step at a time. And a gaps page is computed at every build. On 23 October it said: no control is joined to code or a test, no code has an owner, and 14 risks have no story. That is the kind of honest gap list I want every system to have. The dev desk then wrote a before-and-after for the collaborator, every change shown as the old page against the new. There is already a CI-003.
[figure dy-risk-explore.webp] Exploring the PHP story's risk graph from one node: from CVE-2026-109618 to the fix, the tests that check it and the risks it touches, with inferred links dashed and hideable. | screenshot
[figure dy-risk-gaps.webp] What the risk graph is missing, computed at every release over its 713 nodes and 1,418 edges: 95 of 95 controls joined to no code or test, 16 of 16 code nodes with no owner one step away, 9 of 16 that no test reaches, 14 of 34 risks no story tells, and 815 links inferred by an agent and not yet checked. | screenshot
Readers have a guide {#readers}
A new agent joined: the Sherpa, which walks with the reader. It answers readers' feedback point by point (three pieces on 23 October, with two interface bugs reproduced), keeps a friction log of what gets in readers' way and who can fix each, and sets collaborators' ideas against what the site already does. The designer put a redesign out for review: two dials, who you are and how much of the site you see (Focus, Standard, Everything), and four mockups built from the live data. No reader page has changed yet; the picks are mine.
[figure dy-redesign-a.webp] Mockup A of the PHP site's redesign, for review: a board member's front page with the Focus, Standard and Everything dial and an answer in thirty seconds. Not the live site. | screenshot
Agents on a schedule {#scheduled}
The evidence now stays current without me starting each run. A curator agent, woken five times a day with the key it received in a QR handshake, promoted 33 new captures from the research agent's queue on 23 October: the evidence reached 260 sources, with 28 new claims, six of them disputed, and 164 more captures waiting. The research agent's own pass became scheduled too, five times a day. Its evening pass needed three attempts, because the cloud container was replaced twice under it, which is exactly the failure I described in almost working. That article also understated how far this had got by the evening, and carries a note saying so.
1 unchanged paragraph, under Security, as it went {#security}
Two things worth recording. The conductor made explicit that aA vault's key is the whole boundary: whoever holds it can read and drain that vault's lane,vault, so the vaults page now lists the keys each agent holds are listed,holds, by ID and kind only, onnever thethe vaults page.keys. And about an hour after thethis snapshot, a second security pass found and fixed a stored cross-site scripting flaw in the Ask pane, where a captured page's title could have broken out of a citation and run script; it now renders the model's answer as DOM nodes.script.
1 unchanged paragraph, under What waits on me {#waits}
The status page is blunt about it: 20 agents, 2 working, 2 blocked, 15 waiting on the editor, 10 branches waiting to be carried into dev, and $588 spent across the sessions so far. The decisions at the top of its list: a go for the scheduled curator to re-export the evidence vault into the site (227 sources on the site against 260 in the vault), which vault type the two schedules use, the design picks, two blocked agents whose sessions cannot push, a security review of two branches, and two sealed keys from 22 October to open before they expire. That list is the real lesson of the day. The agents are fast; the decisions are mine, and that is where the time goes.
The team's status page is blunt about it: 20 agents, 2 working, 2 blocked, 15 waiting on me, 10 branches waiting to be released, and $588 spent across all the sessions so far. At the top of its list: a go to publish the evidence the curator has added (the site shows 227 sources against 260 in the vault), the redesign picks, two blocked agents whose sessions cannot push, a security review of two branches, and two sealed keys to open before they expire. That list is the real lesson of the day. The agents are fast; the decisions are mine, and that is where the time goes.
The vaults, and a 13-minute download that became 95 seconds {#vaults}
For readers new to how this newsroom works: the PHP site is rebuilt from vaults, never written by hand. A vault is an encrypted, versioned folder, like a git repository whose server cannot read it, made with our open source tool, sgit. Nineteen vaults sit behind the site: the evidence, with every source and its capture; the research agent's source watch, every page it follows with a snapshot whenever it changes; the private telemetry; and others. Two are public, and anyone can open them read-only in a browser.
The source watch is the biggest. By 23 October it held 63,662 objects and 1.6 GB, growing by about 5,000 objects a pass, and it was failing: the server could no longer list it, a fresh copy took 13 minutes and 47 seconds to download, and one push needed 12 attempts. Moved to sgit's new pack mode, which stores each push as one zip, the same history downloaded in 95 seconds and pushed in 96. The full story of how pack mode came to exist the day before it was needed is in a tangent that shipped.
Why these regular updates {#why-updates}
A live incident moves faster than any single article. These updates are fixed snapshots rather than a running commentary, so that anyone can go back and see where things stood, and what changed between them. Each is taken at a moment the data is consistent; for this one, 23:30 UTC, when the conductor agent refreshed the team's status page, reading all twenty agent sessions, the repository and the scheduled tasks without asking any agent. A few things that landed in the hour after are marked as such.
The updates so far {#the-updates}
1. PHP October 2026, at 8pm: update 1, the evening of 22 October, with a guided tour of the site. 2. This article: update 2, 23:30 UTC on 23 October.
3 unchanged paragraphs, under What this does not claim {#limits}
• Telemetry counts are a floor. Visitors with Do Not Track or a blocker send nothing; a session is a browser tab, not a person; and 168 reader sessions is a day and a half.
1 unchanged paragraph
• Telemetry groups are partly inferred. Declared by the browser from 23 October, inferred before.
• No compromise named is time-bounded. One statement from one organisation would end it.
• No breach named is time-bounded. One statement from one organisation would end it.
1 unchanged paragraph, under Where this comes from {#sources}
The PHP story site's repository and its 84 commits on 23 October, read at release v0.10.18 for the status snapshot and up to v0.11.3 for what came just after; its pages on team status, the state of affairs, pack[who mode,reads this site](https://php.oct.2026.newsroom.sgit.ai/articles/the-telemetry-tools/index.html), CI-002, the vaultsrisk graph before and after](https://php.oct.2026.newsroom.sgit.ai/articles/the-risk-graph-before-and-after/index.html), the vaults, pack mode and the Sherpa;Sherpa](https://php.oct.2026.newsroom.sgit.ai/sherpa/index.html); its screenshots, under its Apache-2.0 licence. Related: update 1, almost working, PHP[a Octobertangent 2026,that at 8pm,shipped](https://newsroom.sgit.ai/articles/a-tangent-that-shipped.html), the false positives are the next incident. Written up and checked by this site's agent, newsroom.writer; the editorial responsibility is mine.