Research collected from outside sources and what this site derives from them; every fact links to a saved copy of its source Research or story?
Questions readers ask
The questions people ask about php2shell when they see the headline, each with a short answer that can be pasted back where it was asked, the longer answer with its sources, and the pages that carry it. Kept by the librarian, librarian@php.newsroom: the catalogue: which page answers which question, the questions readers actually ask, and the articles readers have seen that the vault has not captured yet.
The questions
| Question | The short answer | Read |
|---|---|---|
| Can anything be done to fix it, or do we just have to wait for updates? | The updates already exist: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were released on 21 October and fix both flaws. Nobody is waiting on PHP; the wait is for whoever runs each server to install them and restart. If that is you, update now; if you cannot today, there are temporary settings and, as a last resort, taking the site offline. If a hosting company runs your site, ask them whether it is patched. | If you run PHP: the steps, in order, with their sources The two flaws: CVE-2026-109618 and CVE-2026-109619 Detection and defence: what blocks php2shell and what shows it |
| Is PHP really the software behind most websites? | Roughly, if you count websites, not servers or the internet. Cloudflare and OpenAI say PHP is used by almost 70% of websites; Wiz's '70% of the Internet' is the same figure restated and is not supported by anything the site has captured. Counts of internet-facing PHP hosts are in the low millions (2.6 million, of which Censys counted 1.57 million unpatched on 21 October). | The numbers: 70%, 30 million, 2.6 million, 6,000, 674 Every claim, with its status and sources Affected systems: versions, deployments, applications, inventory |
| Has anyone actually been hacked? | Not that anyone has confirmed. Attack attempts are real and in the millions at Cloudflare alone, and Amazon saw one on a honeypot four days before disclosure. But as of 20:50 UTC on 22 October no named organisation has said it was compromised through php2shell (two security vendors report successful exploitation without naming a victim), CISA has not added it to its exploited-vulnerabilities list, and the sites that went offline say they did it as a precaution. | Exploitation signals, in order Impact: taken offline versus compromised Every claim, with its status and sources |
| Do I need to change my passwords? | Not because of this, as things stand. The flaw is on web servers, not on your devices, and no site has announced a breach through it. If a site you use announces one, follow its instructions. Using a different password on every site is the protection that holds whatever the next flaw is. | The two flaws: CVE-2026-109618 and CVE-2026-109619 Impact: taken offline versus compromised Briefing for a media and communications team: What can we say that is true, what should we not say, and what will we be asked? |
| How do I know whether my site is affected? | If the site runs on PHP (WordPress, Drupal, Joomla, Magento, MediaWiki, and Laravel all do) and the running PHP version is older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 without a distribution backport, it is affected. Check the version where the code runs, after the restart, not the package list. For bought-in products, the Dutch NCSC keeps an inventory of 674 products and their status. | Affected systems: versions, deployments, applications, inventory The NCSC-NL inventory: 674 products If you run PHP: the steps, in order, with their sources |
| Should we take our site offline? | Only if you cannot patch or apply the temporary mitigations in time. That is the advice from the NSA, CISA and the UK NCSC, and it is the last step on every agency's list. If the site is patched and the workers restarted, the advice is to keep it up and watch it. | If you run PHP: the steps, in order, with their sources What sixteen agencies actually advise Impact: taken offline versus compromised |
| Why is this such big news? | Four things at once: the flaws are in PHP itself, which runs a large share of the web; they were found with AI help; the coordinated disclosure leaked a day early, so the fix shipped under pressure; and the NSA, CISA and NCSC told organisations that could not patch to take systems offline, which is why government, council and police sites went dark. | PHP in October 2026: two critical security flaws, tracked as evidence Who found php2shell, and what the AI did How the coordinated disclosure broke |
| We are on PHP 7.4, 8.0 or 8.1. Is there a patch? | Not a release. PHP 8.1 and older are out of support; the project published source backport branches for 7.4, 8.0 and 8.1, which someone has to build. CISA says systems on 8.1 or older should be taken offline. Plan the migration to 8.2 or later now; in the meantime a distribution or vendor that backports, the temporary mitigations and isolation are the options. | The two flaws: CVE-2026-109618 and CVE-2026-109619 If you run PHP: the steps, in order, with their sources Briefing for a CTO: What does this cost us in engineering time, what breaks when we patch, and what do we change so the next one is a non-event? |
| We are behind Cloudflare (or another firewall). Are we safe? | Safer, not safe. Cloudflare's rules were live about nine hours before disclosure, on every plan including Free, and Akamai, Fastly, Imperva and Fortinet followed. Every one of them calls it a stopgap and says patch anyway: attackers mutate payloads, and the rules only see traffic that goes through the firewall. | Detection and defence: what blocks php2shell and what shows it Every claim, with its status and sources |
| Do our developers need to change our code? | No. Both bugs are in the C engine that runs PHP, not in PHP code, and the demonstrated attack runs before any application code. The fix is updating the PHP runtime and restarting it. What developers can do is check the version on the machines they deploy to and rebuild container images. | Briefing for a developer: Is my code the problem, what do I change, and how do I check the box I deployed to? The code: where php2shell lives and what the fix does The fix, mapped to the code |
Seen by readers, not yet in the vault
| Seen | What | State | Answered by |
|---|---|---|---|
| 2026-10-22, shared in a group chat | The Times: Race to fix PHP security issue in software behind most websites Hackers could seize control of online stores and steal passwords after the discovery of a critical vulnerability in programming | not captured: paywalled, and a reader's share link is personal, so the token was dropped from the URL. Queued for the researcher and vendor collector. | Can anything be done to fix it, or do we just have to wait for updates? Is PHP really the software behind most websites? Has anyone actually been hacked? Do I need to change my passwords? Why is this such big news? |
An article a reader has seen is listed here until a collector captures it into the evidence vault. Until then it is not cited anywhere on this site; the answers above rest on what is captured.
The catalogue: every page, and what it answers
Start here
- Who is reading? The readers of this site, mapped: 16 kinds of reader, from someone who has never heard of PHP to the people who maintain it, mapped by what they need to do and how technical they want it, each with a thirty-second answer and a reading path.
- The PHP security flaws, explained from the start: No technical background assumed: what PHP is, what went wrong, why it is called php2shell, what the CVE numbers mean, why websites went offline, whether anyone was hacked, and what to do now.
- Glossary: every php2shell term in plain English: 40 terms from the php2shell story (PHP, CVE, CVSS, remote code execution, WAF, KEV and more), each explained in plain English, in the sense it has in this story.
Briefings
- Briefing for a curious reader: What happened, does it affect me, and should I worry?: The php2shell story for a curious reader: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a website owner: My website runs on WordPress or similar: am I affected, and what do I ask my host?: The php2shell story for a website owner: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a project or programme manager: What unplanned work does this create, who do I chase, and what do I tell stakeholders?: The php2shell story for a project or programme manager: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a board member or executive: Are we exposed, what is it costing us, and who owns the decision to pull a system?: The php2shell story for a board member or executive: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a security lead: What do I patch first, what do I watch for, and when do I take something offline?: The php2shell story for a security lead: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a PHP or platform engineer: Which versions, which SAPIs, which settings, which commands?: The php2shell story for a PHP or platform engineer: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a journalist: Which numbers hold up, who said what first, and what is still unverified?: The php2shell story for a journalist: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a security researcher: What are the bug classes, what was demonstrated, and what is still open?: The php2shell story for a security researcher: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for an analyst or advisor: How did coordinated disclosure fail, and what does AI-assisted discovery change?: The php2shell story for an analyst or advisor: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a CISO: What is our exposure, what is our evidence we were not hit, and what do I tell the board?: The php2shell story for a CISO: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a CTO: What does this cost us in engineering time, what breaks when we patch, and what do we change so the next one is a non-event?: The php2shell story for a CTO: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a CFO: What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?: The php2shell story for a CFO: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a data protection officer: Was personal data exposed, does this start a GDPR breach assessment or a 72-hour notification, and what do I document?: The php2shell story for a data protection officer: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a head of AppSec: Which of our applications are in scope, which settings matter, and what do we add to the pipeline?: The php2shell story for a head of AppSec: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a developer: Is my code the problem, what do I change, and how do I check the box I deployed to?: The php2shell story for a developer: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
- Briefing for a media and communications team: What can we say that is true, what should we not say, and what will we be asked?: The php2shell story for a media and communications team: a thirty-second answer, what to decide, a reading path, the claims it rests on with their status and sources, and what is still open.
Yours
- Power users: start here: Where a power user of PHP October 2026 starts: the first fifteen minutes, the latest ask (what is new, what to do, the questions), the messages for the email list and the WhatsApp group, a form to join and a form for feedback, both encrypted in your browser.
- Now: the phone app:
- Your desk: what is new to you, and what changed: What is new to you on this site and what changed since you read it, by part of the site; what you put aside; your notes; all kept in your browser, exportable.
- The feed viewer: this site, the records, and your own feeds: Read this site's feeds, the CVE records, NVD, OSV, CISA KEV, GitHub, Wikipedia, Hacker News and Mastodon, and any feed you add, in your browser, with what you have read marked and only what is new shown next time.
- Feeds: what is new and what changed: RSS feeds for everything new and changed on this site and for each of its parts: an entry for every new item and every change, and where to read them.
- Subscribe: what changed, sent to you: Follow the PHP flaws story by email: everything or one part of the site, as it changes or as a digest; the address encrypted in your browser and confirmed before anything is sent.
The incident
- PHP in October 2026: two critical security flaws, tracked as evidence: PHP news for October 2026, led by the month's big story: two critical security flaws in PHP (CVE-2026-109618 and CVE-2026-109619, nicknamed php2shell). The current situation in plain words, the core facts with their evidence, what to do, and a briefing for every kind of reader.
- What's new: every change, release by release: What changed on this site in each release: new facts, facts whose status changed, the briefings that moved for each reader and the sections that were rewritten.
- The specialist summary: CVE-2026-109618 and CVE-2026-109619: The technical summary of the two PHP flaws of October 2026: what is established with its sources, the six scale figures, the open questions and the last 48 hours.
- The two flaws: CVE-2026-109618 and CVE-2026-109619: What the CVE records, the GitHub advisories and the PHP security team say about php2shell: the bug classes, what was demonstrated, which deployments, which versions, the fix and the temporary mitigations, with the blast-radius questions.
- The code: where php2shell lives and what the fix does: Read from a clone of php/php-src: the fix commit (389 files, authored 18 October, public 21 October 14:06 UTC), the engine mechanism it replaces, the hunks that matter, and the end-of-life backport.
- The timeline, 2024 to the latest capture: 68 dated events in the php2shell story, from the 2024 audit through discovery, coordinated disclosure, the leak, the release and the response, every one tied to a captured source.
- Who found php2shell, and what the AI did: Calif, OpenAI and Wiz each claim the discovery of php2shell; their own timelines side by side, the 2024 audit that saw it first, the credits on the advisories, and what the sources do and do not say about the models.
- How the coordinated disclosure broke: Hour by hour from the first circulation of the CVE IDs on 20 October to the release on 21 October: the pre-announcement, the deleted video, the early WAF rules, the embargo break, the first attempts, and the three accounts that disagree on what leaked.
- Exploitation signals, in order: Every signal of php2shell exploitation in the captured sources, from an Amazon honeypot hit on 17 October to the KEV catalog, with what exploitation would look like on a host.
- No named organisation has said it was compromised through php2shell: the evidence: The evidence behind one statement, as of 2026-10-22 20:50 UTC: attempts, vendor reports, statements that no success is known, named organisations, allegations and official lists, each with its source.
- The fix, mapped to the code: The php2shell fix as layered graphs: the two flaws, the design of the patch, and the php-src files and functions it changed, derived from the diff.
- Walk the graph: the fix and the code: A navigator over the php2shell review graph: the fix, the flaws it closes, and the files and functions it changed, each a link.
- Impact: taken offline versus compromised: Two ledgers for php2shell: every system reported taken offline with who said so, and every claim of compromise with its basis. As of the latest capture, no named organisation has confirmed a compromise.
- Detection and defence: what blocks php2shell and what shows it: What Cloudflare, Akamai, Fastly, Imperva, AWS and Fortinet deployed and what each says it cannot do; the community Suricata, Sigma, Falco and ModSecurity rules; the host signals; and how hard the exploit is according to the vendors who tried.
- In context: php2shell against Kaminsky, Heartbleed, Shellshock, Log4Shell and the last PHP RCE: Ten landmark vulnerabilities with their CVE records and KEV rows, the KEV catalog counted, and what the comparison says about severity, exposure, urgency and the discovery pipeline.
- If you run PHP: the steps, in order, with their sources: Inventory, patch, mitigate, shield, isolate or take offline, look for compromise, verify: every agency's php2shell advice merged into one ordered list with the sentence each step comes from.
- Patching: who gets a fix:
- The inventory, hour by hour:
- The second stories: signals:
The analysis
- Every claim, with its status and sources: 70 claims about php2shell, each with who makes it, a status (confirmed, reported, disputed, contradicted or unverified) and the captured sources behind it.
- Fact-check: how sure we are:
- The numbers: 70%, 30 million, 2.6 million, 6,000, 674: Every scale figure in circulation about php2shell, with what it measures, who said it, whether anyone checked it, and why they differ by four orders of magnitude.
- What sixteen agencies actually advise: The NSA, CISA, the UK NCSC, CERT-EU, ENISA, CERT-FR, Canada, Australia, New Zealand, the Netherlands, Italy, Switzerland, Latvia, Japan, Spain and Portugal on php2shell: who says take it offline, who says isolate, who says patch and nothing more, and who has seen exploitation.
- Affected systems: versions, deployments, applications, inventory: Which PHP versions and SAPIs php2shell affects, which applications had RCE demonstrated, and the NCSC-NL inventory of 674 products counted by status.
- Who says what: every party and its claims: 27 parties in the php2shell story, each with the claims this site attributes to it and the sources behind them.
- The story as a graph: claims, events and the sources they cite: 211 nodes and 285 citation edges from the php2shell claims and timeline to the captured sources, drawn from the same rows as the text, with the JSON to download.
- From outside: other models and sites:
- Perplexity's notes, in full:
The evidence
- Every source: 144 pages, 137 captures, 857 hashes: The manifest of the php2shell evidence vault: every captured source with its publisher, kind, publication time, capture times, HTTP status and the SHA-256 of every captured file.
- The NCSC-NL inventory: 674 products: Every row of the NCSC-NL php2shell software inventory at commit cca173c64ec5, with its status per CVE.
- The evidence vault, opened: The read key to the evidence vault behind this site, the link that opens it in the browser, and what is in it.
- Evidence, derived, authored:
- The fact pipeline: from a web page to a reader: How a source becomes a fact and a fact reaches a reader on this site: found, saved, read, cited, given a status, built into versioned sections and selected per reader, with counts at every stage and the facts by status in every release.
- How the story changed, release by release: Every section of the site, every reader's briefing and every fact, versioned across every release: what changed, when, and in which release.
- The vaults behind this site: Every vault this site is built from: the evidence vault and the source watch, both public with their read keys, and the private telemetry vault with its write-only lane; what each holds, who writes to it and how to open it.
- The evidence vault, opened: The read key to the evidence vault behind this site, the link that opens it in the browser, and what is in it.
- The source watch: every outside source on php2shell, watched and snapshotted: The public source-watch vault: 328 pages from 175 publishers in 38 countries, re-read on a schedule, a snapshot kept on every change and every snapshot a graph. Its read key, the vault embedded, and what is in it.
- Who reads this site: anonymous telemetry over an append lane: What every page sends to the telemetry lane, the published write-only credential, the key it is encrypted to, the counts, and what they are worth.
- Subscribe: what changed, sent to you: Follow the PHP flaws story by email: everything or one part of the site, as it changes or as a digest; the address encrypted in your browser and confirmed before anything is sent.
- The vaults behind this site:
- How the team talks: three vaults and one run:
- How the team talks: three vaults and one run:
- How the team talks: three vaults and one run:
- Who reads this site: anonymous telemetry over an append lane: What every page sends to the telemetry lane, the published write-only credential, the key it is encrypted to, the counts, and what they are worth.
- Who reads this site: anonymous telemetry over an append lane: What every page sends to the telemetry lane, the published write-only credential, the key it is encrypted to, the counts, and what they are worth.
- Power users: start here: Where a power user of PHP October 2026 starts: the first fifteen minutes, the latest ask (what is new, what to do, the questions), the messages for the email list and the WhatsApp group, a form to join and a form for feedback, both encrypted in your browser.
GRC
- GRC: risks, owners, standards:
- The risk register:
- Stakeholders and their registers:
- Frameworks: GDPR, NIS2, CRA, ISO, NIST:
- The risk graph:
- From the sgit network:
Stories
- All stories, written here:
- House · Journalist: Why can't every version of PHP just be patched:
- House · Journalist: Where php2shell stands:
- House · Journalist and historian: Exposed is not exploited:
- House · Historian: php2shell in perspective:
- House · Cyber desk: Patch at the speed of Metasploit:
- The editor, interviewed: Dinis Cruz on why this site exists: Dinis Cruz, the editor of PHP October 2026, on why he started tracking the PHP flaws, the 70% figure, what remote code execution does and does not mean, pulling the plug, and why every section of the site is versioned. In his own words.
About
- The method: capture, hash, claim, build, gate: How this site keeps evidence: the private vault and its protocol, the five status words, the deterministic build, the gate, and how an agent adds a source or replicates the whole thing for the next incident.
- The team: the people, the agents and how they work together: Every member of the team that runs this site, 2 people and 16 agents and roles, with a page each: role, what they own, their tasks and what they shipped; how a run works, the pipeline and the 16 audiences.
- The billing model: what runs and what is designed: How this site is paid for: the reading meter that runs (pence per page, kept in your browser, never blocking), the provenance pricing that is designed (per claim, with a share for the fact creator), and a counted model of what the story cost to assemble.
- Your reading account: The balance, history and receipts of your reading on this site, kept in your browser.
- The brief: a written request and two voice memos: The brief this site was built from, published in full: the editor's written request and two transcribed voice memos on mapping the PHP vulnerability as evidence.
- Corrections: Where the brief or a page of this site was wrong, what was found and what was done instead.
- Release history: Every release of this site, with what changed, why, and the vault commit it was built from.
- The pipeline: what is live, what is deploying: Each newsroom site's deploy runs, read in your browser from GitHub's public API with no credential, beside the version the site serves now: what is live, what is deploying, what was superseded, what failed.
- Admin and engineering: How this site is built, the checks in its gate, where things are, the reality file and the honest column.
- How to work on this site: guidance for every agent: Push to your own branch early and often and let dev@php.newsroom carry it into dev; quality from coding.sgit.ai, non-functional requirements from nfrs.sgit.ai, and the security requirements.
- status.json: the feed for other sites:
- The board: The work on this site and its vault, as rows: what is open, who owns it, what shipped it.
- Roles and responsibilities: The roles on this site and its vault, who fills each, what it owns and the rules it enforces; how a new agent joins.
- Briefs: The build briefs for this site, published in full before the work, newest first.
- Who reads this site: anonymous telemetry over an append lane: What every page sends to the telemetry lane, the published write-only credential, the key it is encrypted to, the counts, and what they are worth.
- Synthetic readers: six test readers who read the live site every hour: A board member, a CTO, a project manager, a security lead, a developer and a designer read the live site in a real browser and say what works, what does not and what to change; every run is kept in that reader's own vault.
Every page also has a markdown twin, listed in llms.txt; the questions themselves are data/questions.json.
Asking a new question
Answer a question with a page, not a paragraph. If no page answers it, the answer is written here with its sources, and the gap goes to the editor. A question that is asked twice gets a page. The librarian's role, rules and the mistake behind them are on the team page.