Home / Articles / PHP October 2026, update 4: still no confirmed victim, one repository becomes six, the main site moves to the new build, and the agents get faster tools (26 October, 17:16 UTC)

PHP October 2026, update 4: still no confirmed victim, one repository becomes six, the main site moves to the new build, and the agents get faster tools (26 October, 17:16 UTC)

By Dinis Cruz · 2026-10-26 · article v1.0.0 · newsroom v0.13.94 · php2shellupdatesagentsrepositoriessgitevidencearticle

Abstract: The fourth update on php2shell and the newsroom covering it, as of 17:16 UTC on 26 October. Five days after the release, no named organisation has said it was compromised through php2shell; the evidence vault holds 543 sources, and the advice is moving from "install the fix" to "and check whether you were already broken into". A won "steal my bitcoin" challenge proved the flaw gives full control of a machine, on a server built to be attacked. The newsroom changed more than the story did. On 25 October the site's one repository became six, press, data, site, refs, updates and team, each with its own writers, version, gate and address; a release now goes live in 25 to 42 seconds instead of a median of 88, and a change to the references is checked in 7 seconds instead of 75. On 26 October the old repository was frozen, every agent moved to sgit 0.25.0, which cut the researcher's pass from 57 minutes to 35, the curator started writing its own data files after a written proposal, and at 17:07 UTC the main address was switched to the new build. What is not done yet: each site still waits on one build, run by hand, until a token only I can set is in place.

In short

• Still no confirmed victim. Five days in, 543 sources, and no named organisation says it was compromised.
• The advice is shifting: from "install the fix" to "and check whether you were already broken into".
• A bounty was won. It proves the flaw gives full control; the target was built to be attacked.
• One repository became six, split by who writes and how often.
• Releases in seconds: 25 to 42 seconds from push to live, instead of a median of 88.
• The old repository is frozen, and the main address now serves the new build.
• sgit 0.25.0 cut the researcher's pass from 57 minutes to 35.
• New writes need a proposal. The curator wrote one, and now releases its own data.
• Not done yet: the pages still wait on one build, and on a token only I can set.

The story

The line that matters has not moved. As the site's evidence on compromise puts it, at its check of 14:42 UTC on 26 October: "No named organisation has said it was compromised through php2shell." It is marked as what it is, "a time-bounded absence, not a confirmed fact", and one statement from one organisation would end it.

• More evidence, same answer. The evidence vault grew from 382 sources at update 3 to 543, with 605 captures. The researcher's source watch now follows 1,273 pages from 934 publishers.
• The advice is changing. The front page now says it plainly: the advice "is moving from 'install the fix' to 'and check whether you were already broken into'", with Singapore's and Luxembourg's authorities saying so.
• A reader's question, answered. The chief correspondent wrote Has anyone actually been hacked through php2shell? from 525 sources: millions of attack attempts, several vendors saying "exploited in the wild", websites pulled offline as a precaution, and not one organisation that has said it was broken into.
• A won bounty is not a victim. The same group of readers asked about a "steal my bitcoin" challenge: a server built on purpose to be vulnerable, with about $2,000 of bitcoin on it, which a researcher broke into on 25 October and wrote up. The correspondent's reading: "real proof the flaw gives an attacker full control of a machine", and "a game with a consenting target, not a victim". It ran PHP 8.4.26, one release below the fix, using PHP's own built-in web server, a mode not meant for production.
• One name to check. At 16:26 UTC the journalist recorded a secondary report that Square Enix confirmed unauthorised access to its systems that week, which does not say it was through PHP, next to another report that it took servers offline as a precaution because of the flaws. It went in as unverified, with the cause not stated, and the journalist left the headline line for the correspondent to decide. That is the review stage doing its job.
• The third flaw, CVE-2026-115560, is as update 3 described it: it affects fully patched releases, needs a rare setting, and has the mitigation session.upload_progress.enabled=0. No exploitation of it is reported.

The journalist's state of affairs is still version 3; version 4 waits for the new build. That is the other story of these two days.

One repository into six

By 25 October the site had outgrown its repository. Dev's proposal, measured at noon that day, counted 3,332 files, 1,057 pages built by one build script of 7,847 lines, 77 releases on 24 October alone, and 28 release messages in three days naming a conflict, a collision or a renumbering. Every release rewrote about 1,900 files, because the version is stamped on every page, and every release paid for the full gate, 74 seconds, whether it was a redesign or one run record. Its diagnosis is the useful part: "The cause is not the number of agents. It is that one version, one build, one gate, one board file and one output tree serve everything."

So we split it along who writes and how often, not along technology:

• press: the build library, the gate, the release scripts and the shared assets. Dev writes it; security reviews every change.
• data: the API. The evidence exported from the vaults, the claims, the timeline, the state of affairs, the risk graph, the ontology. Every version is immutable once published, with a manifest of every file's sha256.
• site: the main pages, the briefings, the questions, the stories and the tools.
• refs: a page per source and capture.
• updates: the state of affairs, the desk, what is new, the feeds.
• team: the board, the schedule cards, the run records, the briefs, the control room, and every agent's own folder.

The repositories meet only through published, versioned addresses, never through a shared file, and a site pins the data and press versions it was built with. I created the six repositories between 15:31 and 15:34 UTC on 25 October; by 18:12 UTC all six were serving, and every old address on the site still answers.

What the split buys

The first day's report measured it. A CI run from push to live took a median of 88 seconds in the one repository, and 25 to 42 seconds in each of the six. The gate step went from 70 to 132 seconds to between 0.1 seconds, for the team's records, and 7 seconds, for the references. In the report's words: "A change to the references is checked in 7 seconds instead of 75, and a change to the team's records in a tenth of a second."

That matters more than it sounds. A run record used to cost an agent 2 to 4 minutes and a fight over the one board file; three of dev's own releases on 25 October were stopped by another agent's board write. Now it is one file in team, checked in a tenth of a second.

The split was also reviewed, the same evening, by the design agent, from the outside. Its verdict was fair: "a separation of serving and proofing, not yet of making". Every page was still made by the old build. And it found a problem the one site never had: a reader is a stranger on every host, so a reader who chose Security on the main site was greeted as a first-time Executive on the references, with a new wallet for the reading meter on each.

The cutover

On 26 October the old repository was frozen at v0.22.22, in two steps, so that nothing depends on it any more: the build now runs in a box made from the six. Since then the data host has gone from version 0.1.12 to 0.1.39, and the press from 1.0.0 to 1.0.41 since it started on 25 October. At 16:30 UTC the press switched the main address, and edition v0.22.32, at 17:07 UTC, is the first served by the new build at php.oct.2026.newsroom.sgit.ai, with its robots file open to search engines and its own sitemap.

The design moved with it. Every page now carries "the line", one band under the masthead that talks to the reader as the persona they chose, Executive by default, with six others a click away. Views live in the address, such as /agencies/as/security/, a path that is not a file: the site's 404.html reads it, loads the real page and shapes it in the browser. The real pages stay the same for every visitor and every crawler, so only they are indexed.

The agents' tools got faster

On 26 October every agent moved to sgit 0.25.0, after the newsroom reported how slow the source watch vault had become, at 79,465 files and 2.7 GB. The researcher's first full pass on it, at 09:34 UTC, measured the difference: the first commit took 25 seconds instead of 12 minutes 38, the push 67 seconds instead of 4 minutes 16, the data export 34 seconds instead of 9 minutes, and the whole pass 35 minutes instead of 57, with nothing lost.

The same brief is honest about what is still slow. The curator's first status after the upgrade took 18 minutes 23 seconds, of which only about a minute was work, and a pull of two passes took 25 minutes. Its conclusion, sent back to the sgit team: "pull is now the slow step". That is how these tools improve: the newsroom is a demanding user, and it reports with numbers.

A new write needs a proposal

The curator's wakes are light, and it asked, with the journalist, whether it should write the data files that come from its own promotions. My decision, recorded by the conductor at 14:34 UTC, set a rule for any agent taking on a new write: a documented reason, a review by the agents it touches, agreement, then a trial, with the run records showing how it went.

The curator filed its proposal at 15:52 UTC. In its session I then told it to start, since several agents watch the vaults and a few mistakes while we find the workflow are acceptable; it released its first data files at 16:14 UTC, with 543 sources and 605 captures, and the review open. The journalist replied "yes", and noted that its own export of the same vault head had produced identical bytes, so the two releases merged with no conflict. That is a good first test.

Every release live again

The split has a cost we are still paying. In the old repository, every agent's release built and deployed the live site itself, within minutes. After the split, the pages are made by one build, the press chain, which runs only when dev runs it. On the morning of 26 October nothing the agents had released since 01:43 UTC was on the pages. So the conductor wrote, at my direction, a requirement: "Parity with v1." An agent that releases its own repository must be live, in its own area, within minutes, with no hand-run step by anyone else.

Dev has built the first half: a workflow in the press that runs the chain every quarter hour and builds only when one of the six has changed. It waits on one thing, a token only I can set. Until then, editions are made by hand: v0.22.28 at 11:38 UTC, then nothing on the pages until v0.22.29 at 16:01. The second half, "pass two", gives each site its own build from its own sources, so the press serves only the shared assets.

What waits on me

The control room counts it: 17 items waiting on me, 4 decisions, 2 agents blocked, 16 branches ahead with 43 commits. The four decisions, in the conductor's words, start with the obvious one: "Set ROUND_TOKEN", without which "nothing released today reaches the pages". Then security's review of the new release steps, whether wakes write the data files (now answered, for the curator), and how dev's daily wake should run. The team's status data lists 23 agents, and their sessions' running totals add up to $1,025, up from $928 at update 3.

The lesson of updates 2 and 3 still holds. The agents are fast, and the decisions are mine. The split makes the agents faster still, so the queue for my decisions gets longer, not shorter.

Why these regular updates

A live incident moves faster than any single article. These updates are fixed snapshots, so anyone can go back and see where things stood and what changed between them. This one is taken at edition v0.22.32, at 17:16 UTC on 26 October, just after the cutover; the team's status data it reads is from 15:25 UTC, and the control room says so.

The updates so far

1. PHP October 2026, at 8pm: update 1, the evening of 22 October, with a guided tour of the site.
2. PHP October 2026, update 2: 23:30 UTC on 23 October.
3. PHP October 2026, update 3: 23:40 UTC on 24 October.
4. This article: update 4, 17:16 UTC on 26 October.

What this does not claim

• A snapshot, not a verdict. As of edition v0.22.32; the team's status data is from 15:25 UTC.
• "No named organisation" is time-bounded. One statement from one organisation would end it.
• The Square Enix report is unverified, and does not say the access was through PHP.
• The bitcoin challenge is as the correspondent reports it, from the researcher's own write-up.
• The CI and sgit numbers are the agents' own measurements, from one day and one vault.
• Not every number has moved yet. The data host's index still gives its data as of 22 October, a field that has not been updated since.
• Costs are each session's running total, added up from the status data.

Where this comes from

The PHP story site's six repositories and the frozen v1, read on 26 October to 17:16 UTC: their commit logs, from v1's v0.17.4 to v0.22.22 and the six from their creation; the team's briefs and reports named above, and its agents-status.json; the data files compromise.json, story.json and the release notes of data v0.1.12 to v0.1.39; and the live pages, at the main site, the data host, the press, the references and the control room; the screenshots under the site's Apache-2.0 licence. Related: update 1, update 2, update 3, one researcher for every newsroom, a team frozen in time. Written up and checked by this site's agent, newsroom.writer; the editorial responsibility is mine.

Want the next issue by email. One issue a week or so: what was published, what it adds up to, and what is worth your time. Subscribe to the SGit Newsroom →

← All articles