{
 "sections": {
  "page-flaws": {
   "title": "The two flaws",
   "kind": "page",
   "path": "flaws/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "e73c5a2d56f4",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The two flaws: CVE-2026-109618 and CVE-2026-109619\n\nWhat 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.\n\n# The two flaws\n\nTwo bugs in the PHP engine, the same severity, the same fix, the same four releases. Both are memory-safety failures in how PHP recovers from an error, and both can be reached by an unauthenticated HTTP request. This page keeps to what the primary records say and marks where they differ.\n\n**Fixed in** PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 · **Vector** `CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N` · **Nickname** php2shell (NSA: PHP2Shell) · **CNA** PHP Group\n\n### CVE-2026-109618: RCE via OOM corruption\n\nGHSA-w8hw-w9fx-j79w · CVSS v4.0 **9.2** · CWE-416, 755, 824, 1325, 1419 · reserved 2026-10-12 21:03:58 UTC · advisory 2026-10-21 13:34:25 UTC · CVE record 2026-10-21 13:48:34 UTC\n\n**The record's description, verbatim.** *PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts may not properly account for this scenario and leave request memory in an uninitialized state before performing an allocation. The subsequent request cleanup procedure may read or branch on this memory. Multiple OOM strategies can consistently trigger this condition and lead to remote code execution (RCE).*\n\n**What was demonstrated.** Complete RCE validated over HTTP against mod_php with default input and memory limits, before any application code runs. FPM: susceptible by source analysis; the GitHub advisory says no complete FPM exploit has been demonstrated. FrankenPHP likely susceptible; LSAPI likely but unvalidated.\n\n**The fix.** Removes longjmp() for OOM. A delayed, graceful soft OOM at the next VM safe point, plus a hard OOM via _exit() at a higher threshold.\n\nCVE record PHP NVD oss-security\n\n### CVE-2026-109619: RCE via stale global state\n\nGHSA-6wmf-4rv5-p3rp · CVSS v4.0 **9.2** · CWE-416, 755, 824, 1325, 1419 · reserved 2026-10-12 21:04:00 UTC · advisory 2026-10-21 13:34:13 UTC · CVE record 2026-10-21 13:54:43 UTC\n\n**The record's description, verbatim.** *PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed. Subsequent requests may read or branch on this stale state before it is fully initialized. Multiple strategies can trigger this condition and produce remote code execution (RCE).*\n\n**What was demonstrated.** A use-after-free of worker global state across requests: a producer request and a consumer request on the same worker. Confirmed on the PHP 8.5 fatal-error-backtrace path (the basis of the mod_php exploit) and the session upload progress path, which is enabled by default and needs no session_start(); the session path was validated against mod_php and FPM.\n\n**The fix.** Part of the same change, \"Avoid state corruption via bailout\": global state is reset so it cannot refer to freed request memory.\n\nCVE record PHP NVD oss-security\n\n## Which deployments\n\nThe flaw is in the engine, so what matters is how PHP is wired to the web server. php.net ranks mod_php highest.\n\n| SAPI | Risk | What the primary sources say | Sources |\n|---|---|---|---|\n| Apache mod_php | highest | Unauthenticated RCE demonstrated over HTTP with default input and memory limits, before any application code runs. | php.net PHP oss-security |\n| PHP-FPM | susceptible | For CVE-2026-109618 the GitHub advisory says no complete FPM exploit has been demonstrated; the PHP Foundation blog says RCE was confirmed on FPM through application-level paths. For CVE-2026-109619 the session path was validated against FPM. | PHP PHP Foundation PHP oss-security |\n| php-cgi | at risk | Listed by php.net among installations serving web requests. | php.net |\n| FrankenPHP | likely susceptible | 'likely susceptible' per the GitHub advisory. | PHP |\n| LiteSpeed (LSAPI) | likely, unvalidated | 'application-specific exploits being likely but unvalidated'. | PHP |\n| CLI, cron, queue workers | not web-serving | The advisory scopes the risk to installations serving web requests. A CLI process that parses untrusted input is not covered either way by the primary sources. | php.net |\n\n## What a compromise would mean: the blast radius\n\nThis section is the site's own analysis, written from the sources it cites. It is a way of asking the question, not an assessment of any system.\n\nRemote code execution *as the web worker* is the floor, not the ceiling, and not yet a breach. What an attacker gets is whatever that worker can reach: the application's source and configuration, the database credentials in it, the session store, the files the worker can read or write, the outbound network it can open, and anything that trusts requests from that host. What they do not automatically get is the database server's other schemas, the credentials that were never on that host, or a system behind an allow-list the worker is not on. The blast radius of one compromised PHP worker is therefore a property of the system around it, and that is the first thing to map. The questions, with where the answer usually lives:\n\n- **What runs there?** A brochure site with no login, a shop with payment data, an intranet with single sign-on, a mail client, an admin panel. The same bug has a different consequence in each. (The NCSC-NL inventory is a start; your asset register is the real answer.)\n\n- **What credentials sit on the host?** Database passwords, API keys, cloud instance roles, SSH keys in a deploy user's home. A key that cannot be used from anywhere else is a much smaller loss than one that can.\n\n- **What can the worker reach outbound?** Egress rules decide whether a shell becomes a download of tooling, a callback, or a pivot.\n\n- **What trusts the host?** Internal services that accept any request from the web tier, shared file systems, backup agents.\n\n- **What would you see?** CISA's signal is concrete: PHP worker processes launching shells or downloading tools. JPCERT warns that with several exploit paths, one detection rule can miss an attack and a clean log does not prove a clean system.\n\n- **How fast can you pull the plug?** Taking a system offline is the last step in every agency's list, but the ability to do it in minutes, cleanly, is a property worth having before the next one of these.\n\nCISA JPCERT/CC PHP NCSC-NL\n\n## Affected and fixed versions\n\n| Branch | Affected | Fixed | In the CVE record |\n|---|---|---|---|\n| 8.5 | = 5.4' (Wiz); 'toutes versions 5.x, 6.x, 7.x' (CERT-FR) | no release, no backport | **no** |\n\nThe CVE records carry defaultStatus 'unaffected' and list only 8.2 to 8.5, so an automated scanner reading the CVE will call 7.4 to 8.1 unaffected. The php.net advisory, the backport branches and a Greenbone reply on oss-security say otherwise.\n\nCVE record php.net php-src NCSC-NL Wiz on X CERT-FR oss-security\n\n## The temporary mitigations, and what each one does not do\n\n| For | Setting | Caveat, from the same source |\n|---|---|---|\n| CVE-2026-109618 (OOM corruption) | memory_limit=-1, set where applications cannot override it (php_admin_value in the FPM pool or Apache config); check no pool, directory or app setting restores a finite limit. | Removes the controllable memory-limit failure; an underlying allocation failure can still reach the vulnerable path. |\n| CVE-2026-109618 | A low post_max_size (8M without uploads, 32M with), upload_max_filesize below it, and web-server or proxy limits on decoded request size, field count, multipart part count, header count and nesting depth, including for requests without a usable Content-Length. | Reduces exposure to specific attack paths; does not make an installation safe. |\n| CVE-2026-109618 | A container or cgroup memory limit as an availability boundary, killing only the affected worker. | Do not use RLIMIT_AS or RLIMIT_DATA: they can cause the vulnerable allocation failure. |\n| CVE-2026-109619 (stale global state) | session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration, then restart every worker. | Blocks the confirmed session paths only. ini_set() and .user.ini are too late. |\n| CVE-2026-109619, PHP 8.5 only | fatal_error_backtraces=0, then restart every worker. | Blocks the confirmed fatal-backtrace path only. |\n| CVE-2026-109619 | Remove invalid or deprecated per-request settings that emit diagnostics before initialisation; fix attacker-reachable fatal errors and execution timeouts. | Hiding diagnostics with error_reporting, display_errors or @ does not help. |\n| both | pm.max_requests=1 on FPM (GitHub advisory). | 'Updating is the only reliable mitigation.' |\n\nphp.net: *while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.* php.net PHP CERT-EU NCSC-NL\n\nThe engineering steps, in order, are on If you run PHP. The disagreement between the two primary accounts of FPM is claim rce-fpm."
    },
    {
     "v": 2,
     "hash": "5c16343c692a",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The two flaws: CVE-2026-109618 and CVE-2026-109619\n\nWhat 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.\n\n# The two flaws\n\nIn plain English Two bugs deep inside PHP, in how it cleans up after an error. Both can be triggered by anyone who can reach a PHP website. Both are fixed in the same four releases.\n\nTwo bugs in the PHP engine, the same severity, the same fix, the same four releases. Both are memory-safety failures in how PHP recovers from an error, and both can be reached by an unauthenticated HTTP request. This page keeps to what the primary records say and marks where they differ.\n\n**Fixed in** PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 · **Vector** `CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N` · **Nickname** php2shell (NSA: PHP2Shell) · **CNA** PHP Group\n\n### CVE-2026-109618: RCE via OOM corruption\n\nGHSA-w8hw-w9fx-j79w · CVSS v4.0 **9.2** · CWE-416, 755, 824, 1325, 1419 · reserved 2026-10-12 21:03:58 UTC · advisory 2026-10-21 13:34:25 UTC · CVE record 2026-10-21 13:48:34 UTC\n\n**The record's description, verbatim.** *PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request. Some contexts may not properly account for this scenario and leave request memory in an uninitialized state before performing an allocation. The subsequent request cleanup procedure may read or branch on this memory. Multiple OOM strategies can consistently trigger this condition and lead to remote code execution (RCE).*\n\n**What was demonstrated.** Complete RCE validated over HTTP against mod_php with default input and memory limits, before any application code runs. FPM: susceptible by source analysis; the GitHub advisory says no complete FPM exploit has been demonstrated. FrankenPHP likely susceptible; LSAPI likely but unvalidated.\n\n**The fix.** Removes longjmp() for OOM. A delayed, graceful soft OOM at the next VM safe point, plus a hard OOM via _exit() at a higher threshold.\n\nCVE record PHP NVD oss-security\n\n### CVE-2026-109619: RCE via stale global state\n\nGHSA-6wmf-4rv5-p3rp · CVSS v4.0 **9.2** · CWE-416, 755, 824, 1325, 1419 · reserved 2026-10-12 21:04:00 UTC · advisory 2026-10-21 13:34:13 UTC · CVE record 2026-10-21 13:54:43 UTC\n\n**The record's description, verbatim.** *PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed. Subsequent requests may read or branch on this stale state before it is fully initialized. Multiple strategies can trigger this condition and produce remote code execution (RCE).*\n\n**What was demonstrated.** A use-after-free of worker global state across requests: a producer request and a consumer request on the same worker. Confirmed on the PHP 8.5 fatal-error-backtrace path (the basis of the mod_php exploit) and the session upload progress path, which is enabled by default and needs no session_start(); the session path was validated against mod_php and FPM.\n\n**The fix.** Part of the same change, \"Avoid state corruption via bailout\": global state is reset so it cannot refer to freed request memory.\n\nCVE record PHP NVD oss-security\n\n## Which deployments\n\nThe flaw is in the engine, so what matters is how PHP is wired to the web server. php.net ranks mod_php highest.\n\n| SAPI | Risk | What the primary sources say | Sources |\n|---|---|---|---|\n| Apache mod_php | highest | Unauthenticated RCE demonstrated over HTTP with default input and memory limits, before any application code runs. | php.net PHP oss-security |\n| PHP-FPM | susceptible | For CVE-2026-109618 the GitHub advisory says no complete FPM exploit has been demonstrated; the PHP Foundation blog says RCE was confirmed on FPM through application-level paths. For CVE-2026-109619 the session path was validated against FPM. | PHP PHP Foundation PHP oss-security |\n| php-cgi | at risk | Listed by php.net among installations serving web requests. | php.net |\n| FrankenPHP | likely susceptible | 'likely susceptible' per the GitHub advisory. | PHP |\n| LiteSpeed (LSAPI) | likely, unvalidated | 'application-specific exploits being likely but unvalidated'. | PHP |\n| CLI, cron, queue workers | not web-serving | The advisory scopes the risk to installations serving web requests. A CLI process that parses untrusted input is not covered either way by the primary sources. | php.net |\n\n## What a compromise would mean: the blast radius\n\nThis section is the site's own analysis, written from the sources it cites. It is a way of asking the question, not an assessment of any system.\n\nRemote code execution *as the web worker* is the floor, not the ceiling, and not yet a breach. What an attacker gets is whatever that worker can reach: the application's source and configuration, the database credentials in it, the session store, the files the worker can read or write, the outbound network it can open, and anything that trusts requests from that host. What they do not automatically get is the database server's other schemas, the credentials that were never on that host, or a system behind an allow-list the worker is not on. The blast radius of one compromised PHP worker is therefore a property of the system around it, and that is the first thing to map. The questions, with where the answer usually lives:\n\n- **What runs there?** A brochure site with no login, a shop with payment data, an intranet with single sign-on, a mail client, an admin panel. The same bug has a different consequence in each. (The NCSC-NL inventory is a start; your asset register is the real answer.)\n\n- **What credentials sit on the host?** Database passwords, API keys, cloud instance roles, SSH keys in a deploy user's home. A key that cannot be used from anywhere else is a much smaller loss than one that can.\n\n- **What can the worker reach outbound?** Egress rules decide whether a shell becomes a download of tooling, a callback, or a pivot.\n\n- **What trusts the host?** Internal services that accept any request from the web tier, shared file systems, backup agents.\n\n- **What would you see?** CISA's signal is concrete: PHP worker processes launching shells or downloading tools. JPCERT warns that with several exploit paths, one detection rule can miss an attack and a clean log does not prove a clean system.\n\n- **How fast can you pull the plug?** Taking a system offline is the last step in every agency's list, but the ability to do it in minutes, cleanly, is a property worth having before the next one of these.\n\nCISA JPCERT/CC PHP NCSC-NL\n\n## Affected and fixed versions\n\n| Branch | Affected | Fixed | In the CVE record |\n|---|---|---|---|\n| 8.5 | = 5.4' (Wiz); 'toutes versions 5.x, 6.x, 7.x' (CERT-FR) | no release, no backport | **no** |\n\nThe CVE records carry defaultStatus 'unaffected' and list only 8.2 to 8.5, so an automated scanner reading the CVE will call 7.4 to 8.1 unaffected. The php.net advisory, the backport branches and a Greenbone reply on oss-security say otherwise.\n\nCVE record php.net php-src NCSC-NL Wiz on X CERT-FR oss-security\n\n## The temporary mitigations, and what each one does not do\n\n| For | Setting | Caveat, from the same source |\n|---|---|---|\n| CVE-2026-109618 (OOM corruption) | memory_limit=-1, set where applications cannot override it (php_admin_value in the FPM pool or Apache config); check no pool, directory or app setting restores a finite limit. | Removes the controllable memory-limit failure; an underlying allocation failure can still reach the vulnerable path. |\n| CVE-2026-109618 | A low post_max_size (8M without uploads, 32M with), upload_max_filesize below it, and web-server or proxy limits on decoded request size, field count, multipart part count, header count and nesting depth, including for requests without a usable Content-Length. | Reduces exposure to specific attack paths; does not make an installation safe. |\n| CVE-2026-109618 | A container or cgroup memory limit as an availability boundary, killing only the affected worker. | Do not use RLIMIT_AS or RLIMIT_DATA: they can cause the vulnerable allocation failure. |\n| CVE-2026-109619 (stale global state) | session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration, then restart every worker. | Blocks the confirmed session paths only. ini_set() and .user.ini are too late. |\n| CVE-2026-109619, PHP 8.5 only | fatal_error_backtraces=0, then restart every worker. | Blocks the confirmed fatal-backtrace path only. |\n| CVE-2026-109619 | Remove invalid or deprecated per-request settings that emit diagnostics before initialisation; fix attacker-reachable fatal errors and execution timeouts. | Hiding diagnostics with error_reporting, display_errors or @ does not help. |\n| both | pm.max_requests=1 on FPM (GitHub advisory). | 'Updating is the only reliable mitigation.' |\n\nphp.net: *while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.* php.net PHP CERT-EU NCSC-NL\n\nThe engineering steps, in order, are on If you run PHP. The disagreement between the two primary accounts of FPM is claim rce-fpm."
    }
   ]
  },
  "page-timeline": {
   "title": "Timeline",
   "kind": "page",
   "path": "timeline/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "213a4219b7dc",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The timeline, 2024 to the latest capture\n\n59 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.\n\n# The timeline\n\n59 events from the 2024 audit to the latest capture, each dated as its source states it. Times are UTC; where this site converted from a local time, or inferred a date from a phrase such as *two days ago*, the row says so. A row that lists several sources is one that at least two accounts carry; a row with one source is that party's account.\n\n- stated the source states this date or time\n- inferred this site worked it out, and the note says how\n- disputed the sources give different times\n\n## Origins, 2024 to mid-2026\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2024 | Quarkslab audits PHP (funded through OSTIF and the Sovereign Tech Agency). While fixing one of its findings a PHP core developer finds the first signs of the out-of-memory problem behind CVE-2026-109618; an exploit is theorised but no vector found, so it is not fixed. | stated | PHP Foundation Calif BBC News |\n| 2026-06 | OpenAI launches Patch the Planet (a Daybreak initiative with Trail of Bits, HackerOne and Calif).The launch post is blocked; the June date is from a search snippet. The BBC says the PHP Foundation 'joined' in July; the Foundation says it 'got the PHP project into' the programme; Calif says OpenAI invited them. | inferred | OpenAI OpenAI |\n\n## Discovery, August 2026\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-07-30 | Calif begins an audit of PHP under Patch the Planet; Volker Dusch accepts the invitation. | stated | PHP Foundation Calif |\n| 2026-08-01 | Calif discovers 'multiple different paths independently leading to RCE that resurfaced the 2024 issues and new trigger points'. | stated | Calif |\n| 2026-08-05 15:54 UTC | Ryan Austin (@lcfr_hax) posts a SHA-256 hash on X as a commitment to one finding.Time as displayed in a UTC browser. The pre-image has not been published. | stated | Ryan Austin , Calif on X Calif |\n| 2026-08-19 | Wiz Research discovers the first vulnerability using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol; confirms RCE against Drupal on 20 August and WordPress on 21 August. | stated | Wiz |\n\n## Coordinated disclosure, August to 19 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-08-11 | Calif reports the first bug to PHP and coordinated disclosure begins. OpenAI independently reports the same root cause the same day. | stated | Calif PHP Foundation |\n| 2026-08-14 | Calif shares an RCE proof of concept with PHP; PHP confirms it works on 15 August. | stated | Calif |\n| 2026-08-21 | Calif reports the second bug to PHP. | stated | Calif |\n| 2026-08-24 | Wiz reports to the PHP security team. | stated | Wiz PHP Foundation |\n| 2026-08-27 | The GitHub security advisory is opened, credited to lcfr-hax, sagitzadik-wiz, amyb-oai and tomash-areion. | stated | Daubois |\n| 2026-09-18 | Further attack vectors reported by OpenAI. | stated | PHP Foundation |\n| 2026-09-21 | PHP acknowledges Wiz's reports 'and begins developing a coordinated fix'.Conflicts with the Foundation's account that the fix was the top priority from 11 August. | stated | Wiz |\n| 2026-09-25 | The fix pull request is opened. | stated | Daubois |\n| 2026-10 | Cloudflare starts developing WAF protections 'since early October 2026'. | stated | Cloudflare |\n| 2026-10-12 21:03:58 UTC | CVE-2026-109618 and CVE-2026-109619 are reserved. | stated | CVE record CVE record |\n| 2026-10-18 | The final fix commit is authored; the 7.4 backport branch's commit is dated 18:10:24Z. | stated | Daubois php-src |\n| 2026-10-19 14:00 UTC | Release commits for 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are made under embargo (14:00 to 17:04 UTC). | stated | php-src php-src |\n\n## The leak, 17 to 21 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-17 | An exploit attempt from an anonymisation-network IP hits an Amazon MadPot honeypot.As Amazon's CISO told The Hacker News; no primary Amazon post found. | stated | THN |\n| 2026-10-20 15:00 UTC | The two CVE IDs begin circulating on forums and social media with a wrong release time and a wrong CVSS of 10.0. Per Daubois: an anonymous Hacker News post, then screenshots, a 'PHP2Shell tool' screenshot credited to Calif.io, a short exploitation video, and watchTowr posting both CVE numbers.'around 15:00 UTC' per the Foundation. | stated | PHP Foundation Daubois |\n| 2026-10-20 19:30 UTC | php.net publishes the pre-announcement: release moved to 21 October 14:00 UTC, two critical vulnerabilities, CVSS v4.0 9.2, 'we reserve the right to release earlier'.19:30 UTC per the Foundation; the php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC. | disputed | PHP Foundation oss-security php.net |\n| 2026-10-20 20:00 UTC | Calif 'mistakenly published a video' showing its proof of concept against several targets; copies circulate after it is deleted.'around 20:00 UTC'. Calif's page does not mention it. | stated | PHP Foundation PHP Foundation |\n| 2026-10-20 20:22:51 UTC | Alan Coopersmith relays the php.net pre-announcement to oss-security. | stated | oss-security |\n| 2026-10-20 23:00 UTC | The PHP project starts giving mitigation advice to a few critical-infrastructure providers; it 'may have leaked as well'. | stated | PHP Foundation |\n| 2026-10-21 02:00 UTC | Amazon sees proof-of-concept attempts, then six hours of attempts from anonymised infrastructure. | stated | THN |\n| 2026-10-21 07:41 UTC | Chainguard publishes built images containing the fix, 'more than six hours before the coordinated release'.Chainguard reportedly denies leaking; that article is blocked. | stated | PHP Foundation Techzine |\n| 2026-10-21 08:36 UTC | ELLIO records its first sensor hit. | stated | THN PHP Foundation |\n\n## The release, 21 October 13:30 to 14:44 UTC\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-21 13:30 UTC | CERT-EU's stated release time for the PHP fixes.Differs from the planned 14:00 UTC and from the 13:35 UTC tags. | stated | CERT-EU |\n| 2026-10-21 13:32 UTC | Wiz posts 'BREAKING ... #PHP2SHELL ... impacting 70% of the Internet', 28 minutes before the planned release; the thread still says 'Apply the Oct 22 security release'. | stated | Wiz on X |\n| 2026-10-21 13:34:13 UTC | GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) and, twelve seconds later, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) are published by bukka. | stated | PHP PHP |\n| 2026-10-21 13:35:38 UTC | Signed tags php-8.5.12, php-8.4.27, php-8.3.36 and php-8.2.35 are created. | stated | php-src |\n| 2026-10-21 13:48:34 UTC | The CVE record for CVE-2026-109618 is published; CVE-2026-109619 follows at 13:54:43Z. | stated | CVE record CVE record |\n| 2026-10-21 14:00 UTC | The planned release time. php.net's advisory 'Critical remote code execution vulnerabilities, update now' and the four release posts go up. | stated | php.net oss-security Daubois |\n| 2026-10-21 14:04 UTC | OpenAI posts: models 'helped researchers ... discover critical security flaws in PHP ... used to run an estimated 70% of websites'. An X Community Note later disputes OpenAI's role. | stated | OpenAI on X |\n| 2026-10-21 14:06:46 UTC | GitHub release php-8.5.12 is published by adoy. | stated | php-src |\n| 2026-10-21 14:17:09 UTC | NVD publishes both CVEs with the CNA's CVSS v4.0 9.2 and no NIST score. | stated | NVD NVD |\n| 2026-10-21 14:41:54 UTC | Jakub Zelenka announces CVE-2026-109618 on oss-security; CVE-2026-109619 at 14:44:06Z. | stated | oss-security oss-security |\n\n## The response, 20 to 22 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-20 | Swiss BACS posts a warning (home-page teaser dated 20 October; the page itself now says 21 October). | inferred | Swiss BACS BACS |\n| 2026-10-21 | CISA alert 'Critical Vulnerabilities in PHP Require Immediate Patching': take systems offline if you cannot update. NSA press release 'PHP2Shell'. UK NCSC alert. CCCS AL26-026. CERT-FR ALE-014. ACN AL07/261021. Cloudflare, Wiz, Calif, the PHP Foundation and Daubois publish their accounts.Date only; none of these pages carries a time. | stated | CISA NSA NCSC UK CCCS CERT-FR ACN / CSIRT Italia Cloudflare Wiz Calif PHP Foundation Daubois |\n| 2026-10-21 03:02 UTC | Cloudflare's WAF protections go live for all customers, about nine hours ahead of disclosure. | stated | Cloudflare |\n| 2026-10-21 13:45:58 UTC | NSA Cybersecurity posts on X: 'Effective Immediately ... be prepared for an update addressing two critical vulnerabilities ... take the system offline'.Time decoded from the post's ID; the page shows 13:45. | stated | NSA Cyber on X |\n| 2026-10-21 14:04:39 UTC | CISA releases KEV catalog version 2026.10.21; neither PHP CVE is in it. | stated | CISA |\n| 2026-10-21 14:34 UTC | CISA's ADP assessment on both CVE records: exploitation none, automatable no, technical impact total. | stated | CVE record CVE record |\n| 2026-10-21 15:20 UTC | CERT-EU Security Advisory 2026-018 (stated 15:20:18, timezone not given). | inferred | CERT-EU |\n| 2026-10-21 15:25 UTC | NCSC-NL's php2shell README last significant change (17:25 CEST). CERT.LV publishes: Latvia restricts access to several state digital resources from abroad (18:25 EEST).Both converted to UTC by this site. | stated | NCSC-NL CERT.LV |\n| 2026-10-21 20:00 UTC | CERT.LV update: the unified state website platform is patched; lsm.lv and 112.lv restored; about 6,000 potentially affected resources in Latvia; automated attempts seen, none successful. | stated | CERT.LV |\n| 2026-10-21 20:15 UTC | NCSC New Zealand: 'aware of reports of active exploitation' (09:15 NZDT 22 October; updated 21:20Z).Converted from NZDT. | stated | NCSC New Zealand |\n| 2026-10-22 00:43:58 UTC | NSA Cybersecurity posts 'UPDATE: Specific mitigation guidance ... is now available', linking the press release. | stated | NSA Cyber on X NSA |\n| 2026-10-22 05:20 UTC | JVN publishes its note (14:20 JST); JPCERT/CC alert JPCERT-AT-2026-0033 is dated 22 October. | stated | JPCERT/CC JPCERT/CC |\n\n## Aftermath, 21 to 22 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-21 15:24:37 UTC | Aaron Rainbolt relays to oss-security a Fediverse report that the 8.5.12 fix may be incomplete; a Debian maintainer adds that the poster called it a different bug. | stated | oss-security |\n| 2026-10-21 17:29 UTC | Per a Matrix channel, Canonical asked PHP about the Fediverse report and was told it is 'unrelated and not a real issue'.Second-hand. | stated | oss-security |\n| 2026-10-22 | The Hacker News publishes Amazon's account of the 17 October honeypot attempt and VulnCheck's count of 2,608,039 hosts. | stated | THN |\n| 2026-10-22 06:16:24 UTC | BBC News opens its live page: 'Global scramble to fix critical cyber-security flaws as many websites taken offline'. | stated | BBC News |\n| 2026-10-22 06:45:47 UTC | Greenbone on oss-security: the backports imply versions down to 7.4 are affected, whatever the subject line says. | stated | oss-security |\n| 2026-10-22 06:55:50 UTC | The BBC reports the NSA's X post. | stated | BBC News |\n| 2026-10-22 07:00 UTC | Ryan Austin on BBC Radio 4: no evidence of exploitation yet.08:00 BST post. | stated | BBC News |\n| 2026-10-22 07:30:02 UTC | The UK NCSC page is modified (HTTP last-modified). | stated | NCSC UK |\n| 2026-10-22 08:40:58 UTC | NCSC-NL merges pull request 10; the inventory has 674 entries at commit cca173c64ec5. | stated | NCSC-NL NCSC-NL |\n\n## This site\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-22 08:03 UTC | The evidence vault behind this site is opened; the first capture of the BBC live page is at 08:04:53Z. | stated | BBC News |\n\nThe sequence as a graph of who said what first is on Who found it; the leak alone is on How disclosure broke."
    },
    {
     "v": 2,
     "hash": "6d460e9764fb",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The timeline, 2024 to the latest capture\n\n68 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.\n\n# The timeline\n\n68 events from the 2024 audit to the latest capture, each dated as its source states it. Times are UTC; where this site converted from a local time, or inferred a date from a phrase such as *two days ago*, the row says so. A row that lists several sources is one that at least two accounts carry; a row with one source is that party's account.\n\n- stated the source states this date or time\n- inferred this site worked it out, and the note says how\n- disputed the sources give different times\n\n## Origins, 2024 to mid-2026\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2024 | Quarkslab audits PHP (funded through OSTIF and the Sovereign Tech Agency). While fixing one of its findings a PHP core developer finds the first signs of the out-of-memory problem behind CVE-2026-109618; an exploit is theorised but no vector found, so it is not fixed. | stated | PHP Foundation Calif BBC News |\n| 2026-06 | OpenAI launches Patch the Planet (a Daybreak initiative with Trail of Bits, HackerOne and Calif).The launch post is blocked; the June date is from a search snippet. The BBC says the PHP Foundation 'joined' in July; the Foundation says it 'got the PHP project into' the programme; Calif says OpenAI invited them. | inferred | OpenAI OpenAI |\n\n## Discovery, August 2026\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-07-30 | Calif begins an audit of PHP under Patch the Planet; Volker Dusch accepts the invitation. | stated | PHP Foundation Calif |\n| 2026-08-01 | Calif discovers 'multiple different paths independently leading to RCE that resurfaced the 2024 issues and new trigger points'. | stated | Calif |\n| 2026-08-05 15:54 UTC | Ryan Austin (@lcfr_hax) posts a SHA-256 hash on X as a commitment to one finding.Time as displayed in a UTC browser. The pre-image has not been published. | stated | Ryan Austin , Calif on X Calif |\n| 2026-08-19 | Wiz Research discovers the first vulnerability using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol; confirms RCE against Drupal on 20 August and WordPress on 21 August. | stated | Wiz |\n\n## Coordinated disclosure, August to 19 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-08-11 | Calif reports the first bug to PHP and coordinated disclosure begins. OpenAI independently reports the same root cause the same day. | stated | Calif PHP Foundation |\n| 2026-08-14 | Calif shares an RCE proof of concept with PHP; PHP confirms it works on 15 August. | stated | Calif |\n| 2026-08-21 | Calif reports the second bug to PHP. | stated | Calif |\n| 2026-08-24 | Wiz reports to the PHP security team. | stated | Wiz PHP Foundation |\n| 2026-08-27 | The GitHub security advisory is opened, credited to lcfr-hax, sagitzadik-wiz, amyb-oai and tomash-areion. | stated | Daubois |\n| 2026-09-18 | Further attack vectors reported by OpenAI. | stated | PHP Foundation |\n| 2026-09-21 | PHP acknowledges Wiz's reports 'and begins developing a coordinated fix'.Conflicts with the Foundation's account that the fix was the top priority from 11 August. | stated | Wiz |\n| 2026-09-25 | The fix pull request is opened. | stated | Daubois |\n| 2026-10 | Cloudflare starts developing WAF protections 'since early October 2026'. | stated | Cloudflare |\n| 2026-10-12 21:03:58 UTC | CVE-2026-109618 and CVE-2026-109619 are reserved. | stated | CVE record CVE record |\n| 2026-10-18 | The final fix commit is authored; the 7.4 backport branch's commit is dated 18:10:24Z. | stated | Daubois php-src |\n| 2026-10-18 15:26:39 UTC | Arnaud Le Blanc authors the fix, 'Avoid state corruption via bailout', with Ilija Tovilo, Jakub Zelenka, Nora Dossche and Nicolas Grekas; the 7.4 minimal backport is authored at 18:09 UTC.Author timestamps from the commits. | stated | php/php-src , read from a clone |\n| 2026-10-19 14:00 UTC | Release commits for 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are made under embargo (14:00 to 17:04 UTC). | stated | php-src php-src |\n\n## The leak, 17 to 21 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-17 | An exploit attempt from an anonymisation-network IP hits an Amazon MadPot honeypot.As Amazon's CISO told The Hacker News; no primary Amazon post found. | stated | THN |\n| 2026-10-20 | Qualys publishes on the pre-announcement. | stated | Qualys |\n| 2026-10-20 15:00 UTC | The two CVE IDs begin circulating on forums and social media with a wrong release time and a wrong CVSS of 10.0. Per Daubois: an anonymous Hacker News post, then screenshots, a 'PHP2Shell tool' screenshot credited to Calif.io, a short exploitation video, and watchTowr posting both CVE numbers.'around 15:00 UTC' per the Foundation. | stated | PHP Foundation Daubois |\n| 2026-10-20 19:30 UTC | php.net publishes the pre-announcement: release moved to 21 October 14:00 UTC, two critical vulnerabilities, CVSS v4.0 9.2, 'we reserve the right to release earlier'.19:30 UTC per the Foundation; the php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC. | disputed | PHP Foundation oss-security php.net |\n| 2026-10-20 20:00 UTC | Calif 'mistakenly published a video' showing its proof of concept against several targets; copies circulate after it is deleted.'around 20:00 UTC'. Calif's page does not mention it. | stated | PHP Foundation PHP Foundation |\n| 2026-10-20 20:22:51 UTC | Alan Coopersmith relays the php.net pre-announcement to oss-security. | stated | oss-security |\n| 2026-10-20 23:00 UTC | The PHP project starts giving mitigation advice to a few critical-infrastructure providers; it 'may have leaked as well'. | stated | PHP Foundation |\n| 2026-10-21 02:00 UTC | Amazon sees proof-of-concept attempts, then six hours of attempts from anonymised infrastructure. | stated | THN |\n| 2026-10-21 07:41 UTC | Chainguard publishes built images containing the fix, 'more than six hours before the coordinated release'.Chainguard reportedly denies leaking; that article is blocked. | stated | PHP Foundation Techzine |\n| 2026-10-21 07:43 UTC | Cloudflare's CTO reports early attacks emerging, before the release.Second-hand; the post itself is not captured. | stated | Insurance Business SecurityWeek |\n| 2026-10-21 08:36 UTC | ELLIO records its first sensor hit. | stated | THN PHP Foundation |\n\n## The release, 21 October 13:30 to 14:44 UTC\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-21 13:30 UTC | CERT-EU's stated release time for the PHP fixes.Differs from the planned 14:00 UTC and from the 13:35 UTC tags. | stated | CERT-EU |\n| 2026-10-21 13:32 UTC | Wiz posts 'BREAKING ... #PHP2SHELL ... impacting 70% of the Internet', 28 minutes before the planned release; the thread still says 'Apply the Oct 22 security release'. | stated | Wiz on X |\n| 2026-10-21 13:34:13 UTC | GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) and, twelve seconds later, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) are published by bukka. | stated | PHP PHP |\n| 2026-10-21 13:35:38 UTC | Signed tags php-8.5.12, php-8.4.27, php-8.3.36 and php-8.2.35 are created. | stated | php-src |\n| 2026-10-21 13:48:34 UTC | The CVE record for CVE-2026-109618 is published; CVE-2026-109619 follows at 13:54:43Z. | stated | CVE record CVE record |\n| 2026-10-21 14:00 UTC | The planned release time. php.net's advisory 'Critical remote code execution vulnerabilities, update now' and the four release posts go up. | stated | php.net oss-security Daubois |\n| 2026-10-21 14:04 UTC | OpenAI posts: models 'helped researchers ... discover critical security flaws in PHP ... used to run an estimated 70% of websites'. An X Community Note later disputes OpenAI's role. | stated | OpenAI on X |\n| 2026-10-21 14:06:22 UTC | The fix commit enters the public php-src branches (commit timestamp); merged into 8.3 at 14:12, 8.4 at 14:27 and 8.5 at 14:30 UTC. | stated | php/php-src , read from a clone |\n| 2026-10-21 14:06:46 UTC | GitHub release php-8.5.12 is published by adoy. | stated | php-src |\n| 2026-10-21 14:17:09 UTC | NVD publishes both CVEs with the CNA's CVSS v4.0 9.2 and no NIST score. | stated | NVD NVD |\n| 2026-10-21 14:41:54 UTC | Jakub Zelenka announces CVE-2026-109618 on oss-security; CVE-2026-109619 at 14:44:06Z. | stated | oss-security oss-security |\n\n## The response, 20 to 22 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-20 | Swiss BACS posts a warning (home-page teaser dated 20 October; the page itself now says 21 October). | inferred | Swiss BACS BACS |\n| 2026-10-21 | CISA alert 'Critical Vulnerabilities in PHP Require Immediate Patching': take systems offline if you cannot update. NSA press release 'PHP2Shell'. UK NCSC alert. CCCS AL26-026. CERT-FR ALE-014. ACN AL07/261021. Cloudflare, Wiz, Calif, the PHP Foundation and Daubois publish their accounts.Date only; none of these pages carries a time. | stated | CISA NSA NCSC UK CCCS CERT-FR ACN / CSIRT Italia Cloudflare Wiz Calif PHP Foundation Daubois |\n| 2026-10-21 | The Dutch NCSC takes its own website offline as a precaution; DigiD, MijnOverheid and Overheid.nl follow. Weird Gloop turns off its wiki web servers for 13 hours. Amazon, Imperva, Fastly, Akamai and Huntress publish. | stated | Rijksoverheid / NCSC-NL Weird Gloop Amazon Imperva Threat Research Fastly Akamai Security Research Huntress |\n| 2026-10-21 03:02 UTC | Cloudflare's WAF protections go live for all customers, about nine hours ahead of disclosure. | stated | Cloudflare |\n| 2026-10-21 09:45 UTC | Finland's Valtori begins restricting public traffic to government web services (12:45 local).Converted from Finnish time. | inferred | Helsinki Times Yle |\n| 2026-10-21 13:45:58 UTC | NSA Cybersecurity posts on X: 'Effective Immediately ... be prepared for an update addressing two critical vulnerabilities ... take the system offline'.Time decoded from the post's ID; the page shows 13:45. | stated | NSA Cyber on X |\n| 2026-10-21 14:04:39 UTC | CISA releases KEV catalog version 2026.10.21; neither PHP CVE is in it. | stated | CISA |\n| 2026-10-21 14:34 UTC | CISA's ADP assessment on both CVE records: exploitation none, automatable no, technical impact total. | stated | CVE record CVE record |\n| 2026-10-21 15:20 UTC | CERT-EU Security Advisory 2026-018 (stated 15:20:18, timezone not given). | inferred | CERT-EU |\n| 2026-10-21 15:25 UTC | NCSC-NL's php2shell README last significant change (17:25 CEST). CERT.LV publishes: Latvia restricts access to several state digital resources from abroad (18:25 EEST).Both converted to UTC by this site. | stated | NCSC-NL CERT.LV |\n| 2026-10-21 20:00 UTC | CERT.LV update: the unified state website platform is patched; lsm.lv and 112.lv restored; about 6,000 potentially affected resources in Latvia; automated attempts seen, none successful. | stated | CERT.LV |\n| 2026-10-21 20:15 UTC | NCSC New Zealand: 'aware of reports of active exploitation' (09:15 NZDT 22 October; updated 21:20Z).Converted from NZDT. | stated | NCSC New Zealand |\n| 2026-10-22 00:43:58 UTC | NSA Cybersecurity posts 'UPDATE: Specific mitigation guidance ... is now available', linking the press release. | stated | NSA Cyber on X NSA |\n| 2026-10-22 05:20 UTC | JVN publishes its note (14:20 JST); JPCERT/CC alert JPCERT-AT-2026-0033 is dated 22 October. | stated | JPCERT/CC JPCERT/CC |\n\n## Aftermath, 21 to 22 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-21 15:24:37 UTC | Aaron Rainbolt relays to oss-security a Fediverse report that the 8.5.12 fix may be incomplete; a Debian maintainer adds that the poster called it a different bug. | stated | oss-security |\n| 2026-10-21 17:29 UTC | Per a Matrix channel, Canonical asked PHP about the Fediverse report and was told it is 'unrelated and not a real issue'.Second-hand. | stated | oss-security |\n| 2026-10-21 20:30 UTC | Huntress: no exploitation observed on partner systems (16:30 ET).Converted from Eastern time. | stated | Huntress |\n| 2026-10-22 | The Hacker News publishes Amazon's account of the 17 October honeypot attempt and VulnCheck's count of 2,608,039 hosts. | stated | THN |\n| 2026-10-22 | The Register carries Dan Lorenc's reply to the PHP Foundation; Fortinet publishes FortiWeb signatures; The Record carries the Foundation's account of the 2024 signs. | stated | The Register Fortinet Community The Record |\n| 2026-10-22 01:25 UTC | Matthew Prince posts Cloudflare's attempt counts: thousands before, millions after. | stated | Matthew Prince , Cloudflare CEO on |\n| 2026-10-22 06:16:24 UTC | BBC News opens its live page: 'Global scramble to fix critical cyber-security flaws as many websites taken offline'. | stated | BBC News |\n| 2026-10-22 06:45:47 UTC | Greenbone on oss-security: the backports imply versions down to 7.4 are affected, whatever the subject line says. | stated | oss-security |\n| 2026-10-22 06:55:50 UTC | The BBC reports the NSA's X post. | stated | BBC News |\n| 2026-10-22 07:00 UTC | Ryan Austin on BBC Radio 4: no evidence of exploitation yet.08:00 BST post. | stated | BBC News |\n| 2026-10-22 07:30:02 UTC | The UK NCSC page is modified (HTTP last-modified). | stated | NCSC UK |\n| 2026-10-22 08:40:58 UTC | NCSC-NL merges pull request 10; the inventory has 674 entries at commit cca173c64ec5. | stated | NCSC-NL NCSC-NL |\n\n## This site\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-22 08:03 UTC | The evidence vault behind this site is opened; the first capture of the BBC live page is at 08:04:53Z. | stated | BBC News |\n\nThe sequence as a graph of who said what first is on Who found it; the leak alone is on How disclosure broke."
    },
    {
     "v": 3,
     "hash": "6aed6027cc8e",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The timeline, 2024 to the latest capture\n\n68 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.\n\n# The timeline\n\nIn plain English Everything that happened, in order, from a 2024 audit to this morning, each line tied to the page that says so.\n\n68 events from the 2024 audit to the latest capture, each dated as its source states it. Times are UTC; where this site converted from a local time, or inferred a date from a phrase such as *two days ago*, the row says so. A row that lists several sources is one that at least two accounts carry; a row with one source is that party's account.\n\n- stated the source states this date or time\n- inferred this site worked it out, and the note says how\n- disputed the sources give different times\n\n## Origins, 2024 to mid-2026\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2024 | Quarkslab audits PHP (funded through OSTIF and the Sovereign Tech Agency). While fixing one of its findings a PHP core developer finds the first signs of the out-of-memory problem behind CVE-2026-109618; an exploit is theorised but no vector found, so it is not fixed. | stated | PHP Foundation Calif BBC News |\n| 2026-06 | OpenAI launches Patch the Planet (a Daybreak initiative with Trail of Bits, HackerOne and Calif).The launch post is blocked; the June date is from a search snippet. The BBC says the PHP Foundation 'joined' in July; the Foundation says it 'got the PHP project into' the programme; Calif says OpenAI invited them. | inferred | OpenAI OpenAI |\n\n## Discovery, August 2026\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-07-30 | Calif begins an audit of PHP under Patch the Planet; Volker Dusch accepts the invitation. | stated | PHP Foundation Calif |\n| 2026-08-01 | Calif discovers 'multiple different paths independently leading to RCE that resurfaced the 2024 issues and new trigger points'. | stated | Calif |\n| 2026-08-05 15:54 UTC | Ryan Austin (@lcfr_hax) posts a SHA-256 hash on X as a commitment to one finding.Time as displayed in a UTC browser. The pre-image has not been published. | stated | Ryan Austin , Calif on X Calif |\n| 2026-08-19 | Wiz Research discovers the first vulnerability using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol; confirms RCE against Drupal on 20 August and WordPress on 21 August. | stated | Wiz |\n\n## Coordinated disclosure, August to 19 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-08-11 | Calif reports the first bug to PHP and coordinated disclosure begins. OpenAI independently reports the same root cause the same day. | stated | Calif PHP Foundation |\n| 2026-08-14 | Calif shares an RCE proof of concept with PHP; PHP confirms it works on 15 August. | stated | Calif |\n| 2026-08-21 | Calif reports the second bug to PHP. | stated | Calif |\n| 2026-08-24 | Wiz reports to the PHP security team. | stated | Wiz PHP Foundation |\n| 2026-08-27 | The GitHub security advisory is opened, credited to lcfr-hax, sagitzadik-wiz, amyb-oai and tomash-areion. | stated | Daubois |\n| 2026-09-18 | Further attack vectors reported by OpenAI. | stated | PHP Foundation |\n| 2026-09-21 | PHP acknowledges Wiz's reports 'and begins developing a coordinated fix'.Conflicts with the Foundation's account that the fix was the top priority from 11 August. | stated | Wiz |\n| 2026-09-25 | The fix pull request is opened. | stated | Daubois |\n| 2026-10 | Cloudflare starts developing WAF protections 'since early October 2026'. | stated | Cloudflare |\n| 2026-10-12 21:03:58 UTC | CVE-2026-109618 and CVE-2026-109619 are reserved. | stated | CVE record CVE record |\n| 2026-10-18 | The final fix commit is authored; the 7.4 backport branch's commit is dated 18:10:24Z. | stated | Daubois php-src |\n| 2026-10-18 15:26:39 UTC | Arnaud Le Blanc authors the fix, 'Avoid state corruption via bailout', with Ilija Tovilo, Jakub Zelenka, Nora Dossche and Nicolas Grekas; the 7.4 minimal backport is authored at 18:09 UTC.Author timestamps from the commits. | stated | php/php-src , read from a clone |\n| 2026-10-19 14:00 UTC | Release commits for 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are made under embargo (14:00 to 17:04 UTC). | stated | php-src php-src |\n\n## The leak, 17 to 21 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-17 | An exploit attempt from an anonymisation-network IP hits an Amazon MadPot honeypot.As Amazon's CISO told The Hacker News; no primary Amazon post found. | stated | THN |\n| 2026-10-20 | Qualys publishes on the pre-announcement. | stated | Qualys |\n| 2026-10-20 15:00 UTC | The two CVE IDs begin circulating on forums and social media with a wrong release time and a wrong CVSS of 10.0. Per Daubois: an anonymous Hacker News post, then screenshots, a 'PHP2Shell tool' screenshot credited to Calif.io, a short exploitation video, and watchTowr posting both CVE numbers.'around 15:00 UTC' per the Foundation. | stated | PHP Foundation Daubois |\n| 2026-10-20 19:30 UTC | php.net publishes the pre-announcement: release moved to 21 October 14:00 UTC, two critical vulnerabilities, CVSS v4.0 9.2, 'we reserve the right to release earlier'.19:30 UTC per the Foundation; the php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC. | disputed | PHP Foundation oss-security php.net |\n| 2026-10-20 20:00 UTC | Calif 'mistakenly published a video' showing its proof of concept against several targets; copies circulate after it is deleted.'around 20:00 UTC'. Calif's page does not mention it. | stated | PHP Foundation PHP Foundation |\n| 2026-10-20 20:22:51 UTC | Alan Coopersmith relays the php.net pre-announcement to oss-security. | stated | oss-security |\n| 2026-10-20 23:00 UTC | The PHP project starts giving mitigation advice to a few critical-infrastructure providers; it 'may have leaked as well'. | stated | PHP Foundation |\n| 2026-10-21 02:00 UTC | Amazon sees proof-of-concept attempts, then six hours of attempts from anonymised infrastructure. | stated | THN |\n| 2026-10-21 07:41 UTC | Chainguard publishes built images containing the fix, 'more than six hours before the coordinated release'.Chainguard reportedly denies leaking; that article is blocked. | stated | PHP Foundation Techzine |\n| 2026-10-21 07:43 UTC | Cloudflare's CTO reports early attacks emerging, before the release.Second-hand; the post itself is not captured. | stated | Insurance Business SecurityWeek |\n| 2026-10-21 08:36 UTC | ELLIO records its first sensor hit. | stated | THN PHP Foundation |\n\n## The release, 21 October 13:30 to 14:44 UTC\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-21 13:30 UTC | CERT-EU's stated release time for the PHP fixes.Differs from the planned 14:00 UTC and from the 13:35 UTC tags. | stated | CERT-EU |\n| 2026-10-21 13:32 UTC | Wiz posts 'BREAKING ... #PHP2SHELL ... impacting 70% of the Internet', 28 minutes before the planned release; the thread still says 'Apply the Oct 22 security release'. | stated | Wiz on X |\n| 2026-10-21 13:34:13 UTC | GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) and, twelve seconds later, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) are published by bukka. | stated | PHP PHP |\n| 2026-10-21 13:35:38 UTC | Signed tags php-8.5.12, php-8.4.27, php-8.3.36 and php-8.2.35 are created. | stated | php-src |\n| 2026-10-21 13:48:34 UTC | The CVE record for CVE-2026-109618 is published; CVE-2026-109619 follows at 13:54:43Z. | stated | CVE record CVE record |\n| 2026-10-21 14:00 UTC | The planned release time. php.net's advisory 'Critical remote code execution vulnerabilities, update now' and the four release posts go up. | stated | php.net oss-security Daubois |\n| 2026-10-21 14:04 UTC | OpenAI posts: models 'helped researchers ... discover critical security flaws in PHP ... used to run an estimated 70% of websites'. An X Community Note later disputes OpenAI's role. | stated | OpenAI on X |\n| 2026-10-21 14:06:22 UTC | The fix commit enters the public php-src branches (commit timestamp); merged into 8.3 at 14:12, 8.4 at 14:27 and 8.5 at 14:30 UTC. | stated | php/php-src , read from a clone |\n| 2026-10-21 14:06:46 UTC | GitHub release php-8.5.12 is published by adoy. | stated | php-src |\n| 2026-10-21 14:17:09 UTC | NVD publishes both CVEs with the CNA's CVSS v4.0 9.2 and no NIST score. | stated | NVD NVD |\n| 2026-10-21 14:41:54 UTC | Jakub Zelenka announces CVE-2026-109618 on oss-security; CVE-2026-109619 at 14:44:06Z. | stated | oss-security oss-security |\n\n## The response, 20 to 22 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-20 | Swiss BACS posts a warning (home-page teaser dated 20 October; the page itself now says 21 October). | inferred | Swiss BACS BACS |\n| 2026-10-21 | CISA alert 'Critical Vulnerabilities in PHP Require Immediate Patching': take systems offline if you cannot update. NSA press release 'PHP2Shell'. UK NCSC alert. CCCS AL26-026. CERT-FR ALE-014. ACN AL07/261021. Cloudflare, Wiz, Calif, the PHP Foundation and Daubois publish their accounts.Date only; none of these pages carries a time. | stated | CISA NSA NCSC UK CCCS CERT-FR ACN / CSIRT Italia Cloudflare Wiz Calif PHP Foundation Daubois |\n| 2026-10-21 | The Dutch NCSC takes its own website offline as a precaution; DigiD, MijnOverheid and Overheid.nl follow. Weird Gloop turns off its wiki web servers for 13 hours. Amazon, Imperva, Fastly, Akamai and Huntress publish. | stated | Rijksoverheid / NCSC-NL Weird Gloop Amazon Imperva Threat Research Fastly Akamai Security Research Huntress |\n| 2026-10-21 03:02 UTC | Cloudflare's WAF protections go live for all customers, about nine hours ahead of disclosure. | stated | Cloudflare |\n| 2026-10-21 09:45 UTC | Finland's Valtori begins restricting public traffic to government web services (12:45 local).Converted from Finnish time. | inferred | Helsinki Times Yle |\n| 2026-10-21 13:45:58 UTC | NSA Cybersecurity posts on X: 'Effective Immediately ... be prepared for an update addressing two critical vulnerabilities ... take the system offline'.Time decoded from the post's ID; the page shows 13:45. | stated | NSA Cyber on X |\n| 2026-10-21 14:04:39 UTC | CISA releases KEV catalog version 2026.10.21; neither PHP CVE is in it. | stated | CISA |\n| 2026-10-21 14:34 UTC | CISA's ADP assessment on both CVE records: exploitation none, automatable no, technical impact total. | stated | CVE record CVE record |\n| 2026-10-21 15:20 UTC | CERT-EU Security Advisory 2026-018 (stated 15:20:18, timezone not given). | inferred | CERT-EU |\n| 2026-10-21 15:25 UTC | NCSC-NL's php2shell README last significant change (17:25 CEST). CERT.LV publishes: Latvia restricts access to several state digital resources from abroad (18:25 EEST).Both converted to UTC by this site. | stated | NCSC-NL CERT.LV |\n| 2026-10-21 20:00 UTC | CERT.LV update: the unified state website platform is patched; lsm.lv and 112.lv restored; about 6,000 potentially affected resources in Latvia; automated attempts seen, none successful. | stated | CERT.LV |\n| 2026-10-21 20:15 UTC | NCSC New Zealand: 'aware of reports of active exploitation' (09:15 NZDT 22 October; updated 21:20Z).Converted from NZDT. | stated | NCSC New Zealand |\n| 2026-10-22 00:43:58 UTC | NSA Cybersecurity posts 'UPDATE: Specific mitigation guidance ... is now available', linking the press release. | stated | NSA Cyber on X NSA |\n| 2026-10-22 05:20 UTC | JVN publishes its note (14:20 JST); JPCERT/CC alert JPCERT-AT-2026-0033 is dated 22 October. | stated | JPCERT/CC JPCERT/CC |\n\n## Aftermath, 21 to 22 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-21 15:24:37 UTC | Aaron Rainbolt relays to oss-security a Fediverse report that the 8.5.12 fix may be incomplete; a Debian maintainer adds that the poster called it a different bug. | stated | oss-security |\n| 2026-10-21 17:29 UTC | Per a Matrix channel, Canonical asked PHP about the Fediverse report and was told it is 'unrelated and not a real issue'.Second-hand. | stated | oss-security |\n| 2026-10-21 20:30 UTC | Huntress: no exploitation observed on partner systems (16:30 ET).Converted from Eastern time. | stated | Huntress |\n| 2026-10-22 | The Hacker News publishes Amazon's account of the 17 October honeypot attempt and VulnCheck's count of 2,608,039 hosts. | stated | THN |\n| 2026-10-22 | The Register carries Dan Lorenc's reply to the PHP Foundation; Fortinet publishes FortiWeb signatures; The Record carries the Foundation's account of the 2024 signs. | stated | The Register Fortinet Community The Record |\n| 2026-10-22 01:25 UTC | Matthew Prince posts Cloudflare's attempt counts: thousands before, millions after. | stated | Matthew Prince , Cloudflare CEO on |\n| 2026-10-22 06:16:24 UTC | BBC News opens its live page: 'Global scramble to fix critical cyber-security flaws as many websites taken offline'. | stated | BBC News |\n| 2026-10-22 06:45:47 UTC | Greenbone on oss-security: the backports imply versions down to 7.4 are affected, whatever the subject line says. | stated | oss-security |\n| 2026-10-22 06:55:50 UTC | The BBC reports the NSA's X post. | stated | BBC News |\n| 2026-10-22 07:00 UTC | Ryan Austin on BBC Radio 4: no evidence of exploitation yet.08:00 BST post. | stated | BBC News |\n| 2026-10-22 07:30:02 UTC | The UK NCSC page is modified (HTTP last-modified). | stated | NCSC UK |\n| 2026-10-22 08:40:58 UTC | NCSC-NL merges pull request 10; the inventory has 674 entries at commit cca173c64ec5. | stated | NCSC-NL NCSC-NL |\n\n## This site\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-22 08:03 UTC | The evidence vault behind this site is opened; the first capture of the BBC live page is at 08:04:53Z. | stated | BBC News |\n\nThe sequence as a graph of who said what first is on Who found it; the leak alone is on How disclosure broke."
    },
    {
     "v": 4,
     "hash": "21ed012b2ce0",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The timeline, 2024 to the latest capture\n\n68 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.\n\n# The timeline\n\nIn plain English Everything that happened, in order, from a 2024 audit to this morning, each line tied to the page that says so.\n\n68 events from the 2024 audit to the latest capture, each dated as its source states it. Times are UTC; where this site converted from a local time, or inferred a date from a phrase such as *two days ago*, the row says so. A row that lists several sources is one that at least two accounts carry; a row with one source is that party's account.\n\n- stated the source states this date or time\n- inferred this site worked it out, and the note says how\n- disputed the sources give different times\n\n## Origins, 2024 to mid-2026\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2024 | Quarkslab audits PHP (funded through OSTIF and the Sovereign Tech Agency). While fixing one of its findings a PHP core developer finds the first signs of the out-of-memory problem behind CVE-2026-109618; an exploit is theorised but no vector found, so it is not fixed. | stated | PHP Foundation Calif BBC News |\n| 2026-06 | OpenAI launches Patch the Planet (a Daybreak initiative with Trail of Bits, HackerOne and Calif).The launch post is blocked; the June date is from a search snippet. The BBC says the PHP Foundation 'joined' in July; the Foundation says it 'got the PHP project into' the programme; Calif says OpenAI invited them. | inferred | OpenAI OpenAI |\n\n## Discovery, August 2026\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-07-30 | Calif begins an audit of PHP under Patch the Planet; Volker Dusch accepts the invitation. | stated | PHP Foundation Calif |\n| 2026-08-01 | Calif discovers 'multiple different paths independently leading to RCE that resurfaced the 2024 issues and new trigger points'. | stated | Calif |\n| 2026-08-05 15:54 UTC | Ryan Austin (@lcfr_hax) posts a SHA-256 hash on X as a commitment to one finding.Time as displayed in a UTC browser. The pre-image has not been published. | stated | Ryan Austin, Calif on X Calif |\n| 2026-08-19 | Wiz Research discovers the first vulnerability using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol; confirms RCE against Drupal on 20 August and WordPress on 21 August. | stated | Wiz |\n\n## Coordinated disclosure, August to 19 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-08-11 | Calif reports the first bug to PHP and coordinated disclosure begins. OpenAI independently reports the same root cause the same day. | stated | Calif PHP Foundation |\n| 2026-08-14 | Calif shares an RCE proof of concept with PHP; PHP confirms it works on 15 August. | stated | Calif |\n| 2026-08-21 | Calif reports the second bug to PHP. | stated | Calif |\n| 2026-08-24 | Wiz reports to the PHP security team. | stated | Wiz PHP Foundation |\n| 2026-08-27 | The GitHub security advisory is opened, credited to lcfr-hax, sagitzadik-wiz, amyb-oai and tomash-areion. | stated | Daubois |\n| 2026-09-18 | Further attack vectors reported by OpenAI. | stated | PHP Foundation |\n| 2026-09-21 | PHP acknowledges Wiz's reports 'and begins developing a coordinated fix'.Conflicts with the Foundation's account that the fix was the top priority from 11 August. | stated | Wiz |\n| 2026-09-25 | The fix pull request is opened. | stated | Daubois |\n| 2026-10 | Cloudflare starts developing WAF protections 'since early October 2026'. | stated | Cloudflare |\n| 2026-10-12 21:03:58 UTC | CVE-2026-109618 and CVE-2026-109619 are reserved. | stated | CVE record CVE record |\n| 2026-10-18 | The final fix commit is authored; the 7.4 backport branch's commit is dated 18:10:24Z. | stated | Daubois php-src |\n| 2026-10-18 15:26:39 UTC | Arnaud Le Blanc authors the fix, 'Avoid state corruption via bailout', with Ilija Tovilo, Jakub Zelenka, Nora Dossche and Nicolas Grekas; the 7.4 minimal backport is authored at 18:09 UTC.Author timestamps from the commits. | stated | php/php-src, read from a clone |\n| 2026-10-19 14:00 UTC | Release commits for 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are made under embargo (14:00 to 17:04 UTC). | stated | php-src php-src |\n\n## The leak, 17 to 21 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-17 | An exploit attempt from an anonymisation-network IP hits an Amazon MadPot honeypot.As Amazon's CISO told The Hacker News; no primary Amazon post found. | stated | THN |\n| 2026-10-20 | Qualys publishes on the pre-announcement. | stated | Qualys |\n| 2026-10-20 15:00 UTC | The two CVE IDs begin circulating on forums and social media with a wrong release time and a wrong CVSS of 10.0. Per Daubois: an anonymous Hacker News post, then screenshots, a 'PHP2Shell tool' screenshot credited to Calif.io, a short exploitation video, and watchTowr posting both CVE numbers.'around 15:00 UTC' per the Foundation. | stated | PHP Foundation Daubois |\n| 2026-10-20 19:30 UTC | php.net publishes the pre-announcement: release moved to 21 October 14:00 UTC, two critical vulnerabilities, CVSS v4.0 9.2, 'we reserve the right to release earlier'.19:30 UTC per the Foundation; the php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC. | disputed | PHP Foundation oss-security php.net |\n| 2026-10-20 20:00 UTC | Calif 'mistakenly published a video' showing its proof of concept against several targets; copies circulate after it is deleted.'around 20:00 UTC'. Calif's page does not mention it. | stated | PHP Foundation PHP Foundation |\n| 2026-10-20 20:22:51 UTC | Alan Coopersmith relays the php.net pre-announcement to oss-security. | stated | oss-security |\n| 2026-10-20 23:00 UTC | The PHP project starts giving mitigation advice to a few critical-infrastructure providers; it 'may have leaked as well'. | stated | PHP Foundation |\n| 2026-10-21 02:00 UTC | Amazon sees proof-of-concept attempts, then six hours of attempts from anonymised infrastructure. | stated | THN |\n| 2026-10-21 07:41 UTC | Chainguard publishes built images containing the fix, 'more than six hours before the coordinated release'.Chainguard reportedly denies leaking; that article is blocked. | stated | PHP Foundation Techzine |\n| 2026-10-21 07:43 UTC | Cloudflare's CTO reports early attacks emerging, before the release.Second-hand; the post itself is not captured. | stated | Insurance Business SecurityWeek |\n| 2026-10-21 08:36 UTC | ELLIO records its first sensor hit. | stated | THN PHP Foundation |\n\n## The release, 21 October 13:30 to 14:44 UTC\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-21 13:30 UTC | CERT-EU's stated release time for the PHP fixes.Differs from the planned 14:00 UTC and from the 13:35 UTC tags. | stated | CERT-EU |\n| 2026-10-21 13:32 UTC | Wiz posts 'BREAKING ... #PHP2SHELL ... impacting 70% of the Internet', 28 minutes before the planned release; the thread still says 'Apply the Oct 22 security release'. | stated | Wiz on X |\n| 2026-10-21 13:34:13 UTC | GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) and, twelve seconds later, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) are published by bukka. | stated | PHP PHP |\n| 2026-10-21 13:35:38 UTC | Signed tags php-8.5.12, php-8.4.27, php-8.3.36 and php-8.2.35 are created. | stated | php-src |\n| 2026-10-21 13:48:34 UTC | The CVE record for CVE-2026-109618 is published; CVE-2026-109619 follows at 13:54:43Z. | stated | CVE record CVE record |\n| 2026-10-21 14:00 UTC | The planned release time. php.net's advisory 'Critical remote code execution vulnerabilities, update now' and the four release posts go up. | stated | php.net oss-security Daubois |\n| 2026-10-21 14:04 UTC | OpenAI posts: models 'helped researchers ... discover critical security flaws in PHP ... used to run an estimated 70% of websites'. An X Community Note later disputes OpenAI's role. | stated | OpenAI on X |\n| 2026-10-21 14:06:22 UTC | The fix commit enters the public php-src branches (commit timestamp); merged into 8.3 at 14:12, 8.4 at 14:27 and 8.5 at 14:30 UTC. | stated | php/php-src, read from a clone |\n| 2026-10-21 14:06:46 UTC | GitHub release php-8.5.12 is published by adoy. | stated | php-src |\n| 2026-10-21 14:17:09 UTC | NVD publishes both CVEs with the CNA's CVSS v4.0 9.2 and no NIST score. | stated | NVD NVD |\n| 2026-10-21 14:41:54 UTC | Jakub Zelenka announces CVE-2026-109618 on oss-security; CVE-2026-109619 at 14:44:06Z. | stated | oss-security oss-security |\n\n## The response, 20 to 22 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-20 | Swiss BACS posts a warning (home-page teaser dated 20 October; the page itself now says 21 October). | inferred | Swiss BACS BACS |\n| 2026-10-21 | CISA alert 'Critical Vulnerabilities in PHP Require Immediate Patching': take systems offline if you cannot update. NSA press release 'PHP2Shell'. UK NCSC alert. CCCS AL26-026. CERT-FR ALE-014. ACN AL07/261021. Cloudflare, Wiz, Calif, the PHP Foundation and Daubois publish their accounts.Date only; none of these pages carries a time. | stated | CISA NSA NCSC UK CCCS CERT-FR ACN / CSIRT Italia Cloudflare Wiz Calif PHP Foundation Daubois |\n| 2026-10-21 | The Dutch NCSC takes its own website offline as a precaution; DigiD, MijnOverheid and Overheid.nl follow. Weird Gloop turns off its wiki web servers for 13 hours. Amazon, Imperva, Fastly, Akamai and Huntress publish. | stated | Rijksoverheid / NCSC-NL Weird Gloop Amazon Imperva Threat Research Fastly Akamai Security Research Huntress |\n| 2026-10-21 03:02 UTC | Cloudflare's WAF protections go live for all customers, about nine hours ahead of disclosure. | stated | Cloudflare |\n| 2026-10-21 09:45 UTC | Finland's Valtori begins restricting public traffic to government web services (12:45 local).Converted from Finnish time. | inferred | Helsinki Times Yle |\n| 2026-10-21 13:45:58 UTC | NSA Cybersecurity posts on X: 'Effective Immediately ... be prepared for an update addressing two critical vulnerabilities ... take the system offline'.Time decoded from the post's ID; the page shows 13:45. | stated | NSA Cyber on X |\n| 2026-10-21 14:04:39 UTC | CISA releases KEV catalog version 2026.10.21; neither PHP CVE is in it. | stated | CISA |\n| 2026-10-21 14:34 UTC | CISA's ADP assessment on both CVE records: exploitation none, automatable no, technical impact total. | stated | CVE record CVE record |\n| 2026-10-21 15:20 UTC | CERT-EU Security Advisory 2026-018 (stated 15:20:18, timezone not given). | inferred | CERT-EU |\n| 2026-10-21 15:25 UTC | NCSC-NL's php2shell README last significant change (17:25 CEST). CERT.LV publishes: Latvia restricts access to several state digital resources from abroad (18:25 EEST).Both converted to UTC by this site. | stated | NCSC-NL CERT.LV |\n| 2026-10-21 20:00 UTC | CERT.LV update: the unified state website platform is patched; lsm.lv and 112.lv restored; about 6,000 potentially affected resources in Latvia; automated attempts seen, none successful. | stated | CERT.LV |\n| 2026-10-21 20:15 UTC | NCSC New Zealand: 'aware of reports of active exploitation' (09:15 NZDT 22 October; updated 21:20Z).Converted from NZDT. | stated | NCSC New Zealand |\n| 2026-10-22 00:43:58 UTC | NSA Cybersecurity posts 'UPDATE: Specific mitigation guidance ... is now available', linking the press release. | stated | NSA Cyber on X NSA |\n| 2026-10-22 05:20 UTC | JVN publishes its note (14:20 JST); JPCERT/CC alert JPCERT-AT-2026-0033 is dated 22 October. | stated | JPCERT/CC JPCERT/CC |\n\n## Aftermath, 21 to 22 October\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-21 15:24:37 UTC | Aaron Rainbolt relays to oss-security a Fediverse report that the 8.5.12 fix may be incomplete; a Debian maintainer adds that the poster called it a different bug. | stated | oss-security |\n| 2026-10-21 17:29 UTC | Per a Matrix channel, Canonical asked PHP about the Fediverse report and was told it is 'unrelated and not a real issue'.Second-hand. | stated | oss-security |\n| 2026-10-21 20:30 UTC | Huntress: no exploitation observed on partner systems (16:30 ET).Converted from Eastern time. | stated | Huntress |\n| 2026-10-22 | The Hacker News publishes Amazon's account of the 17 October honeypot attempt and VulnCheck's count of 2,608,039 hosts. | stated | THN |\n| 2026-10-22 | The Register carries Dan Lorenc's reply to the PHP Foundation; Fortinet publishes FortiWeb signatures; The Record carries the Foundation's account of the 2024 signs. | stated | The Register Fortinet Community The Record |\n| 2026-10-22 01:25 UTC | Matthew Prince posts Cloudflare's attempt counts: thousands before, millions after. | stated | Matthew Prince, Cloudflare CEO on… |\n| 2026-10-22 06:16:24 UTC | BBC News opens its live page: 'Global scramble to fix critical cyber-security flaws as many websites taken offline'. | stated | BBC News |\n| 2026-10-22 06:45:47 UTC | Greenbone on oss-security: the backports imply versions down to 7.4 are affected, whatever the subject line says. | stated | oss-security |\n| 2026-10-22 06:55:50 UTC | The BBC reports the NSA's X post. | stated | BBC News |\n| 2026-10-22 07:00 UTC | Ryan Austin on BBC Radio 4: no evidence of exploitation yet.08:00 BST post. | stated | BBC News |\n| 2026-10-22 07:30:02 UTC | The UK NCSC page is modified (HTTP last-modified). | stated | NCSC UK |\n| 2026-10-22 08:40:58 UTC | NCSC-NL merges pull request 10; the inventory has 674 entries at commit cca173c64ec5. | stated | NCSC-NL NCSC-NL |\n\n## This site\n\n| When | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-22 08:03 UTC | The evidence vault behind this site is opened; the first capture of the BBC live page is at 08:04:53Z. | stated | BBC News |\n\nThe sequence as a graph of who said what first is on Who found it; the leak alone is on How disclosure broke."
    }
   ]
  },
  "page-discovery": {
   "title": "Who found it",
   "kind": "page",
   "path": "discovery/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "f52c8ca4652b",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Who found php2shell, and what the AI did\n\nCalif, 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.\n\n# Who found it, and how\n\nThree research parties say they found php2shell, and all three say AI helped. Their own timelines, placed side by side, do not conflict on dates: Calif first (1 to 11 August), OpenAI the same day as Calif's report, Wiz independently eight days later. They conflict on framing: Wiz's *Wiz Research uncovers*, OpenAI's *frontier AI was able to find this vulnerability ahead of attackers*, and a Community Note on OpenAI's post pointing at Calif's August hash.\n\n### Calif\n- 2026-07-30 audit begins under Patch the Planet\n- 2026-08-01 multiple paths to RCE found\n- 2026-08-05 hash commitment posted on X\n- 2026-08-11 first bug reported to PHP\n- 2026-08-14 RCE PoC shared; confirmed 08-15\n- 2026-08-21 second bug reported\n\nCalif Ryan Austin , Calif on X\n\n### OpenAI\n- 2026-08-11 same root cause reported, same day as Calif (per the Foundation)\n- 2026-09-18 further attack vectors\n- coalition of maintainers, researchers and providers over two months\n- credit: amyb-oai on both advisories\n\nPHP Foundation OpenAI on X PHP\n\n### Wiz\n- 2026-08-19 first vulnerability found (Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol)\n- 2026-08-20 RCE confirmed on Drupal\n- 2026-08-21 RCE confirmed on WordPress\n- 2026-08-24 reported to PHP\n- 2026-09-21 PHP acknowledges\n- credit: sagitzadik-wiz\n\nWiz\n\n### Before them\n- 2024 Quarkslab audit (OSTIF, Sovereign Tech Agency) surfaces the OOM issue\n- 2024 a Foundation-contracted developer finds first signs; exploit theorised, no vector\n- credit: tomash-areion on both advisories, named nowhere else\n\nPHP Foundation Calif PHP\n\n## What the AI did\n\nThe honest answer from the captured sources is: not enough is said. Calif says *No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery* and that the researcher *asked my LLM companion for help*; it names no model. Wiz names three tools and quotes Google DeepMind's head of Gemini security: *a single researcher completed in a week what previously would have taken a world-class team months of work.* OpenAI's blog, which reportedly names GPT-5.6 Sol, is behind a bot challenge from this capture environment. The PHP Foundation adds that the project was separately scanned with Anthropic's Claude Mythos through Alpha-Omega and that OpenAI's Daybreak Red validated reports and exploits.\n\nWhat is established is the shape: a bug class seen in 2024 and left because nobody could prove exploitation, then three groups with model assistance finding working exploits within three weeks of each other in August 2026. The BBC's quote, *a complex chain of steps, at the edge of what human researchers could practically achieve*, is not on any captured researcher page.\n\nCalif Wiz OpenAI PHP Foundation BBC News\n\n## The claims on discovery\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | BBC News OpenAI on X Calif Wiz |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | Calif Ryan Austin , Calif on X PHP Foundation |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | Wiz PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | PHP Foundation Calif |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | OpenAI on X THN |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | BBC News Wiz |"
    },
    {
     "v": 2,
     "hash": "96f1f2e2cd83",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Who found php2shell, and what the AI did\n\nCalif, 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.\n\n# Who found it, and how\n\nThree research parties say they found php2shell, and all three say AI helped. Their own timelines, placed side by side, do not conflict on dates: Calif first (1 to 11 August), OpenAI the same day as Calif's report, Wiz independently eight days later. They conflict on framing: Wiz's *Wiz Research uncovers*, OpenAI's *frontier AI was able to find this vulnerability ahead of attackers*, and a Community Note on OpenAI's post pointing at Calif's August hash.\n\n### Calif\n- 2026-07-30 audit begins under Patch the Planet\n- 2026-08-01 multiple paths to RCE found\n- 2026-08-05 hash commitment posted on X\n- 2026-08-11 first bug reported to PHP\n- 2026-08-14 RCE PoC shared; confirmed 08-15\n- 2026-08-21 second bug reported\n\nCalif Ryan Austin , Calif on X\n\n### OpenAI\n- 2026-08-11 same root cause reported, same day as Calif (per the Foundation)\n- 2026-09-18 further attack vectors\n- coalition of maintainers, researchers and providers over two months\n- credit: amyb-oai on both advisories\n\nPHP Foundation OpenAI on X PHP\n\n### Wiz\n- 2026-08-19 first vulnerability found (Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol)\n- 2026-08-20 RCE confirmed on Drupal\n- 2026-08-21 RCE confirmed on WordPress\n- 2026-08-24 reported to PHP\n- 2026-09-21 PHP acknowledges\n- credit: sagitzadik-wiz\n\nWiz\n\n### Before them\n- 2024 Quarkslab audit (OSTIF, Sovereign Tech Agency) surfaces the OOM issue\n- 2024 a Foundation-contracted developer finds first signs; exploit theorised, no vector\n- credit: tomash-areion on both advisories, named nowhere else\n\nPHP Foundation Calif PHP\n\n## What the AI did\n\nThe honest answer from the captured sources is: not enough is said. Calif says *No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery* and that the researcher *asked my LLM companion for help*; it names no model. Wiz names three tools and quotes Google DeepMind's head of Gemini security: *a single researcher completed in a week what previously would have taken a world-class team months of work.* OpenAI's blog, which reportedly names GPT-5.6 Sol, is behind a bot challenge from this capture environment. The PHP Foundation adds that the project was separately scanned with Anthropic's Claude Mythos through Alpha-Omega and that OpenAI's Daybreak Red validated reports and exploits.\n\nWhat is established is the shape: a bug class seen in 2024 and left because nobody could prove exploitation, then three groups with model assistance finding working exploits within three weeks of each other in August 2026. The BBC's quote, *a complex chain of steps, at the edge of what human researchers could practically achieve*, is not on any captured researcher page.\n\nCalif Wiz OpenAI PHP Foundation BBC News\n\n## The claims on discovery\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin , Calif on X PHP Foundation |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |"
    },
    {
     "v": 3,
     "hash": "d31c05592578",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Who found php2shell, and what the AI did\n\nCalif, 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.\n\n# Who found it, and how\n\nIn plain English Who found the flaws (three research teams, all using AI help) and what the AI actually did, as far as anyone has said.\n\nThree research parties say they found php2shell, and all three say AI helped. Their own timelines, placed side by side, do not conflict on dates: Calif first (1 to 11 August), OpenAI the same day as Calif's report, Wiz independently eight days later. They conflict on framing: Wiz's *Wiz Research uncovers*, OpenAI's *frontier AI was able to find this vulnerability ahead of attackers*, and a Community Note on OpenAI's post pointing at Calif's August hash.\n\n### Calif\n- 2026-07-30 audit begins under Patch the Planet\n- 2026-08-01 multiple paths to RCE found\n- 2026-08-05 hash commitment posted on X\n- 2026-08-11 first bug reported to PHP\n- 2026-08-14 RCE PoC shared; confirmed 08-15\n- 2026-08-21 second bug reported\n\nCalif Ryan Austin , Calif on X\n\n### OpenAI\n- 2026-08-11 same root cause reported, same day as Calif (per the Foundation)\n- 2026-09-18 further attack vectors\n- coalition of maintainers, researchers and providers over two months\n- credit: amyb-oai on both advisories\n\nPHP Foundation OpenAI on X PHP\n\n### Wiz\n- 2026-08-19 first vulnerability found (Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol)\n- 2026-08-20 RCE confirmed on Drupal\n- 2026-08-21 RCE confirmed on WordPress\n- 2026-08-24 reported to PHP\n- 2026-09-21 PHP acknowledges\n- credit: sagitzadik-wiz\n\nWiz\n\n### Before them\n- 2024 Quarkslab audit (OSTIF, Sovereign Tech Agency) surfaces the OOM issue\n- 2024 a Foundation-contracted developer finds first signs; exploit theorised, no vector\n- credit: tomash-areion on both advisories, named nowhere else\n\nPHP Foundation Calif PHP\n\n## What the AI did\n\nThe honest answer from the captured sources is: not enough is said. Calif says *No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery* and that the researcher *asked my LLM companion for help*; it names no model. Wiz names three tools and quotes Google DeepMind's head of Gemini security: *a single researcher completed in a week what previously would have taken a world-class team months of work.* OpenAI's blog, which reportedly names GPT-5.6 Sol, is behind a bot challenge from this capture environment. The PHP Foundation adds that the project was separately scanned with Anthropic's Claude Mythos through Alpha-Omega and that OpenAI's Daybreak Red validated reports and exploits.\n\nWhat is established is the shape: a bug class seen in 2024 and left because nobody could prove exploitation, then three groups with model assistance finding working exploits within three weeks of each other in August 2026. The BBC's quote, *a complex chain of steps, at the edge of what human researchers could practically achieve*, is not on any captured researcher page.\n\nCalif Wiz OpenAI PHP Foundation BBC News\n\n## The claims on discovery\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin , Calif on X PHP Foundation |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |"
    },
    {
     "v": 4,
     "hash": "91636a915060",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Who found php2shell, and what the AI did\n\nCalif, 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.\n\n# Who found it, and how\n\nIn plain English Who found the flaws (three research teams, all using AI help) and what the AI actually did, as far as anyone has said.\n\nThree research parties say they found php2shell, and all three say AI helped. Their own timelines, placed side by side, do not conflict on dates: Calif first (1 to 11 August), OpenAI the same day as Calif's report, Wiz independently eight days later. They conflict on framing: Wiz's *Wiz Research uncovers*, OpenAI's *frontier AI was able to find this vulnerability ahead of attackers*, and a Community Note on OpenAI's post pointing at Calif's August hash.\n\n### Calif\n- 2026-07-30 audit begins under Patch the Planet\n- 2026-08-01 multiple paths to RCE found\n- 2026-08-05 hash commitment posted on X\n- 2026-08-11 first bug reported to PHP\n- 2026-08-14 RCE PoC shared; confirmed 08-15\n- 2026-08-21 second bug reported\n\nCalif Ryan Austin, Calif on X\n\n### OpenAI\n- 2026-08-11 same root cause reported, same day as Calif (per the Foundation)\n- 2026-09-18 further attack vectors\n- coalition of maintainers, researchers and providers over two months\n- credit: amyb-oai on both advisories\n\nPHP Foundation OpenAI on X PHP\n\n### Wiz\n- 2026-08-19 first vulnerability found (Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol)\n- 2026-08-20 RCE confirmed on Drupal\n- 2026-08-21 RCE confirmed on WordPress\n- 2026-08-24 reported to PHP\n- 2026-09-21 PHP acknowledges\n- credit: sagitzadik-wiz\n\nWiz\n\n### Before them\n- 2024 Quarkslab audit (OSTIF, Sovereign Tech Agency) surfaces the OOM issue\n- 2024 a Foundation-contracted developer finds first signs; exploit theorised, no vector\n- credit: tomash-areion on both advisories, named nowhere else\n\nPHP Foundation Calif PHP\n\n## What the AI did\n\nThe honest answer from the captured sources is: not enough is said. Calif says *No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery* and that the researcher *asked my LLM companion for help*; it names no model. Wiz names three tools and quotes Google DeepMind's head of Gemini security: *a single researcher completed in a week what previously would have taken a world-class team months of work.* OpenAI's blog, which reportedly names GPT-5.6 Sol, is behind a bot challenge from this capture environment. The PHP Foundation adds that the project was separately scanned with Anthropic's Claude Mythos through Alpha-Omega and that OpenAI's Daybreak Red validated reports and exploits.\n\nWhat is established is the shape: a bug class seen in 2024 and left because nobody could prove exploitation, then three groups with model assistance finding working exploits within three weeks of each other in August 2026. The BBC's quote, *a complex chain of steps, at the edge of what human researchers could practically achieve*, is not on any captured researcher page.\n\nCalif Wiz OpenAI PHP Foundation BBC News\n\n## The claims on discovery\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |"
    },
    {
     "v": 5,
     "hash": "0f3b5c295058",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Who found php2shell, and what the AI did\n\nCalif, 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.\n\n# Who found it, and how\n\nIn plain English Who found the flaws (three research teams, all using AI help) and what the AI actually did, as far as anyone has said.\n\nThree research parties say they found php2shell, and all three say AI helped. Their own timelines, placed side by side, do not conflict on dates: Calif first (1 to 11 August), OpenAI the same day as Calif's report, Wiz independently eight days later. They conflict on framing: Wiz's *Wiz Research uncovers*, OpenAI's *frontier AI was able to find this vulnerability ahead of attackers*, and a Community Note on OpenAI's post pointing at Calif's August hash.\n\n### Calif\n- 2026-07-30 audit begins under Patch the Planet\n- 2026-08-01 multiple paths to RCE found\n- 2026-08-05 hash commitment posted on X\n- 2026-08-11 first bug reported to PHP\n- 2026-08-14 RCE PoC shared; confirmed 08-15\n- 2026-08-21 second bug reported\n\nCalif Ryan Austin, Calif on X\n\n### OpenAI\n- 2026-08-11 same root cause reported, same day as Calif (per the Foundation)\n- 2026-09-18 further attack vectors\n- coalition of maintainers, researchers and providers over two months\n- credit: amyb-oai on both advisories\n\nPHP Foundation OpenAI on X PHP\n\n### Wiz\n- 2026-08-19 first vulnerability found (Wiz Atlas, Gemini 4 Argon, GPT-5.6 Sol)\n- 2026-08-20 RCE confirmed on Drupal\n- 2026-08-21 RCE confirmed on WordPress\n- 2026-08-24 reported to PHP\n- 2026-09-21 PHP acknowledges\n- credit: sagitzadik-wiz\n\nWiz\n\n### Before them\n- 2024 Quarkslab audit (OSTIF, Sovereign Tech Agency) surfaces the OOM issue\n- 2024 a Foundation-contracted developer finds first signs; exploit theorised, no vector\n- credit: tomash-areion on both advisories, named nowhere else\n\nPHP Foundation Calif PHP\n\n## What the AI did\n\nThe honest answer from the captured sources is: not enough is said. Calif says *No special harness, or access to models that weren't generally available to everyone were used in the initial bug discovery* and that the researcher *asked my LLM companion for help*; it names no model. Wiz names three tools and quotes Google DeepMind's head of Gemini security: *a single researcher completed in a week what previously would have taken a world-class team months of work.* OpenAI's blog, which reportedly names GPT-5.6 Sol, is behind a bot challenge from this capture environment. The PHP Foundation adds that the project was separately scanned with Anthropic's Claude Mythos through Alpha-Omega and that OpenAI's Daybreak Red validated reports and exploits.\n\nWhat is established is the shape: a bug class seen in 2024 and left because nobody could prove exploitation, then three groups with model assistance finding working exploits within three weeks of each other in August 2026. The BBC's quote, *a complex chain of steps, at the edge of what human researchers could practically achieve*, is not on any captured researcher page.\n\nCalif Wiz OpenAI PHP Foundation BBC News\n\n## The claims on discovery\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | **A3** Echoed●●●○○○ opinion measures differently | 3/4 | BBC News OpenAI on X Calif Wiz |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | **A3** Echoed●●●○○○ opinion measures differently status overstated | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | **A2** Reported●●○○○○ | 2/2 | Wiz PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | **A6** Established●●●●●● | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | **A2** Reported●●○○○○ disputed status overstated | 2/2 | PHP Foundation Calif |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | **A2** Reported●●○○○○ opinion disputed | 1/2 | OpenAI on X THN |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | **A2** Reported●●○○○○ opinion measures differently | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | **A6** Established●●●●●● | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | **A2** Reported●●○○○○ | 0/1 | The Register |"
    }
   ]
  },
  "page-leak": {
   "title": "How disclosure broke",
   "kind": "page",
   "path": "leak/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "935c669b04ff",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# How the coordinated disclosure broke\n\nHour 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.\n\n# How the disclosure broke\n\nThe plan was 22 October at 14:00 UTC. From about 15:00 UTC on 20 October the CVE IDs were loose with a wrong score; by 19:30 the project had pre-announced a release a day early; by 20:00 one of the reporters had published a demonstration video; by 23:00 mitigation advice was going to critical-infrastructure providers; by 02:00 on the 21st Amazon was seeing proof-of-concept attempts; by 03:02 Cloudflare's rules were live; by 07:41 Chainguard had shipped patched images; by 08:36 a sensor network had its first hit. The release went out at 13:34 UTC. Every one of those times is from a party's own account, and the parties disagree on what was leaked and by whom.\n\n| When (UTC) | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-17 | An exploit attempt from an anonymisation-network IP hits an Amazon MadPot honeypot.As Amazon's CISO told The Hacker News; no primary Amazon post found. | stated | THN |\n| 2026-10-20 | Swiss BACS posts a warning (home-page teaser dated 20 October; the page itself now says 21 October). | inferred | Swiss BACS BACS |\n| 2026-10-20 15:00 UTC | The two CVE IDs begin circulating on forums and social media with a wrong release time and a wrong CVSS of 10.0. Per Daubois: an anonymous Hacker News post, then screenshots, a 'PHP2Shell tool' screenshot credited to Calif.io, a short exploitation video, and watchTowr posting both CVE numbers.'around 15:00 UTC' per the Foundation. | stated | PHP Foundation Daubois |\n| 2026-10-20 19:30 UTC | php.net publishes the pre-announcement: release moved to 21 October 14:00 UTC, two critical vulnerabilities, CVSS v4.0 9.2, 'we reserve the right to release earlier'.19:30 UTC per the Foundation; the php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC. | disputed | PHP Foundation oss-security php.net |\n| 2026-10-20 20:00 UTC | Calif 'mistakenly published a video' showing its proof of concept against several targets; copies circulate after it is deleted.'around 20:00 UTC'. Calif's page does not mention it. | stated | PHP Foundation PHP Foundation |\n| 2026-10-20 20:22:51 UTC | Alan Coopersmith relays the php.net pre-announcement to oss-security. | stated | oss-security |\n| 2026-10-20 23:00 UTC | The PHP project starts giving mitigation advice to a few critical-infrastructure providers; it 'may have leaked as well'. | stated | PHP Foundation |\n| 2026-10-21 02:00 UTC | Amazon sees proof-of-concept attempts, then six hours of attempts from anonymised infrastructure. | stated | THN |\n| 2026-10-21 07:41 UTC | Chainguard publishes built images containing the fix, 'more than six hours before the coordinated release'.Chainguard reportedly denies leaking; that article is blocked. | stated | PHP Foundation Techzine |\n| 2026-10-21 08:36 UTC | ELLIO records its first sensor hit. | stated | THN PHP Foundation |\n| 2026-10-21 13:30 UTC | CERT-EU's stated release time for the PHP fixes.Differs from the planned 14:00 UTC and from the 13:35 UTC tags. | stated | CERT-EU |\n| 2026-10-21 13:32 UTC | Wiz posts 'BREAKING ... #PHP2SHELL ... impacting 70% of the Internet', 28 minutes before the planned release; the thread still says 'Apply the Oct 22 security release'. | stated | Wiz on X |\n| 2026-10-21 13:34:13 UTC | GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) and, twelve seconds later, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) are published by bukka. | stated | PHP PHP |\n| 2026-10-21 13:35:38 UTC | Signed tags php-8.5.12, php-8.4.27, php-8.3.36 and php-8.2.35 are created. | stated | php-src |\n| 2026-10-21 13:48:34 UTC | The CVE record for CVE-2026-109618 is published; CVE-2026-109619 follows at 13:54:43Z. | stated | CVE record CVE record |\n| 2026-10-21 14:00 UTC | The planned release time. php.net's advisory 'Critical remote code execution vulnerabilities, update now' and the four release posts go up. | stated | php.net oss-security Daubois |\n| 2026-10-21 14:04 UTC | OpenAI posts: models 'helped researchers ... discover critical security flaws in PHP ... used to run an estimated 70% of websites'. An X Community Note later disputes OpenAI's role. | stated | OpenAI on X |\n| 2026-10-21 14:06:46 UTC | GitHub release php-8.5.12 is published by adoy. | stated | php-src |\n| 2026-10-21 14:17:09 UTC | NVD publishes both CVEs with the CNA's CVSS v4.0 9.2 and no NIST score. | stated | NVD NVD |\n| 2026-10-21 14:41:54 UTC | Jakub Zelenka announces CVE-2026-109618 on oss-security; CVE-2026-109619 at 14:44:06Z. | stated | oss-security oss-security |\n\n## Three accounts of what leaked\n\n- **The PHP Foundation:** the CVE IDs, a wrong release time and a wrong CVSS; *No technical details leaked.* Then Calif's video, then possibly the mitigation advice, then Chainguard's images.\n\n- **Alexandre Daubois (PHP security team, writing personally):** an anonymous Hacker News post citing a reliable source, screenshots of it, a screenshot of the *PHP2Shell tool* credited to Calif.io *alongside the advisory*, a short exploitation video, and watchTowr confirming both CVE numbers in public.\n\n- **The Hacker News:** *details about the CVE identifiers and a proof-of-concept (PoC) exploit leaked ahead of time*, and Amazon's evidence that somebody was trying an exploit four days before any of this.\n\nCalif's own write-up has a timeline that ends *October 21 Patched versions released* and does not mention a leak, a deleted video, or the Foundation's account. Chainguard's reply is behind a bot challenge; the search snippet says it does not dispute the time and denies leaking. The vault records both blocks.\n\nPHP Foundation Daubois THN Calif Techzine\n\n## The claims on the leak and on timing\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixChainguard reportedly does not dispute the time but denies leaking (Techzine, blocked by a bot challenge; snippet only). | PHP Foundation | disputed | PHP Foundation Techzine |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | PHP Foundation oss-security Wiz on X php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | BBC News php.net php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | PHP Foundation oss-security php.net |"
    },
    {
     "v": 2,
     "hash": "6cf590b9a20a",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# How the coordinated disclosure broke\n\nHour 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.\n\n# How the disclosure broke\n\nThe plan was 22 October at 14:00 UTC. From about 15:00 UTC on 20 October the CVE IDs were loose with a wrong score; by 19:30 the project had pre-announced a release a day early; by 20:00 one of the reporters had published a demonstration video; by 23:00 mitigation advice was going to critical-infrastructure providers; by 02:00 on the 21st Amazon was seeing proof-of-concept attempts; by 03:02 Cloudflare's rules were live; by 07:41 Chainguard had shipped patched images; by 08:36 a sensor network had its first hit. The release went out at 13:34 UTC. Every one of those times is from a party's own account, and the parties disagree on what was leaked and by whom.\n\n| When (UTC) | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-17 | An exploit attempt from an anonymisation-network IP hits an Amazon MadPot honeypot.As Amazon's CISO told The Hacker News; no primary Amazon post found. | stated | THN |\n| 2026-10-20 | Swiss BACS posts a warning (home-page teaser dated 20 October; the page itself now says 21 October). | inferred | Swiss BACS BACS |\n| 2026-10-20 | Qualys publishes on the pre-announcement. | stated | Qualys |\n| 2026-10-20 15:00 UTC | The two CVE IDs begin circulating on forums and social media with a wrong release time and a wrong CVSS of 10.0. Per Daubois: an anonymous Hacker News post, then screenshots, a 'PHP2Shell tool' screenshot credited to Calif.io, a short exploitation video, and watchTowr posting both CVE numbers.'around 15:00 UTC' per the Foundation. | stated | PHP Foundation Daubois |\n| 2026-10-20 19:30 UTC | php.net publishes the pre-announcement: release moved to 21 October 14:00 UTC, two critical vulnerabilities, CVSS v4.0 9.2, 'we reserve the right to release earlier'.19:30 UTC per the Foundation; the php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC. | disputed | PHP Foundation oss-security php.net |\n| 2026-10-20 20:00 UTC | Calif 'mistakenly published a video' showing its proof of concept against several targets; copies circulate after it is deleted.'around 20:00 UTC'. Calif's page does not mention it. | stated | PHP Foundation PHP Foundation |\n| 2026-10-20 20:22:51 UTC | Alan Coopersmith relays the php.net pre-announcement to oss-security. | stated | oss-security |\n| 2026-10-20 23:00 UTC | The PHP project starts giving mitigation advice to a few critical-infrastructure providers; it 'may have leaked as well'. | stated | PHP Foundation |\n| 2026-10-21 02:00 UTC | Amazon sees proof-of-concept attempts, then six hours of attempts from anonymised infrastructure. | stated | THN |\n| 2026-10-21 07:41 UTC | Chainguard publishes built images containing the fix, 'more than six hours before the coordinated release'.Chainguard reportedly denies leaking; that article is blocked. | stated | PHP Foundation Techzine |\n| 2026-10-21 07:43 UTC | Cloudflare's CTO reports early attacks emerging, before the release.Second-hand; the post itself is not captured. | stated | Insurance Business SecurityWeek |\n| 2026-10-21 08:36 UTC | ELLIO records its first sensor hit. | stated | THN PHP Foundation |\n| 2026-10-21 13:30 UTC | CERT-EU's stated release time for the PHP fixes.Differs from the planned 14:00 UTC and from the 13:35 UTC tags. | stated | CERT-EU |\n| 2026-10-21 13:32 UTC | Wiz posts 'BREAKING ... #PHP2SHELL ... impacting 70% of the Internet', 28 minutes before the planned release; the thread still says 'Apply the Oct 22 security release'. | stated | Wiz on X |\n| 2026-10-21 13:34:13 UTC | GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) and, twelve seconds later, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) are published by bukka. | stated | PHP PHP |\n| 2026-10-21 13:35:38 UTC | Signed tags php-8.5.12, php-8.4.27, php-8.3.36 and php-8.2.35 are created. | stated | php-src |\n| 2026-10-21 13:48:34 UTC | The CVE record for CVE-2026-109618 is published; CVE-2026-109619 follows at 13:54:43Z. | stated | CVE record CVE record |\n| 2026-10-21 14:00 UTC | The planned release time. php.net's advisory 'Critical remote code execution vulnerabilities, update now' and the four release posts go up. | stated | php.net oss-security Daubois |\n| 2026-10-21 14:04 UTC | OpenAI posts: models 'helped researchers ... discover critical security flaws in PHP ... used to run an estimated 70% of websites'. An X Community Note later disputes OpenAI's role. | stated | OpenAI on X |\n| 2026-10-21 14:06:22 UTC | The fix commit enters the public php-src branches (commit timestamp); merged into 8.3 at 14:12, 8.4 at 14:27 and 8.5 at 14:30 UTC. | stated | php/php-src , read from a clone |\n| 2026-10-21 14:06:46 UTC | GitHub release php-8.5.12 is published by adoy. | stated | php-src |\n| 2026-10-21 14:17:09 UTC | NVD publishes both CVEs with the CNA's CVSS v4.0 9.2 and no NIST score. | stated | NVD NVD |\n| 2026-10-21 14:41:54 UTC | Jakub Zelenka announces CVE-2026-109618 on oss-security; CVE-2026-109619 at 14:44:06Z. | stated | oss-security oss-security |\n\n## Three accounts of what leaked\n\n- **The PHP Foundation:** the CVE IDs, a wrong release time and a wrong CVSS; *No technical details leaked.* Then Calif's video, then possibly the mitigation advice, then Chainguard's images.\n\n- **Alexandre Daubois (PHP security team, writing personally):** an anonymous Hacker News post citing a reliable source, screenshots of it, a screenshot of the *PHP2Shell tool* credited to Calif.io *alongside the advisory*, a short exploitation video, and watchTowr confirming both CVE numbers in public.\n\n- **The Hacker News:** *details about the CVE identifiers and a proof-of-concept (PoC) exploit leaked ahead of time*, and Amazon's evidence that somebody was trying an exploit four days before any of this.\n\nCalif's own write-up has a timeline that ends *October 21 Patched versions released* and does not mention a leak, a deleted video, or the Foundation's account. Chainguard's reply is behind a bot challenge; the search snippet says it does not dispute the time and denies leaking. The vault records both blocks.\n\nPHP Foundation Daubois THN Calif Techzine\n\n## The claims on the leak and on timing\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src , read from a clone php-src |"
    },
    {
     "v": 3,
     "hash": "26fe8974f085",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# How the coordinated disclosure broke\n\nHour 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.\n\n# How the disclosure broke\n\nIn plain English The plan was to publish the fix and the details together on 22 October. The secret leaked on the 20th; this page is the hour-by-hour account.\n\nThe plan was 22 October at 14:00 UTC. From about 15:00 UTC on 20 October the CVE IDs were loose with a wrong score; by 19:30 the project had pre-announced a release a day early; by 20:00 one of the reporters had published a demonstration video; by 23:00 mitigation advice was going to critical-infrastructure providers; by 02:00 on the 21st Amazon was seeing proof-of-concept attempts; by 03:02 Cloudflare's rules were live; by 07:41 Chainguard had shipped patched images; by 08:36 a sensor network had its first hit. The release went out at 13:34 UTC. Every one of those times is from a party's own account, and the parties disagree on what was leaked and by whom.\n\n| When (UTC) | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-17 | An exploit attempt from an anonymisation-network IP hits an Amazon MadPot honeypot.As Amazon's CISO told The Hacker News; no primary Amazon post found. | stated | THN |\n| 2026-10-20 | Swiss BACS posts a warning (home-page teaser dated 20 October; the page itself now says 21 October). | inferred | Swiss BACS BACS |\n| 2026-10-20 | Qualys publishes on the pre-announcement. | stated | Qualys |\n| 2026-10-20 15:00 UTC | The two CVE IDs begin circulating on forums and social media with a wrong release time and a wrong CVSS of 10.0. Per Daubois: an anonymous Hacker News post, then screenshots, a 'PHP2Shell tool' screenshot credited to Calif.io, a short exploitation video, and watchTowr posting both CVE numbers.'around 15:00 UTC' per the Foundation. | stated | PHP Foundation Daubois |\n| 2026-10-20 19:30 UTC | php.net publishes the pre-announcement: release moved to 21 October 14:00 UTC, two critical vulnerabilities, CVSS v4.0 9.2, 'we reserve the right to release earlier'.19:30 UTC per the Foundation; the php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC. | disputed | PHP Foundation oss-security php.net |\n| 2026-10-20 20:00 UTC | Calif 'mistakenly published a video' showing its proof of concept against several targets; copies circulate after it is deleted.'around 20:00 UTC'. Calif's page does not mention it. | stated | PHP Foundation PHP Foundation |\n| 2026-10-20 20:22:51 UTC | Alan Coopersmith relays the php.net pre-announcement to oss-security. | stated | oss-security |\n| 2026-10-20 23:00 UTC | The PHP project starts giving mitigation advice to a few critical-infrastructure providers; it 'may have leaked as well'. | stated | PHP Foundation |\n| 2026-10-21 02:00 UTC | Amazon sees proof-of-concept attempts, then six hours of attempts from anonymised infrastructure. | stated | THN |\n| 2026-10-21 07:41 UTC | Chainguard publishes built images containing the fix, 'more than six hours before the coordinated release'.Chainguard reportedly denies leaking; that article is blocked. | stated | PHP Foundation Techzine |\n| 2026-10-21 07:43 UTC | Cloudflare's CTO reports early attacks emerging, before the release.Second-hand; the post itself is not captured. | stated | Insurance Business SecurityWeek |\n| 2026-10-21 08:36 UTC | ELLIO records its first sensor hit. | stated | THN PHP Foundation |\n| 2026-10-21 13:30 UTC | CERT-EU's stated release time for the PHP fixes.Differs from the planned 14:00 UTC and from the 13:35 UTC tags. | stated | CERT-EU |\n| 2026-10-21 13:32 UTC | Wiz posts 'BREAKING ... #PHP2SHELL ... impacting 70% of the Internet', 28 minutes before the planned release; the thread still says 'Apply the Oct 22 security release'. | stated | Wiz on X |\n| 2026-10-21 13:34:13 UTC | GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) and, twelve seconds later, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) are published by bukka. | stated | PHP PHP |\n| 2026-10-21 13:35:38 UTC | Signed tags php-8.5.12, php-8.4.27, php-8.3.36 and php-8.2.35 are created. | stated | php-src |\n| 2026-10-21 13:48:34 UTC | The CVE record for CVE-2026-109618 is published; CVE-2026-109619 follows at 13:54:43Z. | stated | CVE record CVE record |\n| 2026-10-21 14:00 UTC | The planned release time. php.net's advisory 'Critical remote code execution vulnerabilities, update now' and the four release posts go up. | stated | php.net oss-security Daubois |\n| 2026-10-21 14:04 UTC | OpenAI posts: models 'helped researchers ... discover critical security flaws in PHP ... used to run an estimated 70% of websites'. An X Community Note later disputes OpenAI's role. | stated | OpenAI on X |\n| 2026-10-21 14:06:22 UTC | The fix commit enters the public php-src branches (commit timestamp); merged into 8.3 at 14:12, 8.4 at 14:27 and 8.5 at 14:30 UTC. | stated | php/php-src , read from a clone |\n| 2026-10-21 14:06:46 UTC | GitHub release php-8.5.12 is published by adoy. | stated | php-src |\n| 2026-10-21 14:17:09 UTC | NVD publishes both CVEs with the CNA's CVSS v4.0 9.2 and no NIST score. | stated | NVD NVD |\n| 2026-10-21 14:41:54 UTC | Jakub Zelenka announces CVE-2026-109618 on oss-security; CVE-2026-109619 at 14:44:06Z. | stated | oss-security oss-security |\n\n## Three accounts of what leaked\n\n- **The PHP Foundation:** the CVE IDs, a wrong release time and a wrong CVSS; *No technical details leaked.* Then Calif's video, then possibly the mitigation advice, then Chainguard's images.\n\n- **Alexandre Daubois (PHP security team, writing personally):** an anonymous Hacker News post citing a reliable source, screenshots of it, a screenshot of the *PHP2Shell tool* credited to Calif.io *alongside the advisory*, a short exploitation video, and watchTowr confirming both CVE numbers in public.\n\n- **The Hacker News:** *details about the CVE identifiers and a proof-of-concept (PoC) exploit leaked ahead of time*, and Amazon's evidence that somebody was trying an exploit four days before any of this.\n\nCalif's own write-up has a timeline that ends *October 21 Patched versions released* and does not mention a leak, a deleted video, or the Foundation's account. Chainguard's reply is behind a bot challenge; the search snippet says it does not dispute the time and denies leaking. The vault records both blocks.\n\nPHP Foundation Daubois THN Calif Techzine\n\n## The claims on the leak and on timing\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src , read from a clone php-src |"
    },
    {
     "v": 4,
     "hash": "c642de33224f",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# How the coordinated disclosure broke\n\nHour 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.\n\n# How the disclosure broke\n\nIn plain English The plan was to publish the fix and the details together on 22 October. The secret leaked on the 20th; this page is the hour-by-hour account.\n\nThe plan was 22 October at 14:00 UTC. From about 15:00 UTC on 20 October the CVE IDs were loose with a wrong score; by 19:30 the project had pre-announced a release a day early; by 20:00 one of the reporters had published a demonstration video; by 23:00 mitigation advice was going to critical-infrastructure providers; by 02:00 on the 21st Amazon was seeing proof-of-concept attempts; by 03:02 Cloudflare's rules were live; by 07:41 Chainguard had shipped patched images; by 08:36 a sensor network had its first hit. The release went out at 13:34 UTC. Every one of those times is from a party's own account, and the parties disagree on what was leaked and by whom.\n\n| When (UTC) | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-17 | An exploit attempt from an anonymisation-network IP hits an Amazon MadPot honeypot.As Amazon's CISO told The Hacker News; no primary Amazon post found. | stated | THN |\n| 2026-10-20 | Swiss BACS posts a warning (home-page teaser dated 20 October; the page itself now says 21 October). | inferred | Swiss BACS BACS |\n| 2026-10-20 | Qualys publishes on the pre-announcement. | stated | Qualys |\n| 2026-10-20 15:00 UTC | The two CVE IDs begin circulating on forums and social media with a wrong release time and a wrong CVSS of 10.0. Per Daubois: an anonymous Hacker News post, then screenshots, a 'PHP2Shell tool' screenshot credited to Calif.io, a short exploitation video, and watchTowr posting both CVE numbers.'around 15:00 UTC' per the Foundation. | stated | PHP Foundation Daubois |\n| 2026-10-20 19:30 UTC | php.net publishes the pre-announcement: release moved to 21 October 14:00 UTC, two critical vulnerabilities, CVSS v4.0 9.2, 'we reserve the right to release earlier'.19:30 UTC per the Foundation; the php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC. | disputed | PHP Foundation oss-security php.net |\n| 2026-10-20 20:00 UTC | Calif 'mistakenly published a video' showing its proof of concept against several targets; copies circulate after it is deleted.'around 20:00 UTC'. Calif's page does not mention it. | stated | PHP Foundation PHP Foundation |\n| 2026-10-20 20:22:51 UTC | Alan Coopersmith relays the php.net pre-announcement to oss-security. | stated | oss-security |\n| 2026-10-20 23:00 UTC | The PHP project starts giving mitigation advice to a few critical-infrastructure providers; it 'may have leaked as well'. | stated | PHP Foundation |\n| 2026-10-21 02:00 UTC | Amazon sees proof-of-concept attempts, then six hours of attempts from anonymised infrastructure. | stated | THN |\n| 2026-10-21 07:41 UTC | Chainguard publishes built images containing the fix, 'more than six hours before the coordinated release'.Chainguard reportedly denies leaking; that article is blocked. | stated | PHP Foundation Techzine |\n| 2026-10-21 07:43 UTC | Cloudflare's CTO reports early attacks emerging, before the release.Second-hand; the post itself is not captured. | stated | Insurance Business SecurityWeek |\n| 2026-10-21 08:36 UTC | ELLIO records its first sensor hit. | stated | THN PHP Foundation |\n| 2026-10-21 13:30 UTC | CERT-EU's stated release time for the PHP fixes.Differs from the planned 14:00 UTC and from the 13:35 UTC tags. | stated | CERT-EU |\n| 2026-10-21 13:32 UTC | Wiz posts 'BREAKING ... #PHP2SHELL ... impacting 70% of the Internet', 28 minutes before the planned release; the thread still says 'Apply the Oct 22 security release'. | stated | Wiz on X |\n| 2026-10-21 13:34:13 UTC | GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) and, twelve seconds later, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) are published by bukka. | stated | PHP PHP |\n| 2026-10-21 13:35:38 UTC | Signed tags php-8.5.12, php-8.4.27, php-8.3.36 and php-8.2.35 are created. | stated | php-src |\n| 2026-10-21 13:48:34 UTC | The CVE record for CVE-2026-109618 is published; CVE-2026-109619 follows at 13:54:43Z. | stated | CVE record CVE record |\n| 2026-10-21 14:00 UTC | The planned release time. php.net's advisory 'Critical remote code execution vulnerabilities, update now' and the four release posts go up. | stated | php.net oss-security Daubois |\n| 2026-10-21 14:04 UTC | OpenAI posts: models 'helped researchers ... discover critical security flaws in PHP ... used to run an estimated 70% of websites'. An X Community Note later disputes OpenAI's role. | stated | OpenAI on X |\n| 2026-10-21 14:06:22 UTC | The fix commit enters the public php-src branches (commit timestamp); merged into 8.3 at 14:12, 8.4 at 14:27 and 8.5 at 14:30 UTC. | stated | php/php-src, read from a clone |\n| 2026-10-21 14:06:46 UTC | GitHub release php-8.5.12 is published by adoy. | stated | php-src |\n| 2026-10-21 14:17:09 UTC | NVD publishes both CVEs with the CNA's CVSS v4.0 9.2 and no NIST score. | stated | NVD NVD |\n| 2026-10-21 14:41:54 UTC | Jakub Zelenka announces CVE-2026-109618 on oss-security; CVE-2026-109619 at 14:44:06Z. | stated | oss-security oss-security |\n\n## Three accounts of what leaked\n\n- **The PHP Foundation:** the CVE IDs, a wrong release time and a wrong CVSS; *No technical details leaked.* Then Calif's video, then possibly the mitigation advice, then Chainguard's images.\n\n- **Alexandre Daubois (PHP security team, writing personally):** an anonymous Hacker News post citing a reliable source, screenshots of it, a screenshot of the *PHP2Shell tool* credited to Calif.io *alongside the advisory*, a short exploitation video, and watchTowr confirming both CVE numbers in public.\n\n- **The Hacker News:** *details about the CVE identifiers and a proof-of-concept (PoC) exploit leaked ahead of time*, and Amazon's evidence that somebody was trying an exploit four days before any of this.\n\nCalif's own write-up has a timeline that ends *October 21 Patched versions released* and does not mention a leak, a deleted video, or the Foundation's account. Chainguard's reply is behind a bot challenge; the search snippet says it does not dispute the time and denies leaking. The vault records both blocks.\n\nPHP Foundation Daubois THN Calif Techzine\n\n## The claims on the leak and on timing\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src, read from a clone php-src |"
    },
    {
     "v": 5,
     "hash": "63d1f23d2040",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# How the coordinated disclosure broke\n\nHour 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.\n\n# How the disclosure broke\n\nIn plain English The plan was to publish the fix and the details together on 22 October. The secret leaked on the 20th; this page is the hour-by-hour account.\n\nThe plan was 22 October at 14:00 UTC. From about 15:00 UTC on 20 October the CVE IDs were loose with a wrong score; by 19:30 the project had pre-announced a release a day early; by 20:00 one of the reporters had published a demonstration video; by 23:00 mitigation advice was going to critical-infrastructure providers; by 02:00 on the 21st Amazon was seeing proof-of-concept attempts; by 03:02 Cloudflare's rules were live; by 07:41 Chainguard had shipped patched images; by 08:36 a sensor network had its first hit. The release went out at 13:34 UTC. Every one of those times is from a party's own account, and the parties disagree on what was leaked and by whom.\n\n| When (UTC) | What | Time is | Sources |\n|---|---|---|---|\n| 2026-10-17 | An exploit attempt from an anonymisation-network IP hits an Amazon MadPot honeypot.As Amazon's CISO told The Hacker News; no primary Amazon post found. | stated | THN |\n| 2026-10-20 | Swiss BACS posts a warning (home-page teaser dated 20 October; the page itself now says 21 October). | inferred | Swiss BACS BACS |\n| 2026-10-20 | Qualys publishes on the pre-announcement. | stated | Qualys |\n| 2026-10-20 15:00 UTC | The two CVE IDs begin circulating on forums and social media with a wrong release time and a wrong CVSS of 10.0. Per Daubois: an anonymous Hacker News post, then screenshots, a 'PHP2Shell tool' screenshot credited to Calif.io, a short exploitation video, and watchTowr posting both CVE numbers.'around 15:00 UTC' per the Foundation. | stated | PHP Foundation Daubois |\n| 2026-10-20 19:30 UTC | php.net publishes the pre-announcement: release moved to 21 October 14:00 UTC, two critical vulnerabilities, CVSS v4.0 9.2, 'we reserve the right to release earlier'.19:30 UTC per the Foundation; the php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC. | disputed | PHP Foundation oss-security php.net |\n| 2026-10-20 20:00 UTC | Calif 'mistakenly published a video' showing its proof of concept against several targets; copies circulate after it is deleted.'around 20:00 UTC'. Calif's page does not mention it. | stated | PHP Foundation PHP Foundation |\n| 2026-10-20 20:22:51 UTC | Alan Coopersmith relays the php.net pre-announcement to oss-security. | stated | oss-security |\n| 2026-10-20 23:00 UTC | The PHP project starts giving mitigation advice to a few critical-infrastructure providers; it 'may have leaked as well'. | stated | PHP Foundation |\n| 2026-10-21 02:00 UTC | Amazon sees proof-of-concept attempts, then six hours of attempts from anonymised infrastructure. | stated | THN |\n| 2026-10-21 07:41 UTC | Chainguard publishes built images containing the fix, 'more than six hours before the coordinated release'.Chainguard reportedly denies leaking; that article is blocked. | stated | PHP Foundation Techzine |\n| 2026-10-21 07:43 UTC | Cloudflare's CTO reports early attacks emerging, before the release.Second-hand; the post itself is not captured. | stated | Insurance Business SecurityWeek |\n| 2026-10-21 08:36 UTC | ELLIO records its first sensor hit. | stated | THN PHP Foundation |\n| 2026-10-21 13:30 UTC | CERT-EU's stated release time for the PHP fixes.Differs from the planned 14:00 UTC and from the 13:35 UTC tags. | stated | CERT-EU |\n| 2026-10-21 13:32 UTC | Wiz posts 'BREAKING ... #PHP2SHELL ... impacting 70% of the Internet', 28 minutes before the planned release; the thread still says 'Apply the Oct 22 security release'. | stated | Wiz on X |\n| 2026-10-21 13:34:13 UTC | GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) and, twelve seconds later, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) are published by bukka. | stated | PHP PHP |\n| 2026-10-21 13:35:38 UTC | Signed tags php-8.5.12, php-8.4.27, php-8.3.36 and php-8.2.35 are created. | stated | php-src |\n| 2026-10-21 13:48:34 UTC | The CVE record for CVE-2026-109618 is published; CVE-2026-109619 follows at 13:54:43Z. | stated | CVE record CVE record |\n| 2026-10-21 14:00 UTC | The planned release time. php.net's advisory 'Critical remote code execution vulnerabilities, update now' and the four release posts go up. | stated | php.net oss-security Daubois |\n| 2026-10-21 14:04 UTC | OpenAI posts: models 'helped researchers ... discover critical security flaws in PHP ... used to run an estimated 70% of websites'. An X Community Note later disputes OpenAI's role. | stated | OpenAI on X |\n| 2026-10-21 14:06:22 UTC | The fix commit enters the public php-src branches (commit timestamp); merged into 8.3 at 14:12, 8.4 at 14:27 and 8.5 at 14:30 UTC. | stated | php/php-src, read from a clone |\n| 2026-10-21 14:06:46 UTC | GitHub release php-8.5.12 is published by adoy. | stated | php-src |\n| 2026-10-21 14:17:09 UTC | NVD publishes both CVEs with the CNA's CVSS v4.0 9.2 and no NIST score. | stated | NVD NVD |\n| 2026-10-21 14:41:54 UTC | Jakub Zelenka announces CVE-2026-109618 on oss-security; CVE-2026-109619 at 14:44:06Z. | stated | oss-security oss-security |\n\n## Three accounts of what leaked\n\n- **The PHP Foundation:** the CVE IDs, a wrong release time and a wrong CVSS; *No technical details leaked.* Then Calif's video, then possibly the mitigation advice, then Chainguard's images.\n\n- **Alexandre Daubois (PHP security team, writing personally):** an anonymous Hacker News post citing a reliable source, screenshots of it, a screenshot of the *PHP2Shell tool* credited to Calif.io *alongside the advisory*, a short exploitation video, and watchTowr confirming both CVE numbers in public.\n\n- **The Hacker News:** *details about the CVE identifiers and a proof-of-concept (PoC) exploit leaked ahead of time*, and Amazon's evidence that somebody was trying an exploit four days before any of this.\n\nCalif's own write-up has a timeline that ends *October 21 Patched versions released* and does not mention a leak, a deleted video, or the Foundation's account. Chainguard's reply is behind a bot challenge; the search snippet says it does not dispute the time and denies leaking. The vault records both blocks.\n\nPHP Foundation Daubois THN Calif Techzine\n\n## The claims on the leak and on timing\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | **A2** Reported●●○○○○ disputed | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | **A4** Corroborated●●●●○○ | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | **A3** Echoed●●●○○○ | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | **A2** Reported●●○○○○ | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | **A2** Reported●●○○○○ opinion disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | **A4** Corroborated●●●●○○ measures differently status overstated | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | refuted measures differently | 2/3 | BBC News php.net php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | **A2** Reported●●○○○○ disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | **A2** Reported●●○○○○ disputed | 3/3 | PHP Foundation oss-security php.net |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | **A6** Established●●●●●● | 2/2 | php/php-src, read from a clone php-src |"
    }
   ]
  },
  "page-exploitation": {
   "title": "Exploitation signals",
   "kind": "page",
   "path": "exploitation/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "4ee022827b0e",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Exploitation signals, in order\n\nEvery 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.\n\n# Exploitation: the signals, in order\n\nA remote code execution bug is not an invisibility cloak. If millions of systems were being exploited, the signals would be everywhere: honeypots, WAF logs, national CERTs, the KEV catalog. What the captured sources carry is 14 signals, from one honeypot hit four days before disclosure to one agency's unattributed *reports of active exploitation*, and no confirmed compromise of a named system. That is the state as of the latest capture, and this page will change.\n\n| When (UTC) | Who | What | Kind | Status | Sources |\n|---|---|---|---|---|---|\n| 2026-10-17 | Amazon (CJ Moses, via The Hacker News) | One exploit attempt against a MadPot honeypot from an IP on a commercial anonymisation network, geolocated to Australia, four days before disclosure. 'It remains unclear how the actor acquired exploit information prior to disclosure.' | attempt | reported | THN |\n| 2026-10-20 to 21 | Cloudflare | 'We observed attack traffic targeting our customers' after the leak, and attackers 'mutating the attack payload to try to bypass our protections'. No volumes given. | attack traffic | reported (primary party) | Cloudflare |\n| 2026-10-21 | CISA (alert) | 'CISA has not observed exploitation of these vulnerabilities as of the time of publication.' Neither CVE is in the Known Exploited Vulnerabilities catalog (version 2026.10.21, fetched 2026-10-22T08:15Z). | negative finding | confirmed (primary) | CISA CISA CISA |\n| 2026-10-21 | CCCS (Canada) | 'a Proof of Concept (PoC) is available, with no active exploitation being identified at this time, but that can change quickly.' | assessment | confirmed (primary) | CCCS |\n| 2026-10-21 | PHP Foundation | 'did not identify any functional exploits at the time of release/public disclosure.' | negative finding | reported (primary party) | PHP Foundation |\n| 2026-10-21 02:00 UTC | Amazon (via The Hacker News) | Proof-of-concept attempts begin, then six hours of attempts from anonymised infrastructure; 'multiple threat actors'. | attempts | reported | THN |\n| 2026-10-21 08:36 UTC | ELLIO (via The Hacker News and a comment under the PHP Foundation post) | First sensor hit, about 55 minutes after Chainguard's images. | sensor hit | reported | THN PHP Foundation |\n| 2026-10-21 14:34 UTC | CISA (ADP, SSVC on the CVE record) | Exploitation: none. Automatable: no. Technical impact: total. | assessment | confirmed (primary) | CVE record CVE record |\n| 2026-10-21 20:00 UTC | CERT.LV (Latvia) | Automated exploitation attempts seen in Latvia; no reports of successful attacks. | attempts | confirmed (primary) | CERT.LV |\n| 2026-10-21 20:15 UTC | NCSC New Zealand | 'The NCSC is aware of reports of active exploitation.' Whose reports is not said. | claim of exploitation | reported, sole agency | NCSC New Zealand |\n| 2026-10-22 | ASD's ACSC (Australia) | 'not aware of successful active exploitation within Australia'. | negative finding | confirmed (primary) | ACSC |\n| 2026-10-22 | Alan Woodward, on the BBC | Amazon and Cloudflare saw sites being probed for the flaw. | second-hand | reported; Cloudflare's own post confirms attack traffic, Amazon's own post not found | BBC News Cloudflare THN |\n| 2026-10-22 | unnamed researchers, on the BBC | Criminals are using AI to 'vibe code' an attack method. | claim | unverified | BBC News |\n| 2026-10-22 07:00 UTC | Ryan Austin, Calif, on BBC Radio 4 | No evidence of exploitation yet: 'Not at the moment'. | statement | reported | BBC News |\n\n## What exploitation would look like\n\n- **On the host:** CISA's signal is *PHP worker processes launching shells or downloading tools*. The exploit runs as the web worker, so a worker spawning `sh`, `curl` or `wget`, or writing outside its document root, is the thing to alert on.\n\n- **In the request log:** CERT-FR's workaround is to block or monitor multipart requests, because the confirmed session path rides on session upload progress; php.net's limits are on decoded request size, field count, multipart part count, header count and nesting depth. Unusual values of those are the request-side signal for the OOM path.\n\n- **What a clean log does not prove:** JPCERT warns that with several exploit paths, one detection rule can miss an attack and the absence of traces does not prove the absence of compromise. The UK NCSC says a system that cannot be patched or disabled should be assessed for backdoors.\n\n- **Upstream:** Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads; a WAF is a signal source as well as a control, and the Swiss agency's caveat is that it is not a sufficient control on its own.\n\nCISA CERT-FR php.net JPCERT/CC NCSC UK Cloudflare BACS\n\n## The Known Exploited Vulnerabilities catalog\n\nCISA adds a CVE to KEV when it has reliable evidence of exploitation in the wild. At catalog version 2026.10.21, released 2026-10-21 14:04:39 UTC and fetched 2026-10-22 08:15 UTC, neither CVE-2026-109618 nor CVE-2026-109619 is listed; the catalog has 1,754 entries and its newest additions are dated 20 October. CISA's vulnerability-enrichment assessment on both CVE records at 14:34 UTC says exploitation *none*. This is a point-in-time negative finding; the vault keeps the file and its hash so that the time can be proven later. CISA CISA CVE record"
    },
    {
     "v": 2,
     "hash": "3fd13538b9c9",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Exploitation signals, in order\n\nEvery 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.\n\n# Exploitation: the signals, in order\n\nA remote code execution bug is not an invisibility cloak. If millions of systems were being exploited, the signals would be everywhere: honeypots, WAF logs, national CERTs, the KEV catalog. What the captured sources carry is 20 signals, from one honeypot hit four days before disclosure to one agency's unattributed *reports of active exploitation*, and no confirmed compromise of a named system. That is the state as of the latest capture, and this page will change.\n\n| When (UTC) | Who | What | Kind | Status | Sources |\n|---|---|---|---|---|---|\n| 2026-10-17 | Amazon (CJ Moses, AWS Security Blog) | One exploit attempt against a MadPot honeypot from a commercial anonymisation network, four days before disclosure; 'it remains unclear how the actor acquired exploit information prior to disclosure'. | attempt | reported (primary party) | Amazon |\n| 2026-10-17 | Amazon (CJ Moses, via The Hacker News) | One exploit attempt against a MadPot honeypot from an IP on a commercial anonymisation network, geolocated to Australia, four days before disclosure. 'It remains unclear how the actor acquired exploit information prior to disclosure.' | attempt | reported | THN |\n| 2026-10-20 to 21 | Cloudflare | 'We observed attack traffic targeting our customers' after the leak, and attackers 'mutating the attack payload to try to bypass our protections'. No volumes given. | attack traffic | reported (primary party) | Cloudflare |\n| 2026-10-21 | CISA (alert) | 'CISA has not observed exploitation of these vulnerabilities as of the time of publication.' Neither CVE is in the Known Exploited Vulnerabilities catalog (version 2026.10.21, fetched 2026-10-22T08:15Z). | negative finding | confirmed (primary) | CISA CISA CISA |\n| 2026-10-21 | CCCS (Canada) | 'a Proof of Concept (PoC) is available, with no active exploitation being identified at this time, but that can change quickly.' | assessment | confirmed (primary) | CCCS |\n| 2026-10-21 | PHP Foundation | 'did not identify any functional exploits at the time of release/public disclosure.' | negative finding | reported (primary party) | PHP Foundation |\n| 2026-10-21 | Imperva | No traffic matching the exploit patterns during pre-disclosure monitoring of customer traffic. | negative finding | reported (primary party) | Imperva Threat Research |\n| 2026-10-21 | watchTowr | Active exploitation attempts; the flaws listed as exploited in the wild. | claim | unverified: the site blocks capture | watchTowr |\n| 2026-10-21 02:00 UTC | Amazon (via The Hacker News) | Proof-of-concept attempts begin, then six hours of attempts from anonymised infrastructure; 'multiple threat actors'. | attempts | reported | THN |\n| 2026-10-21 08:36 UTC | ELLIO (via The Hacker News and a comment under the PHP Foundation post) | First sensor hit, about 55 minutes after Chainguard's images. | sensor hit | reported | THN PHP Foundation |\n| 2026-10-21 14:34 UTC | CISA (ADP, SSVC on the CVE record) | Exploitation: none. Automatable: no. Technical impact: total. | assessment | confirmed (primary) | CVE record CVE record |\n| 2026-10-21 20:00 UTC | CERT.LV (Latvia) | Automated exploitation attempts seen in Latvia; no reports of successful attacks. | attempts | confirmed (primary) | CERT.LV |\n| 2026-10-21 20:15 UTC | NCSC New Zealand | 'The NCSC is aware of reports of active exploitation.' Whose reports is not said. | claim of exploitation | reported, sole agency | NCSC New Zealand |\n| 2026-10-21 20:30 UTC | Huntress | No exploitation observed on partner systems; no public exploit code known. | negative finding | reported (primary party) | Huntress |\n| 2026-10-22 | ASD's ACSC (Australia) | 'not aware of successful active exploitation within Australia'. | negative finding | confirmed (primary) | ACSC |\n| 2026-10-22 | Alan Woodward, on the BBC | Amazon and Cloudflare saw sites being probed for the flaw. | second-hand | reported; Cloudflare's own post confirms attack traffic, Amazon's own post not found | BBC News Cloudflare THN |\n| 2026-10-22 | unnamed researchers, on the BBC | Criminals are using AI to 'vibe code' an attack method. | claim | unverified | BBC News |\n| 2026-10-22 | Dan Lorenc, Chainguard, via The Register | Chainguard's honeypots trapped IPs from China and Russia; several unnamed vendors reported exploits in the wild. | claim | reported, second-hand | The Register |\n| 2026-10-22 01:25 UTC | Matthew Prince, Cloudflare | Thousands of attempts in the ten hours before announcement; tens of thousands within 45 minutes after; hundreds of thousands within two hours; millions now. | attempts | reported (primary party) | Matthew Prince , Cloudflare CEO on |\n| 2026-10-22 07:00 UTC | Ryan Austin, Calif, on BBC Radio 4 | No evidence of exploitation yet: 'Not at the moment'. | statement | reported | BBC News |\n\n## What exploitation would look like\n\n- **On the host:** CISA's signal is *PHP worker processes launching shells or downloading tools*. The exploit runs as the web worker, so a worker spawning `sh`, `curl` or `wget`, or writing outside its document root, is the thing to alert on.\n\n- **In the request log:** CERT-FR's workaround is to block or monitor multipart requests, because the confirmed session path rides on session upload progress; php.net's limits are on decoded request size, field count, multipart part count, header count and nesting depth. Unusual values of those are the request-side signal for the OOM path.\n\n- **What a clean log does not prove:** JPCERT warns that with several exploit paths, one detection rule can miss an attack and the absence of traces does not prove the absence of compromise. The UK NCSC says a system that cannot be patched or disabled should be assessed for backdoors.\n\n- **Upstream:** Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads; a WAF is a signal source as well as a control, and the Swiss agency's caveat is that it is not a sufficient control on its own.\n\nCISA CERT-FR php.net JPCERT/CC NCSC UK Cloudflare BACS\n\n## The Known Exploited Vulnerabilities catalog\n\nCISA adds a CVE to KEV when it has reliable evidence of exploitation in the wild. At catalog version 2026.10.21, released 2026-10-21 14:04:39 UTC and fetched 2026-10-22 08:15 UTC, neither CVE-2026-109618 nor CVE-2026-109619 is listed; the catalog has 1,754 entries and its newest additions are dated 20 October. CISA's vulnerability-enrichment assessment on both CVE records at 14:34 UTC says exploitation *none*. This is a point-in-time negative finding; the vault keeps the file and its hash so that the time can be proven later. CISA CISA CVE record"
    },
    {
     "v": 3,
     "hash": "3bcb3c218979",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Exploitation signals, in order\n\nEvery 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.\n\n# Exploitation: the signals, in order\n\nIn plain English Every sign of attackers trying to use the flaws, in order. Lots of attempts; no confirmed break-in of a named organisation yet.\n\nA remote code execution bug is not an invisibility cloak. If millions of systems were being exploited, the signals would be everywhere: honeypots, WAF logs, national CERTs, the KEV catalog. What the captured sources carry is 20 signals, from one honeypot hit four days before disclosure to one agency's unattributed *reports of active exploitation*, and no confirmed compromise of a named system. That is the state as of the latest capture, and this page will change.\n\n| When (UTC) | Who | What | Kind | Status | Sources |\n|---|---|---|---|---|---|\n| 2026-10-17 | Amazon (CJ Moses, AWS Security Blog) | One exploit attempt against a MadPot honeypot from a commercial anonymisation network, four days before disclosure; 'it remains unclear how the actor acquired exploit information prior to disclosure'. | attempt | reported (primary party) | Amazon |\n| 2026-10-17 | Amazon (CJ Moses, via The Hacker News) | One exploit attempt against a MadPot honeypot from an IP on a commercial anonymisation network, geolocated to Australia, four days before disclosure. 'It remains unclear how the actor acquired exploit information prior to disclosure.' | attempt | reported | THN |\n| 2026-10-20 to 21 | Cloudflare | 'We observed attack traffic targeting our customers' after the leak, and attackers 'mutating the attack payload to try to bypass our protections'. No volumes given. | attack traffic | reported (primary party) | Cloudflare |\n| 2026-10-21 | CISA (alert) | 'CISA has not observed exploitation of these vulnerabilities as of the time of publication.' Neither CVE is in the Known Exploited Vulnerabilities catalog (version 2026.10.21, fetched 2026-10-22T08:15Z). | negative finding | confirmed (primary) | CISA CISA CISA |\n| 2026-10-21 | CCCS (Canada) | 'a Proof of Concept (PoC) is available, with no active exploitation being identified at this time, but that can change quickly.' | assessment | confirmed (primary) | CCCS |\n| 2026-10-21 | PHP Foundation | 'did not identify any functional exploits at the time of release/public disclosure.' | negative finding | reported (primary party) | PHP Foundation |\n| 2026-10-21 | Imperva | No traffic matching the exploit patterns during pre-disclosure monitoring of customer traffic. | negative finding | reported (primary party) | Imperva Threat Research |\n| 2026-10-21 | watchTowr | Active exploitation attempts; the flaws listed as exploited in the wild. | claim | unverified: the site blocks capture | watchTowr |\n| 2026-10-21 02:00 UTC | Amazon (via The Hacker News) | Proof-of-concept attempts begin, then six hours of attempts from anonymised infrastructure; 'multiple threat actors'. | attempts | reported | THN |\n| 2026-10-21 08:36 UTC | ELLIO (via The Hacker News and a comment under the PHP Foundation post) | First sensor hit, about 55 minutes after Chainguard's images. | sensor hit | reported | THN PHP Foundation |\n| 2026-10-21 14:34 UTC | CISA (ADP, SSVC on the CVE record) | Exploitation: none. Automatable: no. Technical impact: total. | assessment | confirmed (primary) | CVE record CVE record |\n| 2026-10-21 20:00 UTC | CERT.LV (Latvia) | Automated exploitation attempts seen in Latvia; no reports of successful attacks. | attempts | confirmed (primary) | CERT.LV |\n| 2026-10-21 20:15 UTC | NCSC New Zealand | 'The NCSC is aware of reports of active exploitation.' Whose reports is not said. | claim of exploitation | reported, sole agency | NCSC New Zealand |\n| 2026-10-21 20:30 UTC | Huntress | No exploitation observed on partner systems; no public exploit code known. | negative finding | reported (primary party) | Huntress |\n| 2026-10-22 | ASD's ACSC (Australia) | 'not aware of successful active exploitation within Australia'. | negative finding | confirmed (primary) | ACSC |\n| 2026-10-22 | Alan Woodward, on the BBC | Amazon and Cloudflare saw sites being probed for the flaw. | second-hand | reported; Cloudflare's own post confirms attack traffic, Amazon's own post not found | BBC News Cloudflare THN |\n| 2026-10-22 | unnamed researchers, on the BBC | Criminals are using AI to 'vibe code' an attack method. | claim | unverified | BBC News |\n| 2026-10-22 | Dan Lorenc, Chainguard, via The Register | Chainguard's honeypots trapped IPs from China and Russia; several unnamed vendors reported exploits in the wild. | claim | reported, second-hand | The Register |\n| 2026-10-22 01:25 UTC | Matthew Prince, Cloudflare | Thousands of attempts in the ten hours before announcement; tens of thousands within 45 minutes after; hundreds of thousands within two hours; millions now. | attempts | reported (primary party) | Matthew Prince , Cloudflare CEO on |\n| 2026-10-22 07:00 UTC | Ryan Austin, Calif, on BBC Radio 4 | No evidence of exploitation yet: 'Not at the moment'. | statement | reported | BBC News |\n\n## What exploitation would look like\n\n- **On the host:** CISA's signal is *PHP worker processes launching shells or downloading tools*. The exploit runs as the web worker, so a worker spawning `sh`, `curl` or `wget`, or writing outside its document root, is the thing to alert on.\n\n- **In the request log:** CERT-FR's workaround is to block or monitor multipart requests, because the confirmed session path rides on session upload progress; php.net's limits are on decoded request size, field count, multipart part count, header count and nesting depth. Unusual values of those are the request-side signal for the OOM path.\n\n- **What a clean log does not prove:** JPCERT warns that with several exploit paths, one detection rule can miss an attack and the absence of traces does not prove the absence of compromise. The UK NCSC says a system that cannot be patched or disabled should be assessed for backdoors.\n\n- **Upstream:** Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads; a WAF is a signal source as well as a control, and the Swiss agency's caveat is that it is not a sufficient control on its own.\n\nCISA CERT-FR php.net JPCERT/CC NCSC UK Cloudflare BACS\n\n## The Known Exploited Vulnerabilities catalog\n\nCISA adds a CVE to KEV when it has reliable evidence of exploitation in the wild. At catalog version 2026.10.21, released 2026-10-21 14:04:39 UTC and fetched 2026-10-22 08:15 UTC, neither CVE-2026-109618 nor CVE-2026-109619 is listed; the catalog has 1,754 entries and its newest additions are dated 20 October. CISA's vulnerability-enrichment assessment on both CVE records at 14:34 UTC says exploitation *none*. This is a point-in-time negative finding; the vault keeps the file and its hash so that the time can be proven later. CISA CISA CVE record"
    },
    {
     "v": 4,
     "hash": "3e18fb6db341",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Exploitation signals, in order\n\nEvery 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.\n\n# Exploitation: the signals, in order\n\nIn plain English Every sign of attackers trying to use the flaws, in order. Lots of attempts; no confirmed break-in of a named organisation yet.\n\nA remote code execution bug is not an invisibility cloak. If millions of systems were being exploited, the signals would be everywhere: honeypots, WAF logs, national CERTs, the KEV catalog. What the captured sources carry is 20 signals, from one honeypot hit four days before disclosure to one agency's unattributed *reports of active exploitation*, and no confirmed compromise of a named system. That is the state as of the latest capture, and this page will change.\n\n| When (UTC) | Who | What | Kind | Status | Sources |\n|---|---|---|---|---|---|\n| 2026-10-17 | Amazon (CJ Moses, AWS Security Blog) | One exploit attempt against a MadPot honeypot from a commercial anonymisation network, four days before disclosure; 'it remains unclear how the actor acquired exploit information prior to disclosure'. | attempt | reported (primary party) | Amazon |\n| 2026-10-17 | Amazon (CJ Moses, via The Hacker News) | One exploit attempt against a MadPot honeypot from an IP on a commercial anonymisation network, geolocated to Australia, four days before disclosure. 'It remains unclear how the actor acquired exploit information prior to disclosure.' | attempt | reported | THN |\n| 2026-10-20 to 21 | Cloudflare | 'We observed attack traffic targeting our customers' after the leak, and attackers 'mutating the attack payload to try to bypass our protections'. No volumes given. | attack traffic | reported (primary party) | Cloudflare |\n| 2026-10-21 | CISA (alert) | 'CISA has not observed exploitation of these vulnerabilities as of the time of publication.' Neither CVE is in the Known Exploited Vulnerabilities catalog (version 2026.10.21, fetched 2026-10-22T08:15Z). | negative finding | confirmed (primary) | CISA CISA CISA |\n| 2026-10-21 | CCCS (Canada) | 'a Proof of Concept (PoC) is available, with no active exploitation being identified at this time, but that can change quickly.' | assessment | confirmed (primary) | CCCS |\n| 2026-10-21 | PHP Foundation | 'did not identify any functional exploits at the time of release/public disclosure.' | negative finding | reported (primary party) | PHP Foundation |\n| 2026-10-21 | Imperva | No traffic matching the exploit patterns during pre-disclosure monitoring of customer traffic. | negative finding | reported (primary party) | Imperva Threat Research |\n| 2026-10-21 | watchTowr | Active exploitation attempts; the flaws listed as exploited in the wild. | claim | unverified: the site blocks capture | watchTowr |\n| 2026-10-21 02:00 UTC | Amazon (via The Hacker News) | Proof-of-concept attempts begin, then six hours of attempts from anonymised infrastructure; 'multiple threat actors'. | attempts | reported | THN |\n| 2026-10-21 08:36 UTC | ELLIO (via The Hacker News and a comment under the PHP Foundation post) | First sensor hit, about 55 minutes after Chainguard's images. | sensor hit | reported | THN PHP Foundation |\n| 2026-10-21 14:34 UTC | CISA (ADP, SSVC on the CVE record) | Exploitation: none. Automatable: no. Technical impact: total. | assessment | confirmed (primary) | CVE record CVE record |\n| 2026-10-21 20:00 UTC | CERT.LV (Latvia) | Automated exploitation attempts seen in Latvia; no reports of successful attacks. | attempts | confirmed (primary) | CERT.LV |\n| 2026-10-21 20:15 UTC | NCSC New Zealand | 'The NCSC is aware of reports of active exploitation.' Whose reports is not said. | claim of exploitation | reported, sole agency | NCSC New Zealand |\n| 2026-10-21 20:30 UTC | Huntress | No exploitation observed on partner systems; no public exploit code known. | negative finding | reported (primary party) | Huntress |\n| 2026-10-22 | ASD's ACSC (Australia) | 'not aware of successful active exploitation within Australia'. | negative finding | confirmed (primary) | ACSC |\n| 2026-10-22 | Alan Woodward, on the BBC | Amazon and Cloudflare saw sites being probed for the flaw. | second-hand | reported; Cloudflare's own post confirms attack traffic, Amazon's own post not found | BBC News Cloudflare THN |\n| 2026-10-22 | unnamed researchers, on the BBC | Criminals are using AI to 'vibe code' an attack method. | claim | unverified | BBC News |\n| 2026-10-22 | Dan Lorenc, Chainguard, via The Register | Chainguard's honeypots trapped IPs from China and Russia; several unnamed vendors reported exploits in the wild. | claim | reported, second-hand | The Register |\n| 2026-10-22 01:25 UTC | Matthew Prince, Cloudflare | Thousands of attempts in the ten hours before announcement; tens of thousands within 45 minutes after; hundreds of thousands within two hours; millions now. | attempts | reported (primary party) | Matthew Prince, Cloudflare CEO on… |\n| 2026-10-22 07:00 UTC | Ryan Austin, Calif, on BBC Radio 4 | No evidence of exploitation yet: 'Not at the moment'. | statement | reported | BBC News |\n\n## What exploitation would look like\n\n- **On the host:** CISA's signal is *PHP worker processes launching shells or downloading tools*. The exploit runs as the web worker, so a worker spawning `sh`, `curl` or `wget`, or writing outside its document root, is the thing to alert on.\n\n- **In the request log:** CERT-FR's workaround is to block or monitor multipart requests, because the confirmed session path rides on session upload progress; php.net's limits are on decoded request size, field count, multipart part count, header count and nesting depth. Unusual values of those are the request-side signal for the OOM path.\n\n- **What a clean log does not prove:** JPCERT warns that with several exploit paths, one detection rule can miss an attack and the absence of traces does not prove the absence of compromise. The UK NCSC says a system that cannot be patched or disabled should be assessed for backdoors.\n\n- **Upstream:** Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads; a WAF is a signal source as well as a control, and the Swiss agency's caveat is that it is not a sufficient control on its own.\n\nCISA CERT-FR php.net JPCERT/CC NCSC UK Cloudflare BACS\n\n## The Known Exploited Vulnerabilities catalog\n\nCISA adds a CVE to KEV when it has reliable evidence of exploitation in the wild. At catalog version 2026.10.21, released 2026-10-21 14:04:39 UTC and fetched 2026-10-22 08:15 UTC, neither CVE-2026-109618 nor CVE-2026-109619 is listed; the catalog has 1,754 entries and its newest additions are dated 20 October. CISA's vulnerability-enrichment assessment on both CVE records at 14:34 UTC says exploitation *none*. This is a point-in-time negative finding; the vault keeps the file and its hash so that the time can be proven later. CISA CISA CVE record"
    },
    {
     "v": 5,
     "hash": "7cb6b9c26818",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Exploitation signals, in order\n\nEvery 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.\n\n# Exploitation: the signals, in order\n\nIn plain English Every sign of attackers trying to use the flaws, in order. Lots of attempts; no confirmed break-in of a named organisation yet.\n\nA remote code execution bug is not an invisibility cloak. If millions of systems were being exploited, the signals would be everywhere: honeypots, WAF logs, national CERTs, the KEV catalog. What the captured sources carry is 20 signals, from one honeypot hit four days before disclosure to one agency's unattributed *reports of active exploitation*, and no confirmed compromise of a named system. That is the state as of the latest capture, and this page will change.\n\n| When (UTC) | Who | What | Kind | Status | Sources |\n|---|---|---|---|---|---|\n| 2026-10-17 | Amazon (CJ Moses, AWS Security Blog) | One exploit attempt against a MadPot honeypot from a commercial anonymisation network, four days before disclosure; 'it remains unclear how the actor acquired exploit information prior to disclosure'. | attempt | reported (primary party) | Amazon |\n| 2026-10-17 | Amazon (CJ Moses, via The Hacker News) | One exploit attempt against a MadPot honeypot from an IP on a commercial anonymisation network, geolocated to Australia, four days before disclosure. 'It remains unclear how the actor acquired exploit information prior to disclosure.' | attempt | reported | THN |\n| 2026-10-20 to 21 | Cloudflare | 'We observed attack traffic targeting our customers' after the leak, and attackers 'mutating the attack payload to try to bypass our protections'. No volumes given. | attack traffic | reported (primary party) | Cloudflare |\n| 2026-10-21 | CISA (alert) | 'CISA has not observed exploitation of these vulnerabilities as of the time of publication.' Neither CVE is in the Known Exploited Vulnerabilities catalog (version 2026.10.21, fetched 2026-10-22T08:15Z). | negative finding | confirmed (primary) | CISA CISA CISA |\n| 2026-10-21 | CCCS (Canada) | 'a Proof of Concept (PoC) is available, with no active exploitation being identified at this time, but that can change quickly.' | assessment | confirmed (primary) | CCCS |\n| 2026-10-21 | PHP Foundation | 'did not identify any functional exploits at the time of release/public disclosure.' | negative finding | reported (primary party) | PHP Foundation |\n| 2026-10-21 | Imperva | No traffic matching the exploit patterns during pre-disclosure monitoring of customer traffic. | negative finding | reported (primary party) | Imperva Threat Research |\n| 2026-10-21 | watchTowr | Active exploitation attempts; the flaws listed as exploited in the wild. | claim | unverified the site blocks capture | watchTowr |\n| 2026-10-21 02:00 UTC | Amazon (via The Hacker News) | Proof-of-concept attempts begin, then six hours of attempts from anonymised infrastructure; 'multiple threat actors'. | attempts | reported | THN |\n| 2026-10-21 08:36 UTC | ELLIO (via The Hacker News and a comment under the PHP Foundation post) | First sensor hit, about 55 minutes after Chainguard's images. | sensor hit | reported | THN PHP Foundation |\n| 2026-10-21 14:34 UTC | CISA (ADP, SSVC on the CVE record) | Exploitation: none. Automatable: no. Technical impact: total. | assessment | confirmed (primary) | CVE record CVE record |\n| 2026-10-21 20:00 UTC | CERT.LV (Latvia) | Automated exploitation attempts seen in Latvia; no reports of successful attacks. | attempts | confirmed (primary) | CERT.LV |\n| 2026-10-21 20:15 UTC | NCSC New Zealand | 'The NCSC is aware of reports of active exploitation.' Whose reports is not said. | claim of exploitation | reported, sole agency | NCSC New Zealand |\n| 2026-10-21 20:30 UTC | Huntress | No exploitation observed on partner systems; no public exploit code known. | negative finding | reported (primary party) | Huntress |\n| 2026-10-22 | ASD's ACSC (Australia) | 'not aware of successful active exploitation within Australia'. | negative finding | confirmed (primary) | ACSC |\n| 2026-10-22 | Alan Woodward, on the BBC | Amazon and Cloudflare saw sites being probed for the flaw. | second-hand | reported Cloudflare's own post confirms attack traffic, Amazon's own post not found | BBC News Cloudflare THN |\n| 2026-10-22 | unnamed researchers, on the BBC | Criminals are using AI to 'vibe code' an attack method. | claim | unverified | BBC News |\n| 2026-10-22 | Dan Lorenc, Chainguard, via The Register | Chainguard's honeypots trapped IPs from China and Russia; several unnamed vendors reported exploits in the wild. | claim | reported, second-hand | The Register |\n| 2026-10-22 01:25 UTC | Matthew Prince, Cloudflare | Thousands of attempts in the ten hours before announcement; tens of thousands within 45 minutes after; hundreds of thousands within two hours; millions now. | attempts | reported (primary party) | Matthew Prince, Cloudflare CEO on… |\n| 2026-10-22 07:00 UTC | Ryan Austin, Calif, on BBC Radio 4 | No evidence of exploitation yet: 'Not at the moment'. | statement | reported | BBC News |\n\n## What exploitation would look like\n\n- **On the host:** CISA's signal is *PHP worker processes launching shells or downloading tools*. The exploit runs as the web worker, so a worker spawning `sh`, `curl` or `wget`, or writing outside its document root, is the thing to alert on.\n\n- **In the request log:** CERT-FR's workaround is to block or monitor multipart requests, because the confirmed session path rides on session upload progress; php.net's limits are on decoded request size, field count, multipart part count, header count and nesting depth. Unusual values of those are the request-side signal for the OOM path.\n\n- **What a clean log does not prove:** JPCERT warns that with several exploit paths, one detection rule can miss an attack and the absence of traces does not prove the absence of compromise. The UK NCSC says a system that cannot be patched or disabled should be assessed for backdoors.\n\n- **Upstream:** Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads; a WAF is a signal source as well as a control, and the Swiss agency's caveat is that it is not a sufficient control on its own.\n\nCISA CERT-FR php.net JPCERT/CC NCSC UK Cloudflare BACS\n\n## The Known Exploited Vulnerabilities catalog\n\nCISA adds a CVE to KEV when it has reliable evidence of exploitation in the wild. At catalog version 2026.10.21, released 2026-10-21 14:04:39 UTC and fetched 2026-10-22 08:15 UTC, neither CVE-2026-109618 nor CVE-2026-109619 is listed; the catalog has 1,754 entries and its newest additions are dated 20 October. CISA's vulnerability-enrichment assessment on both CVE records at 14:34 UTC says exploitation *none*. This is a point-in-time negative finding; the vault keeps the file and its hash so that the time can be proven later. CISA CISA CVE record"
    }
   ]
  },
  "page-playbook": {
   "title": "If you run PHP",
   "kind": "page",
   "path": "playbook/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "88ffb48154bf",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# If you run PHP: the steps, in order, with their sources\n\nInventory, 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.\n\n# If you run PHP\n\nEvery agency's advice, merged into one ordered list, with the sentence each step comes from. This is a guide to what the sources say, assembled by agents and not reviewed by your security team; the php.net advisory is the authority and your national agency is the one that applies to you. Taking a system offline is the last step on every list, and the one list where it comes earlier is the one that says *isolate, then migrate*.\n\n- 0 ### Know what you run Inventory every system with PHP serving web requests, including the ones you did not build: appliances, vendor products, hosting panels, the thing marketing bought. Do not limit discovery to old versions. Note the SAPI (mod_php, FPM, cgi, FrankenPHP, LiteSpeed) and the PHP branch.NCSC UK CISA NSA NCSC-NL\n- 1 ### Patch, internet-facing first Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's backported package. Restart every worker; rebuild containers. For 7.4, 8.0 and 8.1 there is a source backport branch and no release: plan the migration now. Some third-party repositories (remirepo) had no packages on release day.php.net BACS php-src CERT-EU\n- 2 ### If you cannot patch today, apply the temporary mitigations memory_limit=-1 where applications cannot override it; low post_max_size with proxy-level request limits; a cgroup memory limit instead of RLIMIT; session.upload_progress.enabled=0 then restart every worker; on 8.5 fatal_error_backtraces=0; pm.max_requests=1 on FPM. Each blocks a known path and none makes the installation safe.php.net PHP NCSC-NL\n- 3 ### Put something in front A WAF may provide some protection (CISA); it is not sufficient on its own (Swiss BACS); it blocked what Cloudflare saw while attackers mutated payloads. CERT-FR's edge workaround is to block or monitor multipart Content-Type requests. Restrict access to the people and systems that need it.CISA BACS Cloudflare CERT-FR\n- 4 ### Isolate or take offline Where none of the above is feasible in time: CERT-EU, Canada and France say isolate internet-facing applications from public networks; the NSA and CISA say take the system offline until fully mitigated; the UK NCSC puts this fourth; Latvia geo-blocked state services from abroad for days. Decide who can make that call and how fast it can be executed, and write it down before you need it.CERT-EU CCCS CERT-FR NSA Cyber on X CISA NCSC UK CERT.LV\n- 5 ### Look for compromise PHP workers launching shells or downloading tools; unexpected files under the web root; outbound connections from the web tier; anomalous multipart or oversized requests. A clean log does not prove a clean system (JPCERT); a system that could not be patched or disabled promptly should be assessed for backdoors (NCSC UK).CISA JPCERT/CC NCSC UK NCSC New Zealand\n- 6 ### Verify, then keep watching Confirm the running version after the restart, not the package version before it. Check vendors that bundle PHP for their own fixes. Watch for a follow-up release: a report that the 8.5.12 fix may be incomplete reached oss-security within two hours and has not been answered on-list.BACS NCSC-NL oss-security\n\n## Pulling the plug, as a capability\n\nFour agencies told organisations to be ready to take systems offline within hours. How long it takes you to do that for one system, cleanly, with a holding page and a way back, is a measurable property of your stack, and it is the property this incident tested. A system that can be removed from the internet in minutes without data loss is one you can afford to leave running until the patch is tested; a system that cannot is one you take offline early, because you will not be able to later. The site's own position is that the decision belongs to a named person and the execution belongs to a rehearsed runbook, and that the inventory in step 0 is where both start.\n\nThe technical detail behind each step is on the two flaws; which versions and products are in scope is on affected systems; what the agencies said, agency by agency, is on the agencies."
    },
    {
     "v": 2,
     "hash": "04ed7f7ccac3",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# If you run PHP: the steps, in order, with their sources\n\nInventory, 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.\n\n# If you run PHP\n\nIn plain English What an organisation that runs PHP should do, step by step, merged from every agency's advice.\n\nEvery agency's advice, merged into one ordered list, with the sentence each step comes from. This is a guide to what the sources say, assembled by agents and not reviewed by your security team; the php.net advisory is the authority and your national agency is the one that applies to you. Taking a system offline is the last step on every list, and the one list where it comes earlier is the one that says *isolate, then migrate*.\n\n- 0 ### Know what you run Inventory every system with PHP serving web requests, including the ones you did not build: appliances, vendor products, hosting panels, the thing marketing bought. Do not limit discovery to old versions. Note the SAPI (mod_php, FPM, cgi, FrankenPHP, LiteSpeed) and the PHP branch.NCSC UK CISA NSA NCSC-NL\n- 1 ### Patch, internet-facing first Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's backported package. Restart every worker; rebuild containers. For 7.4, 8.0 and 8.1 there is a source backport branch and no release: plan the migration now. Some third-party repositories (remirepo) had no packages on release day.php.net BACS php-src CERT-EU\n- 2 ### If you cannot patch today, apply the temporary mitigations memory_limit=-1 where applications cannot override it; low post_max_size with proxy-level request limits; a cgroup memory limit instead of RLIMIT; session.upload_progress.enabled=0 then restart every worker; on 8.5 fatal_error_backtraces=0; pm.max_requests=1 on FPM. Each blocks a known path and none makes the installation safe.php.net PHP NCSC-NL\n- 3 ### Put something in front A WAF may provide some protection (CISA); it is not sufficient on its own (Swiss BACS); it blocked what Cloudflare saw while attackers mutated payloads. CERT-FR's edge workaround is to block or monitor multipart Content-Type requests. Restrict access to the people and systems that need it.CISA BACS Cloudflare CERT-FR\n- 4 ### Isolate or take offline Where none of the above is feasible in time: CERT-EU, Canada and France say isolate internet-facing applications from public networks; the NSA and CISA say take the system offline until fully mitigated; the UK NCSC puts this fourth; Latvia geo-blocked state services from abroad for days. Decide who can make that call and how fast it can be executed, and write it down before you need it.CERT-EU CCCS CERT-FR NSA Cyber on X CISA NCSC UK CERT.LV\n- 5 ### Look for compromise PHP workers launching shells or downloading tools; unexpected files under the web root; outbound connections from the web tier; anomalous multipart or oversized requests. A clean log does not prove a clean system (JPCERT); a system that could not be patched or disabled promptly should be assessed for backdoors (NCSC UK).CISA JPCERT/CC NCSC UK NCSC New Zealand\n- 6 ### Verify, then keep watching Confirm the running version after the restart, not the package version before it. Check vendors that bundle PHP for their own fixes. Watch for a follow-up release: a report that the 8.5.12 fix may be incomplete reached oss-security within two hours and has not been answered on-list.BACS NCSC-NL oss-security\n\n## Pulling the plug, as a capability\n\nFour agencies told organisations to be ready to take systems offline within hours. How long it takes you to do that for one system, cleanly, with a holding page and a way back, is a measurable property of your stack, and it is the property this incident tested. A system that can be removed from the internet in minutes without data loss is one you can afford to leave running until the patch is tested; a system that cannot is one you take offline early, because you will not be able to later. The site's own position is that the decision belongs to a named person and the execution belongs to a rehearsed runbook, and that the inventory in step 0 is where both start.\n\nThe technical detail behind each step is on the two flaws; which versions and products are in scope is on affected systems; what the agencies said, agency by agency, is on the agencies."
    }
   ]
  },
  "page-claims": {
   "title": "Every claim",
   "kind": "page",
   "path": "claims/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "dc82de9af351",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Every claim, with its status and sources\n\n49 claims about php2shell, each with who makes it, a status (confirmed, reported, disputed, contradicted or unverified) and the captured sources behind it.\n\n# Every claim, and who makes it\n\n49 claims: 13 confirmed, 22 reported, 8 disputed, 3 contradicted, 3 unverified. A claim is a sentence somebody said, with the party that said it, the captured sources it comes from, and one of five words for how far it can be trusted. The words are defined here, once, and the build refuses a claim whose sources are not in the manifest.\n\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n\n## The flaws themselves\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | CVE record CVE record PHP PHP php.net |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | PHP Foundation Daubois |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | PHP oss-security php.net |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | PHP Foundation PHP PHP oss-security |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | PHP php.net php-src |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | NCSC-NL Wiz on X CERT-FR oss-security |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | php.net oss-security PHP |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | CISA BACS Cloudflare |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | Calif Wiz |\n\n## How big it is\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | Wiz Wiz on X BBC News |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | BBC News |\n| PHP is exposed on 2,608,039 internet-facing hosts | VulnCheck, via The Hacker News | reported | THN |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | CERT.LV |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | NCSC-NL |\n\n## Who found it, and how\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | BBC News OpenAI on X Calif Wiz |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | Calif Ryan Austin , Calif on X PHP Foundation |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | Wiz PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | PHP Foundation Calif |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | OpenAI on X THN |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | BBC News Wiz |\n\n## The leak\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixChainguard reportedly does not dispute the time but denies leaking (Techzine, blocked by a bot challenge; snippet only). | PHP Foundation | disputed | PHP Foundation Techzine |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | PHP Foundation oss-security Wiz on X php.net |\n\n## When things happened\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | BBC News php.net php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | PHP Foundation oss-security php.net |\n\n## Exploitation\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | CISA CISA CVE record |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network, and proof-of-concept attempts started about 02:00 UTC on 21 OctoberAmazon's own post has not been found. | CJ Moses, Amazon, via The Hacker News | reported | THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | Cloudflare |\n| Amazon and Cloudflare saw sites being probed for the flawSecond-hand, but consistent with what both companies have said themselves. | Alan Woodward, via the BBC | reported | BBC News Cloudflare THN |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | CERT.LV |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | BBC News |\n\n## What the agencies advise\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | NSA CISA |\n\n## What was taken offline\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | BBC News |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | CERT.LV |\n\nThe newsroom's own twelve claims, seeded from the BBC live page on the morning of 22 October, are in the vault as `claims/claude-newsroom-lead.json` and are superseded by the rows above, which trace each of them to primary sources. The raw rows are in data/claims.json."
    },
    {
     "v": 2,
     "hash": "f057564d2cee",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Every claim, with its status and sources\n\n70 claims about php2shell, each with who makes it, a status (confirmed, reported, disputed, contradicted or unverified) and the captured sources behind it.\n\n# Every claim, and who makes it\n\n70 claims: 22 confirmed, 33 reported, 8 disputed, 3 contradicted, 4 unverified. A claim is a sentence somebody said, with the party that said it, the captured sources it comes from, and one of five words for how far it can be trusted. The words are defined here, once, and the build refuses a claim whose sources are not in the manifest.\n\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n## The flaws themselves\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n\n## How big it is\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n\n## Who found it, and how\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin , Calif on X PHP Foundation |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n\n## The leak\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n\n## When things happened\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src , read from a clone php-src |\n\n## Exploitation\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n\n## What the agencies advise\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n\n## What was taken offline\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n\nThe newsroom's own twelve claims, seeded from the BBC live page on the morning of 22 October, are in the vault as `claims/claude-newsroom-lead.json` and are superseded by the rows above, which trace each of them to primary sources. The raw rows are in data/claims.json."
    },
    {
     "v": 3,
     "hash": "5053afe45bb2",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Every claim, with its status and sources\n\n70 claims about php2shell, each with who makes it, a status (confirmed, reported, disputed, contradicted or unverified) and the captured sources behind it.\n\n# Every claim, and who makes it\n\nIn plain English Every statement made about the story, who made it, and how far it can be trusted, with links to the evidence.\n\n70 claims: 22 confirmed, 33 reported, 8 disputed, 3 contradicted, 4 unverified. A claim is a sentence somebody said, with the party that said it, the captured sources it comes from, and one of five words for how far it can be trusted. The words are defined here, once, and the build refuses a claim whose sources are not in the manifest.\n\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n## The flaws themselves\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n\n## How big it is\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n\n## Who found it, and how\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin , Calif on X PHP Foundation |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n\n## The leak\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n\n## When things happened\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src , read from a clone php-src |\n\n## Exploitation\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n\n## What the agencies advise\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n\n## What was taken offline\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n\nThe newsroom's own twelve claims, seeded from the BBC live page on the morning of 22 October, are in the vault as `claims/claude-newsroom-lead.json` and are superseded by the rows above, which trace each of them to primary sources. The raw rows are in data/claims.json."
    },
    {
     "v": 4,
     "hash": "236496738b59",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Every claim, with its status and sources\n\n70 claims about php2shell, each with who makes it, a status (confirmed, reported, disputed, contradicted or unverified) and the captured sources behind it.\n\n# Every claim, and who makes it\n\nIn plain English Every statement made about the story, who made it, and how far it can be trusted, with links to the evidence.\n\n70 claims: 22 confirmed, 33 reported, 8 disputed, 3 contradicted, 4 unverified. A claim is a sentence somebody said, with the party that said it, the captured sources it comes from, and one of five words for how far it can be trusted. The words are defined here, once, and the build refuses a claim whose sources are not in the manifest.\n\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n## The flaws themselves\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n\n## How big it is\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n\n## Who found it, and how\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n\n## The leak\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n\n## When things happened\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src, read from a clone php-src |\n\n## Exploitation\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n\n## What the agencies advise\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n\n## What was taken offline\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n\nThe newsroom's own twelve claims, seeded from the BBC live page on the morning of 22 October, are in the vault as `claims/claude-newsroom-lead.json` and are superseded by the rows above, which trace each of them to primary sources. The raw rows are in data/claims.json."
    },
    {
     "v": 5,
     "hash": "135221912415",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Every claim, with its status and sources\n\n70 claims about php2shell, each with who makes it, a status (confirmed, reported, disputed, contradicted or unverified) and the captured sources behind it.\n\n# Every claim, and who makes it\n\nIn plain English Every statement made about the story, who made it, and how far it can be trusted, with links to the evidence.\n\n70 claims: 22 confirmed, 33 reported, 8 disputed, 3 contradicted, 4 unverified. A claim is a sentence somebody said, with the party that said it, the captured sources it comes from, and one of five words for how far it can be trusted. The words are defined here, once, and the build refuses a claim whose sources are not in the manifest.\n\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n## The flaws themselves\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n\n## How big it is\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n\n## Who found it, and how\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | **A3** Echoed●●●○○○ opinion measures differently | 3/4 | BBC News OpenAI on X Calif Wiz |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | **A3** Echoed●●●○○○ opinion measures differently status overstated | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | **A2** Reported●●○○○○ | 2/2 | Wiz PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | **A6** Established●●●●●● | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | **A2** Reported●●○○○○ disputed status overstated | 2/2 | PHP Foundation Calif |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | **A2** Reported●●○○○○ opinion disputed | 1/2 | OpenAI on X THN |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | **A2** Reported●●○○○○ opinion measures differently | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | **A6** Established●●●●●● | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | **A2** Reported●●○○○○ | 0/1 | The Register |\n\n## The leak\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | **A2** Reported●●○○○○ disputed | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | **A4** Corroborated●●●●○○ | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | **A3** Echoed●●●○○○ | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | **A2** Reported●●○○○○ | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | **A2** Reported●●○○○○ opinion disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | **A4** Corroborated●●●●○○ measures differently status overstated | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n\n## When things happened\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | refuted measures differently | 2/3 | BBC News php.net php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | **A2** Reported●●○○○○ disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | **A2** Reported●●○○○○ disputed | 3/3 | PHP Foundation oss-security php.net |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | **A6** Established●●●●●● | 2/2 | php/php-src, read from a clone php-src |\n\n## Exploitation\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n\n## What the agencies advise\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n\n## What was taken offline\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | **A4** Corroborated●●●●○○ status overstated | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n\nThe newsroom's own twelve claims, seeded from the BBC live page on the morning of 22 October, are in the vault as `claims/claude-newsroom-lead.json` and are superseded by the rows above, which trace each of them to primary sources. The raw rows are in data/claims.json."
    },
    {
     "v": 6,
     "hash": "a8d9718c0a80",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Every claim, with its status and sources\n\n70 claims about php2shell, each with who makes it, a status (confirmed, reported, disputed, contradicted or unverified) and the captured sources behind it.\n\n# Every claim, and who makes it\n\nIn plain English Every statement made about the story, who made it, and how far it can be trusted, with links to the evidence.\n\n70 claims: 21 confirmed, 34 reported, 8 disputed, 3 contradicted, 4 unverified. A claim is a sentence somebody said, with the party that said it, the captured sources it comes from, and one of five words for how far it can be trusted. The words are defined here, once, and the build refuses a claim whose sources are not in the manifest.\n\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n## The flaws themselves\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n\n## How big it is\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n\n## Who found it, and how\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | **A3** Echoed●●●○○○ opinion measures differently | 3/4 | BBC News OpenAI on X Calif Wiz |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | **A3** Echoed●●●○○○ opinion measures differently status overstated | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | **A2** Reported●●○○○○ | 2/2 | Wiz PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | **A6** Established●●●●●● | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | **A2** Reported●●○○○○ disputed status overstated | 2/2 | PHP Foundation Calif |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | **A2** Reported●●○○○○ opinion disputed | 1/2 | OpenAI on X THN |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | **A2** Reported●●○○○○ opinion measures differently | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | **A6** Established●●●●●● | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | **A2** Reported●●○○○○ | 0/1 | The Register |\n\n## The leak\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | **A2** Reported●●○○○○ disputed | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | **A4** Corroborated●●●●○○ | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | **A3** Echoed●●●○○○ | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | **A2** Reported●●○○○○ | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | **A2** Reported●●○○○○ opinion disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | **A4** Corroborated●●●●○○ measures differently status overstated | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n\n## When things happened\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | refuted measures differently | 2/3 | BBC News php.net php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | **A2** Reported●●○○○○ disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | **A2** Reported●●○○○○ disputed | 3/3 | PHP Foundation oss-security php.net |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | **A6** Established●●●●●● | 2/2 | php/php-src, read from a clone php-src |\n\n## Exploitation\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n\n## What the agencies advise\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n\n## What was taken offline\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n\nThe newsroom's own twelve claims, seeded from the BBC live page on the morning of 22 October, are in the vault as `claims/claude-newsroom-lead.json` and are superseded by the rows above, which trace each of them to primary sources. The raw rows are in data/claims.json."
    }
   ]
  },
  "page-numbers": {
   "title": "The numbers",
   "kind": "page",
   "path": "numbers/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "c9fcdff71629",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The numbers: 70%, 30 million, 2.6 million, 6,000, 674\n\nEvery 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.\n\n# The numbers, and what each one measures\n\nThe editor's starting point for this site was a figure that did not add up: *70% of the internet*. It turns out to be a headline's restatement of a share-of-websites statistic that nobody on this beat sources, sitting next to a host count a thousand times smaller and a national count a thousand times smaller again. None of them is wrong on its own terms. The table says what each one counts.\n\n| Figure | What it measures | Who said it | Status | Note | Sources |\n|---|---|---|---|---|---|\n| 70% the Internet | Not stated. The headline is a restatement of the body's figure for websites. | Wiz (headline and X post) | unverified | The BBC says it could not independently verify this figure. The body of the same Wiz post says PHP 'powers 70% of all websites in the world' and cites no measurement. | Wiz Wiz on X |\n| almost 70% websites | The share of websites whose server-side language is PHP, as commonly published by web-technology surveys. Neither page names the survey. | Cloudflare; OpenAI ('an estimated 70% of websites') | reported | A share of websites is not a share of the Internet, and a site that uses PHP is not a site that is reachable, unpatched and exploitable. | Cloudflare OpenAI on X |\n| about 30 million websites | Not stated. | Alan Woodward, Surrey Centre for Cyber Security, on the BBC | reported | Second-hand through the BBC. No basis given. | BBC News |\n| 2,608,039 internet-facing hosts running PHP | Hosts observed on the internet that expose PHP, as counted by one scanning vendor. | VulnCheck, via The Hacker News | reported | A host count, far smaller than any websites figure, because one host serves many sites and most sites are behind hosts that do not expose PHP directly. | THN |\n| about 6,000 potentially affected resources in Latvia, a few hundred in the public sector | Resources identified by the national CERT as potentially affected, in one country. | CERT.LV | reported | The one national-scale count from a primary source, and the only one that says 'potentially'. | CERT.LV |\n| 674 software entries in the NCSC-NL php2shell inventory | Rows in the inventory: 206 marked Vulnerable, 46 Fix, 418 Investigation, 3 Not vulnerable, 1 without a status. | NCSC-NL, counted from the file at commit cca173c64ec5 | confirmed | NCSC-NL calls the entries investigation leads until a vendor backs them. Counted by this site's export script, not copied from a page. | NCSC-NL NCSC-NL |\n| 9.2 CVSS v4.0, each CVE | CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N | PHP Group as CNA; GitHub advisories; CERT-EU; ACN | confirmed | The 10.0 that circulated on 20 October is wrong, per the PHP Foundation; a PHP security team member traces it to a social post relayed by a vendor and a news site. | CVE record CVE record PHP CERT-EU ACN / CSIRT Italia |\n| 10.1 million views of the NSA Cyber post, at capture | The view counter X displayed when the post was captured. | X, as displayed at 2026-10-22T08:09Z | confirmed | A capture-time number; it will be higher now. | NSA Cyber on X |\n| 4 days before disclosure, an exploit attempt hit an Amazon honeypot | 17 October 2026, MadPot honeypot, one attempt from an anonymisation network. | CJ Moses, Amazon, via The Hacker News | reported | Amazon's own post has not been found; the quote is as The Hacker News printed it. | THN |\n| about 9 hours before disclosure, Cloudflare's WAF rules went live for all customers | 21 October 2026 03:02 UTC against the 14:00 UTC release. | Cloudflare | confirmed | Primary party. No attack volumes are in the post. | Cloudflare |\n| more than 6 hours before the coordinated release, Chainguard published built images with the fix | 21 October 2026 07:41 UTC. | The PHP Foundation | reported | Chainguard reportedly does not dispute the time but denies leaking; that article is blocked from this environment. | PHP Foundation |\n\n## Why they differ by four orders of magnitude\n\n- **A share of websites that use PHP** (about 70%) is the population a survey counts by looking at response headers and page markup across a sample of the web. It includes every site on a shared host that patched hours ago, every site behind a CDN, and every site that has not been touched since 2019. It is an upper bound on exposure.\n\n- **Internet-facing hosts that expose PHP** (2.6 million, one scanner's count) is a count of machines, not sites. One host serves many sites; most sites sit behind hosts that do not announce PHP at all. It is a lower bound on the machines an attacker could reach directly.\n\n- **Websites that could be affected** (30 million) has no stated basis. It may be a fraction of a websites total; it may be a guess.\n\n- **Resources potentially affected in one country** (about 6,000 in Latvia) is the only figure from a body that could inventory what it counts. Scaled naively by population it would put the EU in the low millions, which is a different number from any of the above and is not offered here as one.\n\n- **Products in an inventory** (674) counts software, not deployments: one row is WordPress, another is a Linux distribution's package.\n\nThe number a reader actually wants, how many systems were exploitable at a given hour and how many were exploited, does not exist in any captured source. What exists is a set of signals, on the exploitation page."
    },
    {
     "v": 2,
     "hash": "f46e6318138c",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The numbers: 70%, 30 million, 2.6 million, 6,000, 674\n\nEvery 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.\n\n# The numbers, and what each one measures\n\nThe editor's starting point for this site was a figure that did not add up: *70% of the internet*. It turns out to be a headline's restatement of a share-of-websites statistic that nobody on this beat sources, sitting next to a host count a thousand times smaller and a national count a thousand times smaller again. None of them is wrong on its own terms. The table says what each one counts.\n\n| Figure | What it measures | Who said it | Status | Note | Sources |\n|---|---|---|---|---|---|\n| 70% the Internet | Not stated. The headline is a restatement of the body's figure for websites. | Wiz (headline and X post) | unverified | The BBC says it could not independently verify this figure. The body of the same Wiz post says PHP 'powers 70% of all websites in the world' and cites no measurement. | Wiz Wiz on X |\n| almost 70% websites | The share of websites whose server-side language is PHP, as commonly published by web-technology surveys. Neither page names the survey. | Cloudflare; OpenAI ('an estimated 70% of websites') | reported | A share of websites is not a share of the Internet, and a site that uses PHP is not a site that is reachable, unpatched and exploitable. | Cloudflare OpenAI on X |\n| about 30 million websites | Not stated. | Alan Woodward, Surrey Centre for Cyber Security, on the BBC | reported | Second-hand through the BBC. No basis given. | BBC News |\n| 2,608,039 internet-facing hosts running PHP | Hosts observed on the internet that expose PHP, as counted by one scanning vendor. | VulnCheck, via The Hacker News | reported | A host count, far smaller than any websites figure, because one host serves many sites and most sites are behind hosts that do not expose PHP directly. | THN |\n| about 6,000 potentially affected resources in Latvia, a few hundred in the public sector | Resources identified by the national CERT as potentially affected, in one country. | CERT.LV | reported | The one national-scale count from a primary source, and the only one that says 'potentially'. | CERT.LV |\n| 674 software entries in the NCSC-NL php2shell inventory | Rows in the inventory: 206 marked Vulnerable, 46 Fix, 418 Investigation, 3 Not vulnerable, 1 without a status. | NCSC-NL, counted from the file at commit cca173c64ec5 | confirmed | NCSC-NL calls the entries investigation leads until a vendor backs them. Counted by this site's export script, not copied from a page. | NCSC-NL NCSC-NL |\n| 9.2 CVSS v4.0, each CVE | CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N | PHP Group as CNA; GitHub advisories; CERT-EU; ACN | confirmed | The 10.0 that circulated on 20 October is wrong, per the PHP Foundation; a PHP security team member traces it to a social post relayed by a vendor and a news site. | CVE record CVE record PHP CERT-EU ACN / CSIRT Italia |\n| 10.1 million views of the NSA Cyber post, at capture | The view counter X displayed when the post was captured. | X, as displayed at 2026-10-22T08:09Z | confirmed | A capture-time number; it will be higher now. | NSA Cyber on X |\n| 4 days before disclosure, an exploit attempt hit an Amazon honeypot | 17 October 2026, MadPot honeypot, one attempt from an anonymisation network. | CJ Moses, Amazon, via The Hacker News | reported | Amazon's own post has not been found; the quote is as The Hacker News printed it. | THN |\n| about 9 hours before disclosure, Cloudflare's WAF rules went live for all customers | 21 October 2026 03:02 UTC against the 14:00 UTC release. | Cloudflare | confirmed | Primary party. No attack volumes are in the post. | Cloudflare |\n| more than 6 hours before the coordinated release, Chainguard published built images with the fix | 21 October 2026 07:41 UTC. | The PHP Foundation | reported | Chainguard reportedly does not dispute the time but denies leaking; that article is blocked from this environment. | PHP Foundation |\n| 1.57 million internet-facing hosts with an identifiable PHP version that were unpatched on 21 October, of 2.58 million seen | Hosts whose HTTP response announces a PHP version below the fixed one. Hosts that hide the version (a million of them) are not counted either way. | Censys, via SecurityWeek | reported | Censys's own post was not found; nearly 3 million hosts by 22 October per the same report. | SecurityWeek |\n| millions exploit attempts seen across Cloudflare's network by 22 October 01:25 UTC | Requests matching Cloudflare's rules, across all customers. Not compromises, not unique attackers, not unique targets. | Matthew Prince, Cloudflare | reported | Thousands in the ten hours before the announcement. | Matthew Prince , Cloudflare CEO on |\n| 22.6 million internet-facing systems that 'could be vulnerable' | Not stated. | Palo Alto Networks Unit 42, via Insurance Business | reported | Nine times Censys's host count; the method is not given. | Insurance Business |\n| 94% Weird Gloop's wiki page views still served during its 13-hour shutdown | Page views served from cache with no PHP or database running, as measured by the operator. | Weird Gloop | confirmed | The one number on this page that measures the cost of taking a system offline. | Weird Gloop |\n| 389 files changed by the fix commit, 10,689 lines added | git show --shortstat on commit 3584a98bd; 113 of the files are not tests. | php/php-src, counted by this site from a clone | confirmed | The 7.4 backport changes 17 files. | php/php-src , read from a clone |\n| 270 CVEs added to CISA's Known Exploited Vulnerabilities catalog in 2026 so far; 0 of them php2shell | Entries with dateAdded in 2026 in catalog version 2026.10.21. | CISA KEV, counted by this site | confirmed | Three PHP core CVEs are in the catalog from earlier years. | CISA |\n\n## Why they differ by four orders of magnitude\n\n- **A share of websites that use PHP** (about 70%) is the population a survey counts by looking at response headers and page markup across a sample of the web. It includes every site on a shared host that patched hours ago, every site behind a CDN, and every site that has not been touched since 2019. It is an upper bound on exposure.\n\n- **Internet-facing hosts that expose PHP** (2.6 million, one scanner's count) is a count of machines, not sites. One host serves many sites; most sites sit behind hosts that do not announce PHP at all. It is a lower bound on the machines an attacker could reach directly.\n\n- **Websites that could be affected** (30 million) has no stated basis. It may be a fraction of a websites total; it may be a guess.\n\n- **Resources potentially affected in one country** (about 6,000 in Latvia) is the only figure from a body that could inventory what it counts. Scaled naively by population it would put the EU in the low millions, which is a different number from any of the above and is not offered here as one.\n\n- **Products in an inventory** (674) counts software, not deployments: one row is WordPress, another is a Linux distribution's package.\n\nThe number a reader actually wants, how many systems were exploitable at a given hour and how many were exploited, does not exist in any captured source. What exists is a set of signals, on the exploitation page."
    },
    {
     "v": 3,
     "hash": "0eac2101b151",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The numbers: 70%, 30 million, 2.6 million, 6,000, 674\n\nEvery 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.\n\n# The numbers, and what each one measures\n\nIn plain English The big numbers in the headlines measure different things. 70% is a share of websites, not of the Internet; 2.6 million is a count of servers.\n\nThe editor's starting point for this site was a figure that did not add up: *70% of the internet*. It turns out to be a headline's restatement of a share-of-websites statistic that nobody on this beat sources, sitting next to a host count a thousand times smaller and a national count a thousand times smaller again. None of them is wrong on its own terms. The table says what each one counts.\n\n| Figure | What it measures | Who said it | Status | Note | Sources |\n|---|---|---|---|---|---|\n| 70% the Internet | Not stated. The headline is a restatement of the body's figure for websites. | Wiz (headline and X post) | unverified | The BBC says it could not independently verify this figure. The body of the same Wiz post says PHP 'powers 70% of all websites in the world' and cites no measurement. | Wiz Wiz on X |\n| almost 70% websites | The share of websites whose server-side language is PHP, as commonly published by web-technology surveys. Neither page names the survey. | Cloudflare; OpenAI ('an estimated 70% of websites') | reported | A share of websites is not a share of the Internet, and a site that uses PHP is not a site that is reachable, unpatched and exploitable. | Cloudflare OpenAI on X |\n| about 30 million websites | Not stated. | Alan Woodward, Surrey Centre for Cyber Security, on the BBC | reported | Second-hand through the BBC. No basis given. | BBC News |\n| 2,608,039 internet-facing hosts running PHP | Hosts observed on the internet that expose PHP, as counted by one scanning vendor. | VulnCheck, via The Hacker News | reported | A host count, far smaller than any websites figure, because one host serves many sites and most sites are behind hosts that do not expose PHP directly. | THN |\n| about 6,000 potentially affected resources in Latvia, a few hundred in the public sector | Resources identified by the national CERT as potentially affected, in one country. | CERT.LV | reported | The one national-scale count from a primary source, and the only one that says 'potentially'. | CERT.LV |\n| 674 software entries in the NCSC-NL php2shell inventory | Rows in the inventory: 206 marked Vulnerable, 46 Fix, 418 Investigation, 3 Not vulnerable, 1 without a status. | NCSC-NL, counted from the file at commit cca173c64ec5 | confirmed | NCSC-NL calls the entries investigation leads until a vendor backs them. Counted by this site's export script, not copied from a page. | NCSC-NL NCSC-NL |\n| 9.2 CVSS v4.0, each CVE | CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N | PHP Group as CNA; GitHub advisories; CERT-EU; ACN | confirmed | The 10.0 that circulated on 20 October is wrong, per the PHP Foundation; a PHP security team member traces it to a social post relayed by a vendor and a news site. | CVE record CVE record PHP CERT-EU ACN / CSIRT Italia |\n| 10.1 million views of the NSA Cyber post, at capture | The view counter X displayed when the post was captured. | X, as displayed at 2026-10-22T08:09Z | confirmed | A capture-time number; it will be higher now. | NSA Cyber on X |\n| 4 days before disclosure, an exploit attempt hit an Amazon honeypot | 17 October 2026, MadPot honeypot, one attempt from an anonymisation network. | CJ Moses, Amazon, via The Hacker News | reported | Amazon's own post has not been found; the quote is as The Hacker News printed it. | THN |\n| about 9 hours before disclosure, Cloudflare's WAF rules went live for all customers | 21 October 2026 03:02 UTC against the 14:00 UTC release. | Cloudflare | confirmed | Primary party. No attack volumes are in the post. | Cloudflare |\n| more than 6 hours before the coordinated release, Chainguard published built images with the fix | 21 October 2026 07:41 UTC. | The PHP Foundation | reported | Chainguard reportedly does not dispute the time but denies leaking; that article is blocked from this environment. | PHP Foundation |\n| 1.57 million internet-facing hosts with an identifiable PHP version that were unpatched on 21 October, of 2.58 million seen | Hosts whose HTTP response announces a PHP version below the fixed one. Hosts that hide the version (a million of them) are not counted either way. | Censys, via SecurityWeek | reported | Censys's own post was not found; nearly 3 million hosts by 22 October per the same report. | SecurityWeek |\n| millions exploit attempts seen across Cloudflare's network by 22 October 01:25 UTC | Requests matching Cloudflare's rules, across all customers. Not compromises, not unique attackers, not unique targets. | Matthew Prince, Cloudflare | reported | Thousands in the ten hours before the announcement. | Matthew Prince , Cloudflare CEO on |\n| 22.6 million internet-facing systems that 'could be vulnerable' | Not stated. | Palo Alto Networks Unit 42, via Insurance Business | reported | Nine times Censys's host count; the method is not given. | Insurance Business |\n| 94% Weird Gloop's wiki page views still served during its 13-hour shutdown | Page views served from cache with no PHP or database running, as measured by the operator. | Weird Gloop | confirmed | The one number on this page that measures the cost of taking a system offline. | Weird Gloop |\n| 389 files changed by the fix commit, 10,689 lines added | git show --shortstat on commit 3584a98bd; 113 of the files are not tests. | php/php-src, counted by this site from a clone | confirmed | The 7.4 backport changes 17 files. | php/php-src , read from a clone |\n| 270 CVEs added to CISA's Known Exploited Vulnerabilities catalog in 2026 so far; 0 of them php2shell | Entries with dateAdded in 2026 in catalog version 2026.10.21. | CISA KEV, counted by this site | confirmed | Three PHP core CVEs are in the catalog from earlier years. | CISA |\n\n## Why they differ by four orders of magnitude\n\n- **A share of websites that use PHP** (about 70%) is the population a survey counts by looking at response headers and page markup across a sample of the web. It includes every site on a shared host that patched hours ago, every site behind a CDN, and every site that has not been touched since 2019. It is an upper bound on exposure.\n\n- **Internet-facing hosts that expose PHP** (2.6 million, one scanner's count) is a count of machines, not sites. One host serves many sites; most sites sit behind hosts that do not announce PHP at all. It is a lower bound on the machines an attacker could reach directly.\n\n- **Websites that could be affected** (30 million) has no stated basis. It may be a fraction of a websites total; it may be a guess.\n\n- **Resources potentially affected in one country** (about 6,000 in Latvia) is the only figure from a body that could inventory what it counts. Scaled naively by population it would put the EU in the low millions, which is a different number from any of the above and is not offered here as one.\n\n- **Products in an inventory** (674) counts software, not deployments: one row is WordPress, another is a Linux distribution's package.\n\nThe number a reader actually wants, how many systems were exploitable at a given hour and how many were exploited, does not exist in any captured source. What exists is a set of signals, on the exploitation page."
    },
    {
     "v": 4,
     "hash": "ae1c03176dc6",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The numbers: 70%, 30 million, 2.6 million, 6,000, 674\n\nEvery 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.\n\n# The numbers, and what each one measures\n\nIn plain English The big numbers in the headlines measure different things. 70% is a share of websites, not of the Internet; 2.6 million is a count of servers.\n\nThe editor's starting point for this site was a figure that did not add up: *70% of the internet*. It turns out to be a headline's restatement of a share-of-websites statistic that nobody on this beat sources, sitting next to a host count a thousand times smaller and a national count a thousand times smaller again. None of them is wrong on its own terms. The table says what each one counts.\n\n| Figure | What it measures | Who said it | Status | Note | Sources |\n|---|---|---|---|---|---|\n| 70% the Internet | Not stated. The headline is a restatement of the body's figure for websites. | Wiz (headline and X post) | unverified | The BBC says it could not independently verify this figure. The body of the same Wiz post says PHP 'powers 70% of all websites in the world' and cites no measurement. | Wiz Wiz on X |\n| almost 70% websites | The share of websites whose server-side language is PHP, as commonly published by web-technology surveys. Neither page names the survey. | Cloudflare; OpenAI ('an estimated 70% of websites') | reported | A share of websites is not a share of the Internet, and a site that uses PHP is not a site that is reachable, unpatched and exploitable. | Cloudflare OpenAI on X |\n| about 30 million websites | Not stated. | Alan Woodward, Surrey Centre for Cyber Security, on the BBC | reported | Second-hand through the BBC. No basis given. | BBC News |\n| 2,608,039 internet-facing hosts running PHP | Hosts observed on the internet that expose PHP, as counted by one scanning vendor. | VulnCheck, via The Hacker News | reported | A host count, far smaller than any websites figure, because one host serves many sites and most sites are behind hosts that do not expose PHP directly. | THN |\n| about 6,000 potentially affected resources in Latvia, a few hundred in the public sector | Resources identified by the national CERT as potentially affected, in one country. | CERT.LV | reported | The one national-scale count from a primary source, and the only one that says 'potentially'. | CERT.LV |\n| 674 software entries in the NCSC-NL php2shell inventory | Rows in the inventory: 206 marked Vulnerable, 46 Fix, 418 Investigation, 3 Not vulnerable, 1 without a status. | NCSC-NL, counted from the file at commit cca173c64ec5 | confirmed | NCSC-NL calls the entries investigation leads until a vendor backs them. Counted by this site's export script, not copied from a page. | NCSC-NL NCSC-NL |\n| 9.2 CVSS v4.0, each CVE | CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N | PHP Group as CNA; GitHub advisories; CERT-EU; ACN | confirmed | The 10.0 that circulated on 20 October is wrong, per the PHP Foundation; a PHP security team member traces it to a social post relayed by a vendor and a news site. | CVE record CVE record PHP CERT-EU ACN / CSIRT Italia |\n| 10.1 million views of the NSA Cyber post, at capture | The view counter X displayed when the post was captured. | X, as displayed at 2026-10-22T08:09Z | confirmed | A capture-time number; it will be higher now. | NSA Cyber on X |\n| 4 days before disclosure, an exploit attempt hit an Amazon honeypot | 17 October 2026, MadPot honeypot, one attempt from an anonymisation network. | CJ Moses, Amazon, via The Hacker News | reported | Amazon's own post has not been found; the quote is as The Hacker News printed it. | THN |\n| about 9 hours before disclosure, Cloudflare's WAF rules went live for all customers | 21 October 2026 03:02 UTC against the 14:00 UTC release. | Cloudflare | confirmed | Primary party. No attack volumes are in the post. | Cloudflare |\n| more than 6 hours before the coordinated release, Chainguard published built images with the fix | 21 October 2026 07:41 UTC. | The PHP Foundation | reported | Chainguard reportedly does not dispute the time but denies leaking; that article is blocked from this environment. | PHP Foundation |\n| 1.57 million internet-facing hosts with an identifiable PHP version that were unpatched on 21 October, of 2.58 million seen | Hosts whose HTTP response announces a PHP version below the fixed one. Hosts that hide the version (a million of them) are not counted either way. | Censys, via SecurityWeek | reported | Censys's own post was not found; nearly 3 million hosts by 22 October per the same report. | SecurityWeek |\n| millions exploit attempts seen across Cloudflare's network by 22 October 01:25 UTC | Requests matching Cloudflare's rules, across all customers. Not compromises, not unique attackers, not unique targets. | Matthew Prince, Cloudflare | reported | Thousands in the ten hours before the announcement. | Matthew Prince, Cloudflare CEO on… |\n| 22.6 million internet-facing systems that 'could be vulnerable' | Not stated. | Palo Alto Networks Unit 42, via Insurance Business | reported | Nine times Censys's host count; the method is not given. | Insurance Business |\n| 94% Weird Gloop's wiki page views still served during its 13-hour shutdown | Page views served from cache with no PHP or database running, as measured by the operator. | Weird Gloop | confirmed | The one number on this page that measures the cost of taking a system offline. | Weird Gloop |\n| 389 files changed by the fix commit, 10,689 lines added | git show --shortstat on commit 3584a98bd; 113 of the files are not tests. | php/php-src, counted by this site from a clone | confirmed | The 7.4 backport changes 17 files. | php/php-src, read from a clone |\n| 270 CVEs added to CISA's Known Exploited Vulnerabilities catalog in 2026 so far; 0 of them php2shell | Entries with dateAdded in 2026 in catalog version 2026.10.21. | CISA KEV, counted by this site | confirmed | Three PHP core CVEs are in the catalog from earlier years. | CISA |\n\n## Why they differ by four orders of magnitude\n\n- **A share of websites that use PHP** (about 70%) is the population a survey counts by looking at response headers and page markup across a sample of the web. It includes every site on a shared host that patched hours ago, every site behind a CDN, and every site that has not been touched since 2019. It is an upper bound on exposure.\n\n- **Internet-facing hosts that expose PHP** (2.6 million, one scanner's count) is a count of machines, not sites. One host serves many sites; most sites sit behind hosts that do not announce PHP at all. It is a lower bound on the machines an attacker could reach directly.\n\n- **Websites that could be affected** (30 million) has no stated basis. It may be a fraction of a websites total; it may be a guess.\n\n- **Resources potentially affected in one country** (about 6,000 in Latvia) is the only figure from a body that could inventory what it counts. Scaled naively by population it would put the EU in the low millions, which is a different number from any of the above and is not offered here as one.\n\n- **Products in an inventory** (674) counts software, not deployments: one row is WordPress, another is a Linux distribution's package.\n\nThe number a reader actually wants, how many systems were exploitable at a given hour and how many were exploited, does not exist in any captured source. What exists is a set of signals, on the exploitation page."
    }
   ]
  },
  "page-agencies": {
   "title": "The agencies",
   "kind": "page",
   "path": "agencies/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "bd72737b91c0",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# What sixteen agencies actually advise\n\nThe 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.\n\n# The agencies, side by side\n\n16 national and supranational bodies, each read from its own page. The question that divides them is not whether to patch (all say patch) but what to do with a system that cannot be patched now. Of 16: 6 say *none*, 2 say *yes*, 2 say *isolate*, 2 say *unknown*, 1 say *after mitigations*, 1 say *isolate first*, 1 say *consider*, 1 say *restrict from abroad*. Two could not be read because their sites block automated browsers; the block is recorded.\n\nThe BBC's morning framing, *the UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline*, holds for the NSA and CISA, is a simplification of the NCSC's fourth of six steps, and is not supported by the Australian page at all. The sentence the BBC quotes from the NCSC is not on the NCSC page as captured; its opening matches the Canadian text.\n\n| Agency | Published | Offline? | Exploitation | Note | Sources |\n|---|---|---|---|---|---|\n| **NSA Cybersecurity** US | 2026-10-21T13:45:58Z (X post); press release dated 21 Oct | yesIf an immediate update is not feasible, it is recommend[ed] that organizations take the system offline until it can be fully mitigated. | not stated | The X post says 'be prepared for an update', so it reads as written before or with the patch. The press release names no CVE IDs and calls the pair 'PHP2Shell'. | NSA Cyber on X NSA NSA Cyber on X |\n| **CISA** US | 2026-10-21 | yesOrganizations that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated. | none observed at publication; neither CVE in KEV as of catalog 2026.10.21 | 'A web application firewall may provide some protection until systems are updated or patched.' The most absolute offline advice, and it covers end-of-life versions explicitly. | CISA CISA CISA |\n| **NCSC** UK | 2026-10-21 (page modified 2026-10-22T07:30:02Z) | after mitigationsIf you are unable to apply the temporary mitigations, or applying them would take too long, you should consider taking the system offline until it can be fully mitigated. | not stated | Offline is the fourth of six priority actions, after inventory, update and the PHP Foundation's temporary mitigations. The sentence the BBC quotes ('Where immediate remediation is not feasible...') is not on the page as captured; the page changed on 22 October. | NCSC UK |\n| **CERT-EU** EU institutions | 2026-10-21 15:20:18 (timezone not stated) | isolateWhere that is not feasible, organisations should consider isolating internet-facing applications from public networks until a fix is applied and verified. | PoCs circulating; 'raises the likelihood that attackers are already exploiting' | States the fixes were released at 13:30 UTC. Lists the PHP temporary mitigations in full. | CERT-EU |\n| **ENISA CSIRTs Network** EU | 2026-10-21 | noneThe Mitigation field still holds template placeholder text. | not stated | An index of about 30 national advisories, work in progress: a truncated CVE in the heading and a Dutch 'en'. | ENISA CNW |\n| **CERT-FR (ANSSI)** FR | 2026-10-21 | isolate firstLe CERT-FR recommande d'isoler les équipements affectés puis de procéder à la migration vers une version maintenue... | not stated | The closest to 'isolate first, then patch'. Lists all 5.x, 6.x, 7.x, 8.0 and 8.1 as affected. Workarounds: session.upload_progress off; block multipart Content-Type at a WAF. | CERT-FR |\n| **CCCS** CA | 2026-10-21 | isolateWhere immediate remediation is not feasible, organisations should consider isolating internet-facing applications from public networks until a fix can be applied. | PoC available, no active exploitation identified | The opening of this sentence is the one the BBC attributes to the UK NCSC. The wording is shared across Five Eyes and CERT-EU text. | CCCS CCCS |\n| **ASD's ACSC** AU | 2026-10-21, reviewed 2026-10-22 | noneIdentify PHP, review php.net, apply updates and mitigations, monitor. | not aware of successful active exploitation within Australia | No take-offline or isolation advice. The BBC's 'Australian counterparts' framing is not supported by the page. Parts of the body are still pre-patch text. | ACSC ACSC |\n| **NCSC** NZ | 2026-10-21T20:15Z (09:15 NZDT, 22 Oct); updated 21:20Z | noneUpdate to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35; apply the remediation as soon as possible; investigate unauthorised access or compromise. | 'The NCSC is aware of reports of active exploitation.' | The only agency to say active exploitation is reported. It does not say whose reports. Time converted from NZDT by this site. | NCSC New Zealand NCSC New Zealand |\n| **NCSC-NL** NL | 2026-10-21T15:25Z (README last significant change) | noneIf immediate patching is not possible, follow PHP's temporary mitigations... PHP states that these measures are not complete fixes. | public PoC exists; no active abuse seen (portal banner) | Runs the public php2shell GitHub repository with the software inventory the UK NCSC cites, cPanel detection and mitigation scripts, and an SPDX/VEX source list. | NCSC-NL NCSC-NL NCSC-NL |\n| **ACN / CSIRT Italia** IT | 2026-10-21 | noneSi raccomanda di aggiornare i prodotti vulnerabili. | not stated | Update only. Lists the four fixed branches and no end-of-life branches. | ACN / CSIRT Italia |\n| **BACS (NCSC)** CH | 2026-10-21 (home-page teaser dated 20 Oct) | considerCheck, particularly for critical applications, whether a temporary disconnection from the internet or taking the system offline is necessary. | not stated | 'Even a web application firewall alone is not sufficient', which contrasts with CISA. Says containers may need to be rebuilt. | BACS Swiss BACS |\n| **CERT.LV** LV | 2026-10-21T15:25Z; updated 20:00Z (converted from EEST) | restrict from abroadSystems that cannot be updated must have internet access restricted, with no public availability until the risk is removed. | automated exploitation attempts seen, none successful | Latvia geo-blocked several state digital resources from abroad, possibly until 26 October. The unified state website platform was patched by 20:00Z; lsm.lv and 112.lv restored. Translations are this site's. | CERT.LV |\n| **JPCERT/CC** JP | 2026-10-22 | noneAfter sufficient testing, apply the fixed version promptly; investigate whether you have been compromised. | not stated; warns that one detection rule may miss attacks | Translations are this site's. | JPCERT/CC JPCERT/CC |\n| **CCN-CERT** ES | unknown | unknownNot read: HTTP 403 bot challenge to every fetch. | unknown | The title ('actualización inmediata') points to immediate-update advice. The block is recorded in the vault. | CCN-CERT |\n| **CNCS** PT | unknown | unknownNot read: HTTP 513 browser-verification challenge. | unknown | The block is recorded in the vault. | CNCS |\n\nEach agency's full text is in its capture; the sentences here are the ones the collectors copied verbatim into their notes. Translations from French, Italian, Latvian and Japanese are this site's and are marked as such in the notes."
    },
    {
     "v": 2,
     "hash": "4632fc415eb8",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# What sixteen agencies actually advise\n\nThe 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.\n\n# The agencies, side by side\n\nIn plain English What sixteen government cyber agencies told organisations to do. All say update; they disagree on whether to take systems offline.\n\n16 national and supranational bodies, each read from its own page. The question that divides them is not whether to patch (all say patch) but what to do with a system that cannot be patched now. Of 16: 6 say *none*, 2 say *yes*, 2 say *isolate*, 2 say *unknown*, 1 say *after mitigations*, 1 say *isolate first*, 1 say *consider*, 1 say *restrict from abroad*. Two could not be read because their sites block automated browsers; the block is recorded.\n\nThe BBC's morning framing, *the UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline*, holds for the NSA and CISA, is a simplification of the NCSC's fourth of six steps, and is not supported by the Australian page at all. The sentence the BBC quotes from the NCSC is not on the NCSC page as captured; its opening matches the Canadian text.\n\n| Agency | Published | Offline? | Exploitation | Note | Sources |\n|---|---|---|---|---|---|\n| **NSA Cybersecurity** US | 2026-10-21T13:45:58Z (X post); press release dated 21 Oct | yesIf an immediate update is not feasible, it is recommend[ed] that organizations take the system offline until it can be fully mitigated. | not stated | The X post says 'be prepared for an update', so it reads as written before or with the patch. The press release names no CVE IDs and calls the pair 'PHP2Shell'. | NSA Cyber on X NSA NSA Cyber on X |\n| **CISA** US | 2026-10-21 | yesOrganizations that cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated. | none observed at publication; neither CVE in KEV as of catalog 2026.10.21 | 'A web application firewall may provide some protection until systems are updated or patched.' The most absolute offline advice, and it covers end-of-life versions explicitly. | CISA CISA CISA |\n| **NCSC** UK | 2026-10-21 (page modified 2026-10-22T07:30:02Z) | after mitigationsIf you are unable to apply the temporary mitigations, or applying them would take too long, you should consider taking the system offline until it can be fully mitigated. | not stated | Offline is the fourth of six priority actions, after inventory, update and the PHP Foundation's temporary mitigations. The sentence the BBC quotes ('Where immediate remediation is not feasible...') is not on the page as captured; the page changed on 22 October. | NCSC UK |\n| **CERT-EU** EU institutions | 2026-10-21 15:20:18 (timezone not stated) | isolateWhere that is not feasible, organisations should consider isolating internet-facing applications from public networks until a fix is applied and verified. | PoCs circulating; 'raises the likelihood that attackers are already exploiting' | States the fixes were released at 13:30 UTC. Lists the PHP temporary mitigations in full. | CERT-EU |\n| **ENISA CSIRTs Network** EU | 2026-10-21 | noneThe Mitigation field still holds template placeholder text. | not stated | An index of about 30 national advisories, work in progress: a truncated CVE in the heading and a Dutch 'en'. | ENISA CNW |\n| **CERT-FR (ANSSI)** FR | 2026-10-21 | isolate firstLe CERT-FR recommande d'isoler les équipements affectés puis de procéder à la migration vers une version maintenue... | not stated | The closest to 'isolate first, then patch'. Lists all 5.x, 6.x, 7.x, 8.0 and 8.1 as affected. Workarounds: session.upload_progress off; block multipart Content-Type at a WAF. | CERT-FR |\n| **CCCS** CA | 2026-10-21 | isolateWhere immediate remediation is not feasible, organisations should consider isolating internet-facing applications from public networks until a fix can be applied. | PoC available, no active exploitation identified | The opening of this sentence is the one the BBC attributes to the UK NCSC. The wording is shared across Five Eyes and CERT-EU text. | CCCS CCCS |\n| **ASD's ACSC** AU | 2026-10-21, reviewed 2026-10-22 | noneIdentify PHP, review php.net, apply updates and mitigations, monitor. | not aware of successful active exploitation within Australia | No take-offline or isolation advice. The BBC's 'Australian counterparts' framing is not supported by the page. Parts of the body are still pre-patch text. | ACSC ACSC |\n| **NCSC** NZ | 2026-10-21T20:15Z (09:15 NZDT, 22 Oct); updated 21:20Z | noneUpdate to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35; apply the remediation as soon as possible; investigate unauthorised access or compromise. | 'The NCSC is aware of reports of active exploitation.' | The only agency to say active exploitation is reported. It does not say whose reports. Time converted from NZDT by this site. | NCSC New Zealand NCSC New Zealand |\n| **NCSC-NL** NL | 2026-10-21T15:25Z (README last significant change) | noneIf immediate patching is not possible, follow PHP's temporary mitigations... PHP states that these measures are not complete fixes. | public PoC exists; no active abuse seen (portal banner) | Runs the public php2shell GitHub repository with the software inventory the UK NCSC cites, cPanel detection and mitigation scripts, and an SPDX/VEX source list. | NCSC-NL NCSC-NL NCSC-NL |\n| **ACN / CSIRT Italia** IT | 2026-10-21 | noneSi raccomanda di aggiornare i prodotti vulnerabili. | not stated | Update only. Lists the four fixed branches and no end-of-life branches. | ACN / CSIRT Italia |\n| **BACS (NCSC)** CH | 2026-10-21 (home-page teaser dated 20 Oct) | considerCheck, particularly for critical applications, whether a temporary disconnection from the internet or taking the system offline is necessary. | not stated | 'Even a web application firewall alone is not sufficient', which contrasts with CISA. Says containers may need to be rebuilt. | BACS Swiss BACS |\n| **CERT.LV** LV | 2026-10-21T15:25Z; updated 20:00Z (converted from EEST) | restrict from abroadSystems that cannot be updated must have internet access restricted, with no public availability until the risk is removed. | automated exploitation attempts seen, none successful | Latvia geo-blocked several state digital resources from abroad, possibly until 26 October. The unified state website platform was patched by 20:00Z; lsm.lv and 112.lv restored. Translations are this site's. | CERT.LV |\n| **JPCERT/CC** JP | 2026-10-22 | noneAfter sufficient testing, apply the fixed version promptly; investigate whether you have been compromised. | not stated; warns that one detection rule may miss attacks | Translations are this site's. | JPCERT/CC JPCERT/CC |\n| **CCN-CERT** ES | unknown | unknownNot read: HTTP 403 bot challenge to every fetch. | unknown | The title ('actualización inmediata') points to immediate-update advice. The block is recorded in the vault. | CCN-CERT |\n| **CNCS** PT | unknown | unknownNot read: HTTP 513 browser-verification challenge. | unknown | The block is recorded in the vault. | CNCS |\n\nEach agency's full text is in its capture; the sentences here are the ones the collectors copied verbatim into their notes. Translations from French, Italian, Latvian and Japanese are this site's and are marked as such in the notes."
    }
   ]
  },
  "page-affected": {
   "title": "Affected systems",
   "kind": "page",
   "path": "affected/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "213c47aa11d2",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Affected systems: versions, deployments, applications, inventory\n\nWhich PHP versions and SAPIs php2shell affects, which applications had RCE demonstrated, and the NCSC-NL inventory of 674 products counted by status.\n\n# Affected systems\n\nThree layers: the PHP versions, the ways PHP is attached to a web server, and the software that runs on top. The first two come from the PHP project. The third comes from NCSC-NL's public inventory, which this site counts rather than quotes: 674 products at commit `cca173c64ec5`, of which 206 are marked vulnerable to CVE-2026-109618, 46 fixed, 418 under investigation and 3 not vulnerable.\n\n## Versions\n\n| Branch | Affected | Fixed | In the CVE record |\n|---|---|---|---|\n| 8.5 | = 5.4' (Wiz); 'toutes versions 5.x, 6.x, 7.x' (CERT-FR) | no release, no backport | **no** |\n\nThe CVE records carry defaultStatus 'unaffected' and list only 8.2 to 8.5, so an automated scanner reading the CVE will call 7.4 to 8.1 unaffected. The php.net advisory, the backport branches and a Greenbone reply on oss-security say otherwise. CVE record php.net php-src NCSC-NL Wiz on X CERT-FR oss-security\n\n## Deployments\n\n| SAPI | Risk | What the primary sources say | Sources |\n|---|---|---|---|\n| Apache mod_php | highest | Unauthenticated RCE demonstrated over HTTP with default input and memory limits, before any application code runs. | php.net PHP oss-security |\n| PHP-FPM | susceptible | For CVE-2026-109618 the GitHub advisory says no complete FPM exploit has been demonstrated; the PHP Foundation blog says RCE was confirmed on FPM through application-level paths. For CVE-2026-109619 the session path was validated against FPM. | PHP PHP Foundation PHP oss-security |\n| php-cgi | at risk | Listed by php.net among installations serving web requests. | php.net |\n| FrankenPHP | likely susceptible | 'likely susceptible' per the GitHub advisory. | PHP |\n| LiteSpeed (LSAPI) | likely, unvalidated | 'application-specific exploits being likely but unvalidated'. | PHP |\n| CLI, cron, queue workers | not web-serving | The advisory scopes the risk to installations serving web requests. A CLI process that parses untrusted input is not covered either way by the primary sources. | php.net |\n\n## Applications\n\nCalif reports confirmed pre-authentication RCE against WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS; Wiz confirmed Drupal (20 August) and WordPress (21 August). The flaw is below the application, so any PHP web application on an affected runtime is in scope. Calif Wiz\n\n## The NCSC-NL inventory, counted\n\n| Status | CVE-2026-109618 | CVE-2026-109619 |\n|---|---|---|\n| Vulnerable | 206 | 206 |\n| Fix | 46 | 46 |\n| Investigation | 418 | 418 |\n| Not vuln | 3 | 3 |\n| none | 1 | 1 |\n\nNCSC-NL generates the list from an SPDX 3 inventory with VEX statements and says an entry is an investigation lead until a vendor or upstream backs it. 46 products carry a fix for both CVEs; 206 are marked vulnerable to at least one. The suppliers with the most entries:\n\n| Supplier | Entries |\n|---|---|\n| The PHP Group | 86 |\n| Nette community | 15 |\n| Synology | 11 |\n| Canonical / Ubuntu package maintainers | 9 |\n| Sean Morris / php-wasm project | 7 |\n| Icinga GmbH | 6 |\n| Symfony | 6 |\n| Microsoft Azure Storage | 5 |\n| Plesk | 5 |\n| SURF | 5 |\n| TuxCare / CloudLinux | 5 |\n| WordPress Playground contributors | 5 |\n| Docker Official Images / docker-library PHP maintainers | 4 |\n| Google | 4 |\n| Laravel | 4 |\n\nThe full inventory, all 674 rows → The parsed file is in the vault as `software-list-cca173c64ec5.json`; the repository bundle and tree at the same commit are there too. NCSC-NL NCSC-NL"
    },
    {
     "v": 2,
     "hash": "6cf22d4469e2",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Affected systems: versions, deployments, applications, inventory\n\nWhich PHP versions and SAPIs php2shell affects, which applications had RCE demonstrated, and the NCSC-NL inventory of 674 products counted by status.\n\n# Affected systems\n\nIn plain English Which PHP versions, which server setups and which software products are affected.\n\nThree layers: the PHP versions, the ways PHP is attached to a web server, and the software that runs on top. The first two come from the PHP project. The third comes from NCSC-NL's public inventory, which this site counts rather than quotes: 674 products at commit `cca173c64ec5`, of which 206 are marked vulnerable to CVE-2026-109618, 46 fixed, 418 under investigation and 3 not vulnerable.\n\n## Versions\n\n| Branch | Affected | Fixed | In the CVE record |\n|---|---|---|---|\n| 8.5 | = 5.4' (Wiz); 'toutes versions 5.x, 6.x, 7.x' (CERT-FR) | no release, no backport | **no** |\n\nThe CVE records carry defaultStatus 'unaffected' and list only 8.2 to 8.5, so an automated scanner reading the CVE will call 7.4 to 8.1 unaffected. The php.net advisory, the backport branches and a Greenbone reply on oss-security say otherwise. CVE record php.net php-src NCSC-NL Wiz on X CERT-FR oss-security\n\n## Deployments\n\n| SAPI | Risk | What the primary sources say | Sources |\n|---|---|---|---|\n| Apache mod_php | highest | Unauthenticated RCE demonstrated over HTTP with default input and memory limits, before any application code runs. | php.net PHP oss-security |\n| PHP-FPM | susceptible | For CVE-2026-109618 the GitHub advisory says no complete FPM exploit has been demonstrated; the PHP Foundation blog says RCE was confirmed on FPM through application-level paths. For CVE-2026-109619 the session path was validated against FPM. | PHP PHP Foundation PHP oss-security |\n| php-cgi | at risk | Listed by php.net among installations serving web requests. | php.net |\n| FrankenPHP | likely susceptible | 'likely susceptible' per the GitHub advisory. | PHP |\n| LiteSpeed (LSAPI) | likely, unvalidated | 'application-specific exploits being likely but unvalidated'. | PHP |\n| CLI, cron, queue workers | not web-serving | The advisory scopes the risk to installations serving web requests. A CLI process that parses untrusted input is not covered either way by the primary sources. | php.net |\n\n## Applications\n\nCalif reports confirmed pre-authentication RCE against WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS; Wiz confirmed Drupal (20 August) and WordPress (21 August). The flaw is below the application, so any PHP web application on an affected runtime is in scope. Calif Wiz\n\n## The NCSC-NL inventory, counted\n\n| Status | CVE-2026-109618 | CVE-2026-109619 |\n|---|---|---|\n| Vulnerable | 206 | 206 |\n| Fix | 46 | 46 |\n| Investigation | 418 | 418 |\n| Not vuln | 3 | 3 |\n| none | 1 | 1 |\n\nNCSC-NL generates the list from an SPDX 3 inventory with VEX statements and says an entry is an investigation lead until a vendor or upstream backs it. 46 products carry a fix for both CVEs; 206 are marked vulnerable to at least one. The suppliers with the most entries:\n\n| Supplier | Entries |\n|---|---|\n| The PHP Group | 86 |\n| Nette community | 15 |\n| Synology | 11 |\n| Canonical / Ubuntu package maintainers | 9 |\n| Sean Morris / php-wasm project | 7 |\n| Icinga GmbH | 6 |\n| Symfony | 6 |\n| Microsoft Azure Storage | 5 |\n| Plesk | 5 |\n| SURF | 5 |\n| TuxCare / CloudLinux | 5 |\n| WordPress Playground contributors | 5 |\n| Docker Official Images / docker-library PHP maintainers | 4 |\n| Google | 4 |\n| Laravel | 4 |\n\nThe full inventory, all 674 rows → The parsed file is in the vault as `software-list-cca173c64ec5.json`; the repository bundle and tree at the same commit are there too. NCSC-NL NCSC-NL"
    }
   ]
  },
  "page-method": {
   "title": "The method",
   "kind": "page",
   "path": "method/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "6b3d26042919",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The method: capture, hash, claim, build, gate\n\nHow 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.\n\n# The method: capture, hash, claim, build, gate\n\nThis site is the newsroom's PHP flaws section taken to its conclusion: a site whose every sentence can be traced to bytes, rebuilt by a script from the vault, with no step a reader has to take on trust. It is also a test of the stack sgit.ai is building, and says so in its footer.\n\n## The evidence vault\n\nA private, encrypted sgit vault, opened at 2026-10-22T08:03Z, written to by 4 agents and the editor. It holds 61 sources and 62 captures at commit `379e3d7f172a`. Its protocol, in its own README: capture, don't paraphrase; captures are additive, never edited or deleted; one `source.json` and one `notes.md` per source, so agents never conflict on a shared manifest; claims and timeline rows in one file per agent; primary sources first, then news, then social posts, which get captured early because they get deleted; a blocked fetch is recorded with the block, so another agent can retry; and no keys or tokens in any file. The vault is private because it holds verbatim third-party pages for the record; this site publishes their hashes, their URLs and short quotations, and never the pages.\n\n## Five words for how far a claim can be trusted\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n\nA claim never gets a better word than its sources give it. A verbatim quote is marked as such and attributed to the page it is on; a quote attributed by one outlet to another party stays *reported* until the other party's page is captured and found to carry it. The one case so far where that check failed, the BBC's NCSC sentence, is on the agencies page.\n\n## Deterministic, and why that matters\n\nThe build reads `data/` and `VERSION` and writes every page. It has no clock, no random number and no network: run it twice and the output is byte-identical, which the gate checks. That means a page can be reproduced from the data at any version, a diff between two versions is a diff in the data, and a reader who doubts a page can rebuild it. Times on pages are the sources' times; the only date the site adds is the time of the latest capture, which is itself read from the vault.\n\n- `admin/build/export_vault.py --from ` reads the vault and writes the manifest with every hash, the merged per-agent claims and timeline, the vault's HEAD and the software inventory counts. Never the captures.\n\n- `admin/build/build.py` builds every page, its markdown twin, `data/graph.json` and `llms.txt`.\n\n- `admin/build/validate.py` is the gate: every internal link resolves; every page is linked from somewhere and has a markdown twin and an llms.txt line; every claim and event cites a slug in the manifest; the build is byte-identical when run again; no em-dash in the site's prose; no credential shape anywhere in the tree.\n\n- `admin/build/release.sh` bumps the version, builds, validates, runs the leak tripwire over the staged diff, pushes, and polls the live site for the new version before it will say the release is done.\n\n## For an agent\n\nEverything on this site is in `data/` as JSON and every page has a markdown twin at the same path; llms.txt lists them. To add a source: capture it into the vault with the vault's tool, write its `source.json` and `notes.md`, add rows to your own `claims/.json` and `timeline/.json`, commit with your agent's name, push. To change this site: edit `data/`, run the build, run the gate. Do not edit a generated page; the build will overwrite it. The vault's claims and timeline files are exported as vault-claims.json and vault-timeline.json; this site's own rows are in claims.json and timeline.json, written by the agent `claude-story-site` from every note in the vault.\n\n## Replicate it for the next incident\n\nNothing here is specific to PHP. The vault protocol, the capture tool, the five status words, the export, the build and the gate would carry a story about any incident, outage or disclosure. The repository is public under Apache-2.0 and CC BY 4.0; the next story starts by copying it, emptying `data/`, and opening a vault."
    },
    {
     "v": 2,
     "hash": "653df70caad9",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The method: capture, hash, claim, build, gate\n\nHow 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.\n\n# The method: capture, hash, claim, build, gate\n\nThis site is the newsroom's PHP flaws section taken to its conclusion: a site whose every sentence can be traced to bytes, rebuilt by a script from the vault, with no step a reader has to take on trust. It is also a test of the stack sgit.ai is building, and says so in its footer.\n\n## The evidence vault\n\nA private, encrypted sgit vault, opened at 2026-10-22T08:03Z, written to by 5 agents and the editor. It holds 144 sources and 137 captures at commit `200d08971937`. Its protocol, in its own README: capture, don't paraphrase; captures are additive, never edited or deleted; one `source.json` and one `notes.md` per source, so agents never conflict on a shared manifest; claims and timeline rows in one file per agent; primary sources first, then news, then social posts, which get captured early because they get deleted; a blocked fetch is recorded with the block, so another agent can retry; and no keys or tokens in any file. The vault is private because it holds verbatim third-party pages for the record; this site publishes their hashes, their URLs and short quotations, and never the pages.\n\n## Five words for how far a claim can be trusted\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\nA claim never gets a better word than its sources give it. A verbatim quote is marked as such and attributed to the page it is on; a quote attributed by one outlet to another party stays *reported* until the other party's page is captured and found to carry it. The one case so far where that check failed, the BBC's NCSC sentence, is on the agencies page.\n\n## Deterministic, and why that matters\n\nThe build reads `data/` and `VERSION` and writes every page. It has no clock, no random number and no network: run it twice and the output is byte-identical, which the gate checks. That means a page can be reproduced from the data at any version, a diff between two versions is a diff in the data, and a reader who doubts a page can rebuild it. Times on pages are the sources' times; the only date the site adds is the time of the latest capture, which is itself read from the vault.\n\n- `admin/build/export_vault.py --from ` reads the vault and writes the manifest with every hash, the merged per-agent claims and timeline, the vault's HEAD and the software inventory counts. Never the captures.\n\n- `admin/build/build.py` builds every page, its markdown twin, `data/graph.json` and `llms.txt`.\n\n- `admin/build/validate.py` is the gate: every internal link resolves; every page is linked from somewhere and has a markdown twin and an llms.txt line; every claim and event cites a slug in the manifest; the build is byte-identical when run again; no em-dash in the site's prose; no credential shape anywhere in the tree.\n\n- `admin/build/release.sh` bumps the version, builds, validates, runs the leak tripwire over the staged diff, pushes, and polls the live site for the new version before it will say the release is done.\n\n## For an agent\n\nEverything on this site is in `data/` as JSON and every page has a markdown twin at the same path; llms.txt lists them. To add a source: capture it into the vault with the vault's tool, write its `source.json` and `notes.md`, add rows to your own `claims/.json` and `timeline/.json`, commit with your agent's name, push. To change this site: edit `data/`, run the build, run the gate. Do not edit a generated page; the build will overwrite it. The vault's claims and timeline files are exported as vault-claims.json and vault-timeline.json; this site's own rows are in claims.json and timeline.json, written by the agent `claude-story-site` from every note in the vault.\n\n## Replicate it for the next incident\n\nNothing here is specific to PHP. The vault protocol, the capture tool, the five status words, the export, the build and the gate would carry a story about any incident, outage or disclosure. The repository is public under Apache-2.0 and CC BY 4.0; the next story starts by copying it, emptying `data/`, and opening a vault."
    },
    {
     "v": 3,
     "hash": "ac26ddfb1867",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The method: capture, hash, claim, build, gate\n\nHow 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.\n\n# The method: capture, hash, claim, build, gate\n\nIn plain English How this site works: save every source, fingerprint it, attach every statement to its evidence, and rebuild the site from that.\n\nThis site is the newsroom's PHP flaws section taken to its conclusion: a site whose every sentence can be traced to bytes, rebuilt by a script from the vault, with no step a reader has to take on trust. It is also a test of the stack sgit.ai is building, and says so in its footer.\n\n## The evidence vault\n\nA private, encrypted sgit vault, opened at 2026-10-22T08:03Z, written to by 5 agents and the editor. It holds 144 sources and 137 captures at commit `200d08971937`. Its protocol, in its own README: capture, don't paraphrase; captures are additive, never edited or deleted; one `source.json` and one `notes.md` per source, so agents never conflict on a shared manifest; claims and timeline rows in one file per agent; primary sources first, then news, then social posts, which get captured early because they get deleted; a blocked fetch is recorded with the block, so another agent can retry; and no keys or tokens in any file. The vault is private because it holds verbatim third-party pages for the record; this site publishes their hashes, their URLs and short quotations, and never the pages.\n\n## Five words for how far a claim can be trusted\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\nA claim never gets a better word than its sources give it. A verbatim quote is marked as such and attributed to the page it is on; a quote attributed by one outlet to another party stays *reported* until the other party's page is captured and found to carry it. The one case so far where that check failed, the BBC's NCSC sentence, is on the agencies page.\n\n## Deterministic, and why that matters\n\nThe build reads `data/` and `VERSION` and writes every page. It has no clock, no random number and no network: run it twice and the output is byte-identical, which the gate checks. That means a page can be reproduced from the data at any version, a diff between two versions is a diff in the data, and a reader who doubts a page can rebuild it. Times on pages are the sources' times; the only date the site adds is the time of the latest capture, which is itself read from the vault.\n\n- `admin/build/export_vault.py --from ` reads the vault and writes the manifest with every hash, the merged per-agent claims and timeline, the vault's HEAD and the software inventory counts. Never the captures.\n\n- `admin/build/build.py` builds every page, its markdown twin, `data/graph.json` and `llms.txt`.\n\n- `admin/build/validate.py` is the gate: every internal link resolves; every page is linked from somewhere and has a markdown twin and an llms.txt line; every claim and event cites a slug in the manifest; the build is byte-identical when run again; no em-dash in the site's prose; no credential shape anywhere in the tree.\n\n- `admin/build/release.sh` bumps the version, builds, validates, runs the leak tripwire over the staged diff, pushes, and polls the live site for the new version before it will say the release is done.\n\n## For an agent\n\nEverything on this site is in `data/` as JSON and every page has a markdown twin at the same path; llms.txt lists them. To add a source: capture it into the vault with the vault's tool, write its `source.json` and `notes.md`, add rows to your own `claims/.json` and `timeline/.json`, commit with your agent's name, push. To change this site: edit `data/`, run the build, run the gate. Do not edit a generated page; the build will overwrite it. The vault's claims and timeline files are exported as vault-claims.json and vault-timeline.json; this site's own rows are in claims.json and timeline.json, written by the agent `claude-story-site` from every note in the vault.\n\n## Replicate it for the next incident\n\nNothing here is specific to PHP. The vault protocol, the capture tool, the five status words, the export, the build and the gate would carry a story about any incident, outage or disclosure. The repository is public under Apache-2.0 and CC BY 4.0; the next story starts by copying it, emptying `data/`, and opening a vault."
    }
   ]
  },
  "briefing-board": {
   "title": "Briefing: Board member or executive",
   "kind": "briefing",
   "path": "briefings/board/index.html",
   "scope": "board",
   "versions": [
    {
     "v": 1,
     "hash": "bce7178ae338",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a board member or executive: Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nThe php2shell story for a board member or executive: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Board member or executive\n\n# Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nThree decisions sit with you: whether the organisation is exposed, what it costs to find out, and who may pull a system. The facts below are the ones those decisions turn on. Everything marked *reported* is one party's word; nothing below is a confirmed compromise anywhere.\n\n## What to decide or do\n- Do we have an inventory of every system serving PHP, including vendor products? If not, that is the first spend.\n- Has every internet-facing system been patched and restarted, and has the running version been checked after the restart?\n- Who is authorised to take a system offline, how long does it take, and has it been rehearsed?\n- What would a compromise of our most exposed PHP system reach: which data, which credentials, which other systems?\n- What is our evidence that we were not exploited between the leak on 20 October and our patch?\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | BBC News |\n| PHP is exposed on 2,608,039 internet-facing hosts | VulnCheck, via The Hacker News | reported | THN |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | CISA CISA CVE record |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network, and proof-of-concept attempts started about 02:00 UTC on 21 OctoberAmazon's own post has not been found. | CJ Moses, Amazon, via The Hacker News | reported | THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | Cloudflare |\n| Amazon and Cloudflare saw sites being probed for the flawSecond-hand, but consistent with what both companies have said themselves. | Alan Woodward, via the BBC | reported | BBC News Cloudflare THN |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | CERT.LV |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | BBC News |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | CISA |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | CERT.LV |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | BBC News |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or advisor."
    },
    {
     "v": 2,
     "hash": "cfd8891bcb45",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a board member or executive: Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nThe php2shell story for a board member or executive: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Board member or executive\n\n# Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nThree decisions sit with you: whether the organisation is exposed, what it costs to find out, and who may pull a system. The facts below are the ones those decisions turn on. Everything marked *reported* is one party's word; nothing below is a confirmed compromise anywhere.\n\n## What to decide or do\n- Do we have an inventory of every system serving PHP, including vendor products? If not, that is the first spend.\n- Has every internet-facing system been patched and restarted, and has the running version been checked after the restart?\n- Who is authorised to take a system offline, how long does it take, and has it been rehearsed?\n- What would a compromise of our most exposed PHP system reach: which data, which credentials, which other systems?\n- What is our evidence that we were not exploited between the leak on 20 October and our patch?\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or advisor · CISO · CTO · CFO · Head of AppSec · Developer · Media and communications team."
    },
    {
     "v": 3,
     "hash": "9b02e962c405",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a board member or executive: Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nThe 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.\n\nBriefing for Jordan, board member or executive · ******Plain English\n\n# Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nJ\nThe answer in thirty seconds\n\nA critical flaw in software that runs many websites, fixed on 21 October. Every agency says update first; some say take systems offline if you cannot. No named organisation has confirmed a break-in. Your questions are: do we know every system running PHP, are they updated and restarted, and who can pull a system offline and how fast.\n\nRead the site as Jordan →\n\nThree decisions sit with you: whether the organisation is exposed, what it costs to find out, and who may pull a system. The facts below are the ones those decisions turn on. Everything marked *reported* is one party's word; nothing below is a confirmed compromise anywhere.\n\n## What to decide or do\n- Do we have an inventory of every system serving PHP, including vendor products? If not, that is the first spend.\n- Has every internet-facing system been patched and restarted, and has the running version been checked after the restart?\n- Who is authorised to take a system offline, how long does it take, and has it been rehearsed?\n- What would a compromise of our most exposed PHP system reach: which data, which credentials, which other systems?\n- What is our evidence that we were not exploited between the leak on 20 October and our patch?\n\n## Your reading path\n- Your briefing\n- Explained from scratch\n- Impact: offline vs compromised\n- The agencies\n- If you run PHP\n\nChoose *read as Jordan* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- are we exposed\n- who owns the decision to take a system offline\n- what to ask the CISO\n- which headline figures not to use\n\n### What you can skip\n- SAPIs and settings\n- the C code\n- the leak forensics\n\n\n## The facts this rests on\nShow the 35 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "8e922ae89faf",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a board member or executive: Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nThe 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.\n\nBriefing for Jordan, board member or executive · ******Plain English\n\n# Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nJ\nThe answer in thirty seconds\n\nA critical flaw in software that runs many websites, fixed on 21 October. Every agency says update first; some say take systems offline if you cannot. No named organisation has confirmed a break-in. Your questions are: do we know every system running PHP, are they updated and restarted, and who can pull a system offline and how fast.\n\nRead the site as Jordan →\n\nThree decisions sit with you: whether the organisation is exposed, what it costs to find out, and who may pull a system. The facts below are the ones those decisions turn on. Everything marked *reported* is one party's word; nothing below is a confirmed compromise anywhere.\n\n## What to decide or do\n- Do we have an inventory of every system serving PHP, including vendor products? If not, that is the first spend.\n- Has every internet-facing system been patched and restarted, and has the running version been checked after the restart?\n- Who is authorised to take a system offline, how long does it take, and has it been rehearsed?\n- What would a compromise of our most exposed PHP system reach: which data, which credentials, which other systems?\n- What is our evidence that we were not exploited between the leak on 20 October and our patch?\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The agencies\n- If you run PHP\n\nChoose *read as Jordan* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- are we exposed\n- who owns the decision to take a system offline\n- what to ask the CISO\n- which headline figures not to use\n\n### What you can skip\n- SAPIs and settings\n- the C code\n- the leak forensics\n\n\n## The facts this rests on\nShow the 35 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 5,
     "hash": "ed60a8996c4c",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a board member or executive: Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nThe 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.\n\nBriefing for Jordan, board member or executive · ******Plain English\n\n# Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nJ\nThe answer in thirty seconds\n\nA critical flaw in software that runs many websites, fixed on 21 October. Every agency says update first; some say take systems offline if you cannot. No named organisation has confirmed a break-in. Your questions are: do we know every system running PHP, are they updated and restarted, and who can pull a system offline and how fast.\n\nRead the site as Jordan →\n\nThree decisions sit with you: whether the organisation is exposed, what it costs to find out, and who may pull a system. The facts below are the ones those decisions turn on. Everything marked *reported* is one party's word; nothing below is a confirmed compromise anywhere.\n\n## What to decide or do\n- Do we have an inventory of every system serving PHP, including vendor products? If not, that is the first spend.\n- Has every internet-facing system been patched and restarted, and has the running version been checked after the restart?\n- Who is authorised to take a system offline, how long does it take, and has it been rehearsed?\n- What would a compromise of our most exposed PHP system reach: which data, which credentials, which other systems?\n- What is our evidence that we were not exploited between the leak on 20 October and our patch?\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The agencies\n- If you run PHP\n\nChoose *read as Jordan* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- are we exposed\n- who owns the decision to take a system offline\n- what to ask the CISO\n- which headline figures not to use\n\n### What you can skip\n- SAPIs and settings\n- the C code\n- the leak forensics\n\n\n## The facts this rests on\nShow the 35 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | **A4** Corroborated●●●●○○ status overstated | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 6,
     "hash": "d074c82a2ea0",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a board member or executive: Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nThe 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.\n\nBriefing for Jordan, board member or executive · ******Plain English\n\n# Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nJ\nThe answer in thirty seconds\n\nA critical flaw in software that runs many websites, fixed on 21 October. Every agency says update first; some say take systems offline if you cannot. As of the evening of 22 October, no named organisation has said it was broken into through this flaw, though attempts are widespread. Your questions are: do we know every system running PHP, are they updated and restarted, and who can pull a system offline and how fast.\n\nRead the site as Jordan →\n\nThree decisions sit with you: whether the organisation is exposed, what it costs to find out, and who may pull a system. The facts below are the ones those decisions turn on. Everything marked *reported* is one party's word; nothing below is a confirmed compromise anywhere.\n\n## What to decide or do\n- Do we have an inventory of every system serving PHP, including vendor products? If not, that is the first spend.\n- Has every internet-facing system been patched and restarted, and has the running version been checked after the restart?\n- Who is authorised to take a system offline, how long does it take, and has it been rehearsed?\n- What would a compromise of our most exposed PHP system reach: which data, which credentials, which other systems?\n- What is our evidence that we were not exploited between the leak on 20 October and our patch?\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The agencies\n- If you run PHP\n\nChoose *read as Jordan* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- are we exposed\n- who owns the decision to take a system offline\n- what to ask the CISO\n- which headline figures not to use\n\n### What you can skip\n- SAPIs and settings\n- the C code\n- the leak forensics\n\n\n## The facts this rests on\nShow the 35 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 7,
     "hash": "404d73a3166c",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a board member or executive: Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nThe 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.\n\nBriefing for Jordan, board member or executive · ******Plain English\n\n# Are we exposed, what is it costing us, and who owns the decision to pull a system?\n\nJ\nThe answer in thirty seconds\n\nA critical flaw in software that runs many websites, fixed on 21 October. Every agency says update first; some say take systems offline if you cannot. As of the evening of 22 October, no named organisation has said it was broken into through this flaw, though attempts are widespread. Your questions are: do we know every system running PHP, are they updated and restarted, and who can pull a system offline and how fast.\n\nRead the site as Jordan →\n\nThree decisions sit with you: whether the organisation is exposed, what it costs to find out, and who may pull a system. The facts below are the ones those decisions turn on. Everything marked *reported* is one party's word; nothing below is a confirmed compromise anywhere.\n\n## What to decide or do\n- Do we have an inventory of every system serving PHP, including vendor products? If not, that is the first spend.\n- Has every internet-facing system been patched and restarted, and has the running version been checked after the restart?\n- Who is authorised to take a system offline, how long does it take, and has it been rehearsed?\n- What would a compromise of our most exposed PHP system reach: which data, which credentials, which other systems?\n- What is our evidence that we were not exploited between the leak on 20 October and our patch?\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The agencies\n- If you run PHP\n\nChoose *read as Jordan* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- are we exposed\n- who owns the decision to take a system offline\n- what to ask the CISO\n- which headline figures not to use\n\n### What you can skip\n- SAPIs and settings\n- the C code\n- the leak forensics\n\n\n## The facts this rests on\nShow the 35 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Data protection officer · Head of AppSec · Developer · Communications team."
    }
   ]
  },
  "briefing-security": {
   "title": "Briefing: Security lead",
   "kind": "briefing",
   "path": "briefings/security/index.html",
   "scope": "security",
   "versions": [
    {
     "v": 1,
     "hash": "5dc3a2253e2e",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a security lead: What do I patch first, what do I watch for, and when do I take something offline?\n\nThe php2shell story for a security lead: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Security lead\n\n# What do I patch first, what do I watch for, and when do I take something offline?\n\nPatch order, mitigations, signals and the offline decision. The claims are grouped so that the ones your runbook depends on come first.\n\n## What to decide or do\n- Internet-facing mod_php first, then FPM, then everything else; 7.4 to 8.1 need a migration plan, not a package.\n- Apply the temporary mitigations where patching slips, and record that each one blocks a known path only.\n- Alert on PHP workers spawning shells or fetching tools; log multipart and oversized requests at the edge.\n- Decide the isolate-or-offline threshold now and name who calls it.\n- Re-check KEV and oss-security daily: the exploitation picture and the incomplete-fix question will both move.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | php.net oss-security PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | Calif Wiz |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | oss-security |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | CISA CISA CVE record |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network, and proof-of-concept attempts started about 02:00 UTC on 21 OctoberAmazon's own post has not been found. | CJ Moses, Amazon, via The Hacker News | reported | THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | Cloudflare |\n| Amazon and Cloudflare saw sites being probed for the flawSecond-hand, but consistent with what both companies have said themselves. | Alan Woodward, via the BBC | reported | BBC News Cloudflare THN |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | CERT.LV |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | BBC News |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | CISA |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | BBC News |\n| PHP is exposed on 2,608,039 internet-facing hosts | VulnCheck, via The Hacker News | reported | THN |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | Wiz Wiz on X BBC News |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · PHP or platform engineer · Journalist · Security researcher · Analyst or advisor."
    },
    {
     "v": 2,
     "hash": "17ab4904b0a0",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a security lead: What do I patch first, what do I watch for, and when do I take something offline?\n\nThe php2shell story for a security lead: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Security lead\n\n# What do I patch first, what do I watch for, and when do I take something offline?\n\nPatch order, mitigations, signals and the offline decision. The claims are grouped so that the ones your runbook depends on come first.\n\n## What to decide or do\n- Internet-facing mod_php first, then FPM, then everything else; 7.4 to 8.1 need a migration plan, not a package.\n- Apply the temporary mitigations where patching slips, and record that each one blocks a known path only.\n- Alert on PHP workers spawning shells or fetching tools; log multipart and oversized requests at the edge.\n- Decide the isolate-or-offline threshold now and name who calls it.\n- Re-check KEV and oss-security daily: the exploitation picture and the incomplete-fix question will both move.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · PHP or platform engineer · Journalist · Security researcher · Analyst or advisor · CISO · CTO · CFO · Head of AppSec · Developer · Media and communications team."
    },
    {
     "v": 3,
     "hash": "02433c9dc030",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a security lead: What do I patch first, what do I watch for, and when do I take something offline?\n\nThe 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.\n\nBriefing for Sam, security lead · ******Some technical\n\n# What do I patch first, what do I watch for, and when do I take something offline?\n\nS\nThe answer in thirty seconds\n\nInternet-facing mod_php first, then FPM, then everything else. Where patching slips, apply php.net's temporary settings and record that each blocks a known path only. Alert on PHP workers spawning shells or fetching tools. Decide now who calls isolate or offline, and when.\n\nRead the site as Sam →\n\nPatch order, mitigations, signals and the offline decision. The claims are grouped so that the ones your runbook depends on come first.\n\n## What to decide or do\n- Internet-facing mod_php first, then FPM, then everything else; 7.4 to 8.1 need a migration plan, not a package.\n- Apply the temporary mitigations where patching slips, and record that each one blocks a known path only.\n- Alert on PHP workers spawning shells or fetching tools; log multipart and oversized requests at the edge.\n- Decide the isolate-or-offline threshold now and name who calls it.\n- Re-check KEV and oss-security daily: the exploitation picture and the incomplete-fix question will both move.\n\n## Your reading path\n- Your briefing\n- If you run PHP\n- Exploitation signals\n- Detection and defence\n- The agencies\n\nChoose *read as Sam* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- patch order\n- temporary mitigations and what each misses\n- what to alert on\n- the offline threshold\n\n### What you can skip\n- the leak forensics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "dc4e3e0c7795",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a security lead: What do I patch first, what do I watch for, and when do I take something offline?\n\nThe 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.\n\nBriefing for Sam, security lead · ******Some technical\n\n# What do I patch first, what do I watch for, and when do I take something offline?\n\nS\nThe answer in thirty seconds\n\nInternet-facing mod_php first, then FPM, then everything else. Where patching slips, apply php.net's temporary settings and record that each blocks a known path only. Alert on PHP workers spawning shells or fetching tools. Decide now who calls isolate or offline, and when.\n\nRead the site as Sam →\n\nPatch order, mitigations, signals and the offline decision. The claims are grouped so that the ones your runbook depends on come first.\n\n## What to decide or do\n- Internet-facing mod_php first, then FPM, then everything else; 7.4 to 8.1 need a migration plan, not a package.\n- Apply the temporary mitigations where patching slips, and record that each one blocks a known path only.\n- Alert on PHP workers spawning shells or fetching tools; log multipart and oversized requests at the edge.\n- Decide the isolate-or-offline threshold now and name who calls it.\n- Re-check KEV and oss-security daily: the exploitation picture and the incomplete-fix question will both move.\n\n## Your reading path\n- Your briefing\n- If you run PHP\n- Exploitation signals\n- Detection and defence\n- The agencies\n\nChoose *read as Sam* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- patch order\n- temporary mitigations and what each misses\n- what to alert on\n- the offline threshold\n\n### What you can skip\n- the leak forensics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 5,
     "hash": "afe8ce93fff3",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a security lead: What do I patch first, what do I watch for, and when do I take something offline?\n\nThe 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.\n\nBriefing for Sam, security lead · ******Some technical\n\n# What do I patch first, what do I watch for, and when do I take something offline?\n\nS\nThe answer in thirty seconds\n\nInternet-facing mod_php first, then FPM, then everything else. Where patching slips, apply php.net's temporary settings and record that each blocks a known path only. Alert on PHP workers spawning shells or fetching tools. Decide now who calls isolate or offline, and when.\n\nRead the site as Sam →\n\nPatch order, mitigations, signals and the offline decision. The claims are grouped so that the ones your runbook depends on come first.\n\n## What to decide or do\n- Internet-facing mod_php first, then FPM, then everything else; 7.4 to 8.1 need a migration plan, not a package.\n- Apply the temporary mitigations where patching slips, and record that each one blocks a known path only.\n- Alert on PHP workers spawning shells or fetching tools; log multipart and oversized requests at the edge.\n- Decide the isolate-or-offline threshold now and name who calls it.\n- Re-check KEV and oss-security daily: the exploitation picture and the incomplete-fix question will both move.\n\n## Your reading path\n- Your briefing\n- If you run PHP\n- Exploitation signals\n- Detection and defence\n- The agencies\n\nChoose *read as Sam* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- patch order\n- temporary mitigations and what each misses\n- what to alert on\n- the offline threshold\n\n### What you can skip\n- the leak forensics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 6,
     "hash": "c455ac2e2c7e",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a security lead: What do I patch first, what do I watch for, and when do I take something offline?\n\nThe 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.\n\nBriefing for Sam, security lead · ******Some technical\n\n# What do I patch first, what do I watch for, and when do I take something offline?\n\nS\nThe answer in thirty seconds\n\nInternet-facing mod_php first, then FPM, then everything else. Where patching slips, apply php.net's temporary settings and record that each blocks a known path only. Alert on PHP workers spawning shells or fetching tools. Decide now who calls isolate or offline, and when.\n\nRead the site as Sam →\n\nPatch order, mitigations, signals and the offline decision. The claims are grouped so that the ones your runbook depends on come first.\n\n## What to decide or do\n- Internet-facing mod_php first, then FPM, then everything else; 7.4 to 8.1 need a migration plan, not a package.\n- Apply the temporary mitigations where patching slips, and record that each one blocks a known path only.\n- Alert on PHP workers spawning shells or fetching tools; log multipart and oversized requests at the edge.\n- Decide the isolate-or-offline threshold now and name who calls it.\n- Re-check KEV and oss-security daily: the exploitation picture and the incomplete-fix question will both move.\n\n## Your reading path\n- Your briefing\n- If you run PHP\n- Exploitation signals\n- Detection and defence\n- The agencies\n\nChoose *read as Sam* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- patch order\n- temporary mitigations and what each misses\n- what to alert on\n- the offline threshold\n\n### What you can skip\n- the leak forensics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Data protection officer · Head of AppSec · Developer · Communications team."
    }
   ]
  },
  "briefing-engineer": {
   "title": "Briefing: PHP or platform engineer",
   "kind": "briefing",
   "path": "briefings/engineer/index.html",
   "scope": "engineer",
   "versions": [
    {
     "v": 1,
     "hash": "5da8d59a2b0e",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a php or platform engineer: Which versions, which SAPIs, which settings, which commands?\n\nThe php2shell story for a php or platform engineer: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · PHP or platform engineer\n\n# Which versions, which SAPIs, which settings, which commands?\n\nVersions, SAPIs, settings and what each does. The claims are the primary records' own words where they exist.\n\n## What to decide or do\n- Target 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart every worker; rebuild images.\n- memory_limit=-1 via php_admin_value; post_max_size 8M or 32M; cgroup limits not RLIMIT; session.upload_progress.enabled=0 in php.ini or the pool, never ini_set; fatal_error_backtraces=0 on 8.5; pm.max_requests=1.\n- The CVE record calls 7.4 to 8.1 unaffected by omission; the backport branches say otherwise. Do not trust a scanner on this.\n- The 8.5.12 fix may have a follow-up; watch php.net and oss-security.\n- Verify the running version with phpinfo or php -v inside the container, after the restart.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | php.net oss-security PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | Calif Wiz |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · Journalist · Security researcher · Analyst or advisor."
    },
    {
     "v": 2,
     "hash": "4c677065840e",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a php or platform engineer: Which versions, which SAPIs, which settings, which commands?\n\nThe php2shell story for a php or platform engineer: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · PHP or platform engineer\n\n# Which versions, which SAPIs, which settings, which commands?\n\nVersions, SAPIs, settings and what each does. The claims are the primary records' own words where they exist.\n\n## What to decide or do\n- Target 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart every worker; rebuild images.\n- memory_limit=-1 via php_admin_value; post_max_size 8M or 32M; cgroup limits not RLIMIT; session.upload_progress.enabled=0 in php.ini or the pool, never ini_set; fatal_error_backtraces=0 on 8.5; pm.max_requests=1.\n- The CVE record calls 7.4 to 8.1 unaffected by omission; the backport branches say otherwise. Do not trust a scanner on this.\n- The 8.5.12 fix may have a follow-up; watch php.net and oss-security.\n- Verify the running version with phpinfo or php -v inside the container, after the restart.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · Journalist · Security researcher · Analyst or advisor · CISO · CTO · CFO · Head of AppSec · Developer · Media and communications team."
    },
    {
     "v": 3,
     "hash": "b379ac568a6e",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a php or platform engineer: Which versions, which SAPIs, which settings, which commands?\n\nThe 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.\n\nBriefing for Drew, php or platform engineer · ******Deeply technical\n\n# Which versions, which SAPIs, which settings, which commands?\n\nD\nThe answer in thirty seconds\n\nTarget 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart every worker and rebuild images. Until then: session.upload_progress.enabled=0 in php.ini or the pool, low post_max_size, fatal_error_backtraces=0 on 8.5, pm.max_requests=1 on FPM. Verify with php -v inside the running container.\n\nRead the site as Drew →\n\nVersions, SAPIs, settings and what each does. The claims are the primary records' own words where they exist.\n\n## What to decide or do\n- Target 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart every worker; rebuild images.\n- memory_limit=-1 via php_admin_value; post_max_size 8M or 32M; cgroup limits not RLIMIT; session.upload_progress.enabled=0 in php.ini or the pool, never ini_set; fatal_error_backtraces=0 on 8.5; pm.max_requests=1.\n- The CVE record calls 7.4 to 8.1 unaffected by omission; the backport branches say otherwise. Do not trust a scanner on this.\n- The 8.5.12 fix may have a follow-up; watch php.net and oss-security.\n- Verify the running version with phpinfo or php -v inside the container, after the restart.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- If you run PHP\n- Affected systems\n- The code\n\nChoose *read as Drew* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- fixed versions\n- which SAPI is how exposed\n- the exact settings and where they must be set\n- how to verify the running version\n\n### What you can skip\n- the board line\n- the money\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "b548667cc89b",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a php or platform engineer: Which versions, which SAPIs, which settings, which commands?\n\nThe 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.\n\nBriefing for Drew, php or platform engineer · ******Deeply technical\n\n# Which versions, which SAPIs, which settings, which commands?\n\nD\nThe answer in thirty seconds\n\nTarget 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart every worker and rebuild images. Until then: session.upload_progress.enabled=0 in php.ini or the pool, low post_max_size, fatal_error_backtraces=0 on 8.5, pm.max_requests=1 on FPM. Verify with php -v inside the running container.\n\nRead the site as Drew →\n\nVersions, SAPIs, settings and what each does. The claims are the primary records' own words where they exist.\n\n## What to decide or do\n- Target 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart every worker; rebuild images.\n- memory_limit=-1 via php_admin_value; post_max_size 8M or 32M; cgroup limits not RLIMIT; session.upload_progress.enabled=0 in php.ini or the pool, never ini_set; fatal_error_backtraces=0 on 8.5; pm.max_requests=1.\n- The CVE record calls 7.4 to 8.1 unaffected by omission; the backport branches say otherwise. Do not trust a scanner on this.\n- The 8.5.12 fix may have a follow-up; watch php.net and oss-security.\n- Verify the running version with phpinfo or php -v inside the container, after the restart.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- If you run PHP\n- Affected systems\n- The code\n\nChoose *read as Drew* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- fixed versions\n- which SAPI is how exposed\n- the exact settings and where they must be set\n- how to verify the running version\n\n### What you can skip\n- the board line\n- the money\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 5,
     "hash": "175915ad2607",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a PHP or platform engineer: Which versions, which SAPIs, which settings, which commands?\n\nThe 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.\n\nBriefing for Drew, php or platform engineer · ******Deeply technical\n\n# Which versions, which SAPIs, which settings, which commands?\n\nD\nThe answer in thirty seconds\n\nTarget 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart every worker and rebuild images. Until then: session.upload_progress.enabled=0 in php.ini or the pool, low post_max_size, fatal_error_backtraces=0 on 8.5, pm.max_requests=1 on FPM. Verify with php -v inside the running container.\n\nRead the site as Drew →\n\nVersions, SAPIs, settings and what each does. The claims are the primary records' own words where they exist.\n\n## What to decide or do\n- Target 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart every worker; rebuild images.\n- memory_limit=-1 via php_admin_value; post_max_size 8M or 32M; cgroup limits not RLIMIT; session.upload_progress.enabled=0 in php.ini or the pool, never ini_set; fatal_error_backtraces=0 on 8.5; pm.max_requests=1.\n- The CVE record calls 7.4 to 8.1 unaffected by omission; the backport branches say otherwise. Do not trust a scanner on this.\n- The 8.5.12 fix may have a follow-up; watch php.net and oss-security.\n- Verify the running version with phpinfo or php -v inside the container, after the restart.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- If you run PHP\n- Affected systems\n- The code\n\nChoose *read as Drew* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- fixed versions\n- which SAPI is how exposed\n- the exact settings and where they must be set\n- how to verify the running version\n\n### What you can skip\n- the board line\n- the money\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 6,
     "hash": "ef0947d9399b",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a PHP or platform engineer: Which versions, which SAPIs, which settings, which commands?\n\nThe 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.\n\nBriefing for Drew, php or platform engineer · ******Deeply technical\n\n# Which versions, which SAPIs, which settings, which commands?\n\nD\nThe answer in thirty seconds\n\nTarget 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart every worker and rebuild images. Until then: session.upload_progress.enabled=0 in php.ini or the pool, low post_max_size, fatal_error_backtraces=0 on 8.5, pm.max_requests=1 on FPM. Verify with php -v inside the running container.\n\nRead the site as Drew →\n\nVersions, SAPIs, settings and what each does. The claims are the primary records' own words where they exist.\n\n## What to decide or do\n- Target 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart every worker; rebuild images.\n- memory_limit=-1 via php_admin_value; post_max_size 8M or 32M; cgroup limits not RLIMIT; session.upload_progress.enabled=0 in php.ini or the pool, never ini_set; fatal_error_backtraces=0 on 8.5; pm.max_requests=1.\n- The CVE record calls 7.4 to 8.1 unaffected by omission; the backport branches say otherwise. Do not trust a scanner on this.\n- The 8.5.12 fix may have a follow-up; watch php.net and oss-security.\n- Verify the running version with phpinfo or php -v inside the container, after the restart.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- If you run PHP\n- Affected systems\n- The code\n\nChoose *read as Drew* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- fixed versions\n- which SAPI is how exposed\n- the exact settings and where they must be set\n- how to verify the running version\n\n### What you can skip\n- the board line\n- the money\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 7,
     "hash": "0594804801d9",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a PHP or platform engineer: Which versions, which SAPIs, which settings, which commands?\n\nThe 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.\n\nBriefing for Drew, php or platform engineer · ******Deeply technical\n\n# Which versions, which SAPIs, which settings, which commands?\n\nD\nThe answer in thirty seconds\n\nTarget 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart every worker and rebuild images. Until then: session.upload_progress.enabled=0 in php.ini or the pool, low post_max_size, fatal_error_backtraces=0 on 8.5, pm.max_requests=1 on FPM. Verify with php -v inside the running container.\n\nRead the site as Drew →\n\nVersions, SAPIs, settings and what each does. The claims are the primary records' own words where they exist.\n\n## What to decide or do\n- Target 8.5.12, 8.4.27, 8.3.36 or 8.2.35; restart every worker; rebuild images.\n- memory_limit=-1 via php_admin_value; post_max_size 8M or 32M; cgroup limits not RLIMIT; session.upload_progress.enabled=0 in php.ini or the pool, never ini_set; fatal_error_backtraces=0 on 8.5; pm.max_requests=1.\n- The CVE record calls 7.4 to 8.1 unaffected by omission; the backport branches say otherwise. Do not trust a scanner on this.\n- The 8.5.12 fix may have a follow-up; watch php.net and oss-security.\n- Verify the running version with phpinfo or php -v inside the container, after the restart.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- If you run PHP\n- Affected systems\n- The code\n\nChoose *read as Drew* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- fixed versions\n- which SAPI is how exposed\n- the exact settings and where they must be set\n- how to verify the running version\n\n### What you can skip\n- the board line\n- the money\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Data protection officer · Head of AppSec · Developer · Communications team."
    }
   ]
  },
  "briefing-journalist": {
   "title": "Briefing: Journalist",
   "kind": "briefing",
   "path": "briefings/journalist/index.html",
   "scope": "journalist",
   "versions": [
    {
     "v": 1,
     "hash": "51f11dadb579",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a journalist: Which numbers hold up, who said what first, and what is still unverified?\n\nThe php2shell story for a journalist: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Journalist\n\n# Which numbers hold up, who said what first, and what is still unverified?\n\nWhich numbers hold up, who said what first, which quotes are on the page they are attributed to, and what nobody has verified. Every row links to the captured source so the quote can be checked against the bytes.\n\n## What to decide or do\n- The 70% figure is a share of websites that use PHP, restated as a share of the Internet; no page on this beat sources it.\n- The release was 21 October 13:34 to 14:06 UTC, not 22 October; the php.net changelog still says 22.\n- The sentence the BBC attributes to the NCSC is not on the NCSC page as captured; the opening matches Canada's text.\n- Australia's agency gives no offline advice; the EU's says isolate.\n- Three parties claim discovery; their own dates do not conflict, their framing does. The Foundation says Calif and OpenAI reported the same root cause on the same day.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | BBC News |\n| PHP is exposed on 2,608,039 internet-facing hosts | VulnCheck, via The Hacker News | reported | THN |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | Wiz Wiz on X BBC News |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | Calif Ryan Austin , Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | BBC News Wiz |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixChainguard reportedly does not dispute the time but denies leaking (Techzine, blocked by a bot challenge; snippet only). | PHP Foundation | disputed | PHP Foundation Techzine |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | BBC News php.net php-src |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | CISA |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · PHP or platform engineer · Security researcher · Analyst or advisor."
    },
    {
     "v": 2,
     "hash": "e5cfa650dfe5",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a journalist: Which numbers hold up, who said what first, and what is still unverified?\n\nThe php2shell story for a journalist: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Journalist\n\n# Which numbers hold up, who said what first, and what is still unverified?\n\nWhich numbers hold up, who said what first, which quotes are on the page they are attributed to, and what nobody has verified. Every row links to the captured source so the quote can be checked against the bytes.\n\n## What to decide or do\n- The 70% figure is a share of websites that use PHP, restated as a share of the Internet; no page on this beat sources it.\n- The release was 21 October 13:34 to 14:06 UTC, not 22 October; the php.net changelog still says 22.\n- The sentence the BBC attributes to the NCSC is not on the NCSC page as captured; the opening matches Canada's text.\n- Australia's agency gives no offline advice; the EU's says isolate.\n- Three parties claim discovery; their own dates do not conflict, their framing does. The Foundation says Calif and OpenAI reported the same root cause on the same day.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin , Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src , read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · PHP or platform engineer · Security researcher · Analyst or advisor · CISO · CTO · CFO · Head of AppSec · Developer · Media and communications team."
    },
    {
     "v": 3,
     "hash": "37d9fe0625ef",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a journalist: Which numbers hold up, who said what first, and what is still unverified?\n\nThe 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.\n\nBriefing for Rowan, journalist · ******Some technical\n\n# Which numbers hold up, who said what first, and what is still unverified?\n\nR\nThe answer in thirty seconds\n\nThe 70% figure is a share of websites that use PHP, restated as a share of the Internet. The release was 21 October, not 22. Three parties claim the discovery; their dates do not conflict, their framing does. No agency has confirmed a successful compromise, and CISA has not listed either flaw as exploited.\n\nRead the site as Rowan →\n\nWhich numbers hold up, who said what first, which quotes are on the page they are attributed to, and what nobody has verified. Every row links to the captured source so the quote can be checked against the bytes.\n\n## What to decide or do\n- The 70% figure is a share of websites that use PHP, restated as a share of the Internet; no page on this beat sources it.\n- The release was 21 October 13:34 to 14:06 UTC, not 22 October; the php.net changelog still says 22.\n- The sentence the BBC attributes to the NCSC is not on the NCSC page as captured; the opening matches Canada's text.\n- Australia's agency gives no offline advice; the EU's says isolate.\n- Three parties claim discovery; their own dates do not conflict, their framing does. The Foundation says Calif and OpenAI reported the same root cause on the same day.\n\n## Your reading path\n- Your briefing\n- The numbers\n- Every claim\n- Who found it\n- How disclosure broke\n- The agencies\n\nChoose *read as Rowan* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- which numbers hold up\n- who said what first\n- quotes checked against their source\n- what is unverified\n\n### What you can skip\n- server settings\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin , Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src , read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "59bf6abe1e00",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a journalist: Which numbers hold up, who said what first, and what is still unverified?\n\nThe 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.\n\nBriefing for Rowan, journalist · ******Some technical\n\n# Which numbers hold up, who said what first, and what is still unverified?\n\nR\nThe answer in thirty seconds\n\nThe 70% figure is a share of websites that use PHP, restated as a share of the Internet. The release was 21 October, not 22. Three parties claim the discovery; their dates do not conflict, their framing does. No agency has confirmed a successful compromise, and CISA has not listed either flaw as exploited.\n\nRead the site as Rowan →\n\nWhich numbers hold up, who said what first, which quotes are on the page they are attributed to, and what nobody has verified. Every row links to the captured source so the quote can be checked against the bytes.\n\n## What to decide or do\n- The 70% figure is a share of websites that use PHP, restated as a share of the Internet; no page on this beat sources it.\n- The release was 21 October 13:34 to 14:06 UTC, not 22 October; the php.net changelog still says 22.\n- The sentence the BBC attributes to the NCSC is not on the NCSC page as captured; the opening matches Canada's text.\n- Australia's agency gives no offline advice; the EU's says isolate.\n- Three parties claim discovery; their own dates do not conflict, their framing does. The Foundation says Calif and OpenAI reported the same root cause on the same day.\n\n## Your reading path\n- Your briefing\n- The numbers\n- Every claim\n- Who found it\n- How disclosure broke\n- The agencies\n\nChoose *read as Rowan* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- which numbers hold up\n- who said what first\n- quotes checked against their source\n- what is unverified\n\n### What you can skip\n- server settings\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 5,
     "hash": "8e0373192996",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a journalist: Which numbers hold up, who said what first, and what is still unverified?\n\nThe 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.\n\nBriefing for Rowan, journalist · ******Some technical\n\n# Which numbers hold up, who said what first, and what is still unverified?\n\nR\nThe answer in thirty seconds\n\nThe 70% figure is a share of websites that use PHP, restated as a share of the Internet. The release was 21 October, not 22. Three parties claim the discovery; their dates do not conflict, their framing does. No agency has confirmed a successful compromise, and CISA has not listed either flaw as exploited.\n\nRead the site as Rowan →\n\nWhich numbers hold up, who said what first, which quotes are on the page they are attributed to, and what nobody has verified. Every row links to the captured source so the quote can be checked against the bytes.\n\n## What to decide or do\n- The 70% figure is a share of websites that use PHP, restated as a share of the Internet; no page on this beat sources it.\n- The release was 21 October 13:34 to 14:06 UTC, not 22 October; the php.net changelog still says 22.\n- The sentence the BBC attributes to the NCSC is not on the NCSC page as captured; the opening matches Canada's text.\n- Australia's agency gives no offline advice; the EU's says isolate.\n- Three parties claim discovery; their own dates do not conflict, their framing does. The Foundation says Calif and OpenAI reported the same root cause on the same day.\n\n## Your reading path\n- Your briefing\n- The numbers\n- Every claim\n- Who found it\n- How disclosure broke\n- The agencies\n\nChoose *read as Rowan* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- which numbers hold up\n- who said what first\n- quotes checked against their source\n- what is unverified\n\n### What you can skip\n- server settings\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | **A3** Echoed●●●○○○ opinion measures differently status overstated | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | **A6** Established●●●●●● | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | **A2** Reported●●○○○○ disputed status overstated | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | **A3** Echoed●●●○○○ opinion measures differently | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | **A2** Reported●●○○○○ | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | **A2** Reported●●○○○○ opinion measures differently | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | **A6** Established●●●●●● | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | **A2** Reported●●○○○○ | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | **A2** Reported●●○○○○ opinion disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | **A4** Corroborated●●●●○○ measures differently status overstated | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | **A2** Reported●●○○○○ disputed | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | **A4** Corroborated●●●●○○ | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | **A3** Echoed●●●○○○ | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | **A2** Reported●●○○○○ | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | **A2** Reported●●○○○○ opinion disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | **A6** Established●●●●●● | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | **A2** Reported●●○○○○ disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | **A2** Reported●●○○○○ disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | refuted measures differently | 2/3 | BBC News php.net php-src |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 6,
     "hash": "1ab51a2c7634",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a journalist: Which numbers hold up, who said what first, and what is still unverified?\n\nThe 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.\n\nBriefing for Rowan, journalist · ******Some technical\n\n# Which numbers hold up, who said what first, and what is still unverified?\n\nR\nThe answer in thirty seconds\n\nThe 70% figure is a share of websites that use PHP, restated as a share of the Internet. The release was 21 October, not 22. Three parties claim the discovery; their dates do not conflict, their framing does. No agency has confirmed a successful compromise, and CISA has not listed either flaw as exploited.\n\nRead the site as Rowan →\n\nWhich numbers hold up, who said what first, which quotes are on the page they are attributed to, and what nobody has verified. Every row links to the captured source so the quote can be checked against the bytes.\n\n## What to decide or do\n- The 70% figure is a share of websites that use PHP, restated as a share of the Internet; no page on this beat sources it.\n- The release was 21 October 13:34 to 14:06 UTC, not 22 October; the php.net changelog still says 22.\n- The sentence the BBC attributes to the NCSC is not on the NCSC page as captured; the opening matches Canada's text.\n- Australia's agency gives no offline advice; the EU's says isolate.\n- Three parties claim discovery; their own dates do not conflict, their framing does. The Foundation says Calif and OpenAI reported the same root cause on the same day.\n\n## Your reading path\n- Your briefing\n- The numbers\n- Every claim\n- Who found it\n- How disclosure broke\n- The agencies\n\nChoose *read as Rowan* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- which numbers hold up\n- who said what first\n- quotes checked against their source\n- what is unverified\n\n### What you can skip\n- server settings\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | **A3** Echoed●●●○○○ opinion measures differently status overstated | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | **A6** Established●●●●●● | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | **A2** Reported●●○○○○ disputed status overstated | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | **A3** Echoed●●●○○○ opinion measures differently | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | **A2** Reported●●○○○○ | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | **A2** Reported●●○○○○ opinion measures differently | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | **A6** Established●●●●●● | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | **A2** Reported●●○○○○ | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | **A2** Reported●●○○○○ opinion disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | **A4** Corroborated●●●●○○ measures differently status overstated | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | **A2** Reported●●○○○○ disputed | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | **A4** Corroborated●●●●○○ | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | **A3** Echoed●●●○○○ | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | **A2** Reported●●○○○○ | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | **A2** Reported●●○○○○ opinion disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | **A6** Established●●●●●● | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | **A2** Reported●●○○○○ disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | **A2** Reported●●○○○○ disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | refuted measures differently | 2/3 | BBC News php.net php-src |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Data protection officer · Head of AppSec · Developer · Communications team."
    }
   ]
  },
  "briefing-researcher": {
   "title": "Briefing: Security researcher",
   "kind": "briefing",
   "path": "briefings/researcher/index.html",
   "scope": "researcher",
   "versions": [
    {
     "v": 1,
     "hash": "5cd4fe2b678e",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a security researcher: What are the bug classes, what was demonstrated, and what is still open?\n\nThe php2shell story for a security researcher: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Security researcher\n\n# What are the bug classes, what was demonstrated, and what is still open?\n\nBug classes, what was demonstrated against what, credits, and the open technical questions.\n\n## What to decide or do\n- Two classes: OOM longjmp leaving request memory uninitialised (CWE-416/755/824/1325/1419), and worker global state pointing at freed request memory across requests.\n- mod_php exploited pre-application with default limits; FPM via session upload progress for 109619; FPM for 109618 disputed between the GHSA and the Foundation blog.\n- Credits on both GHSAs: lcfr-hax, sagitzadik-wiz, amyb-oai, tomash-areion. The last is unexplained.\n- Open: the Fediverse report of a third bug or incomplete fix; Calif's hash pre-image; whether the embedded demo is the deleted video.\n- The fix changes the engine: soft OOM at a VM safe point, hard OOM via _exit(). Expect behavioural differences under memory pressure.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | php.net oss-security PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | Calif Wiz |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | oss-security |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | Calif Ryan Austin , Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | BBC News Wiz |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixChainguard reportedly does not dispute the time but denies leaking (Techzine, blocked by a bot challenge; snippet only). | PHP Foundation | disputed | PHP Foundation Techzine |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · PHP or platform engineer · Journalist · Analyst or advisor."
    },
    {
     "v": 2,
     "hash": "50989cf97e07",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a security researcher: What are the bug classes, what was demonstrated, and what is still open?\n\nThe php2shell story for a security researcher: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Security researcher\n\n# What are the bug classes, what was demonstrated, and what is still open?\n\nBug classes, what was demonstrated against what, credits, and the open technical questions.\n\n## What to decide or do\n- Two classes: OOM longjmp leaving request memory uninitialised (CWE-416/755/824/1325/1419), and worker global state pointing at freed request memory across requests.\n- mod_php exploited pre-application with default limits; FPM via session upload progress for 109619; FPM for 109618 disputed between the GHSA and the Foundation blog.\n- Credits on both GHSAs: lcfr-hax, sagitzadik-wiz, amyb-oai, tomash-areion. The last is unexplained.\n- Open: the Fediverse report of a third bug or incomplete fix; Calif's hash pre-image; whether the embedded demo is the deleted video.\n- The fix changes the engine: soft OOM at a VM safe point, hard OOM via _exit(). Expect behavioural differences under memory pressure.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin , Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · PHP or platform engineer · Journalist · Analyst or advisor · CISO · CTO · CFO · Head of AppSec · Developer · Media and communications team."
    },
    {
     "v": 3,
     "hash": "22533883404c",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a security researcher: What are the bug classes, what was demonstrated, and what is still open?\n\nThe 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.\n\nBriefing for Ash, security researcher · ******Deeply technical\n\n# What are the bug classes, what was demonstrated, and what is still open?\n\nA\nThe answer in thirty seconds\n\nTwo classes: an out-of-memory longjmp leaving request memory uninitialised, and worker global state pointing at freed request memory across requests. mod_php was exploited before application code; FPM for the first flaw is disputed. The fix removes longjmp for OOM. A report of an incomplete fix is open.\n\nRead the site as Ash →\n\nBug classes, what was demonstrated against what, credits, and the open technical questions.\n\n## What to decide or do\n- Two classes: OOM longjmp leaving request memory uninitialised (CWE-416/755/824/1325/1419), and worker global state pointing at freed request memory across requests.\n- mod_php exploited pre-application with default limits; FPM via session upload progress for 109619; FPM for 109618 disputed between the GHSA and the Foundation blog.\n- Credits on both GHSAs: lcfr-hax, sagitzadik-wiz, amyb-oai, tomash-areion. The last is unexplained.\n- Open: the Fediverse report of a third bug or incomplete fix; Calif's hash pre-image; whether the embedded demo is the deleted video.\n- The fix changes the engine: soft OOM at a VM safe point, hard OOM via _exit(). Expect behavioural differences under memory pressure.\n\n## Your reading path\n- Your briefing\n- The code\n- The two flaws\n- Who found it\n- In context: 2008 to 2026\n\nChoose *read as Ash* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- the two bug classes\n- what was demonstrated against which SAPI\n- the fix in the code\n- the open questions\n\n### What you can skip\n- the board line\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin , Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "af357861680f",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a security researcher: What are the bug classes, what was demonstrated, and what is still open?\n\nThe 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.\n\nBriefing for Ash, security researcher · ******Deeply technical\n\n# What are the bug classes, what was demonstrated, and what is still open?\n\nA\nThe answer in thirty seconds\n\nTwo classes: an out-of-memory longjmp leaving request memory uninitialised, and worker global state pointing at freed request memory across requests. mod_php was exploited before application code; FPM for the first flaw is disputed. The fix removes longjmp for OOM. A report of an incomplete fix is open.\n\nRead the site as Ash →\n\nBug classes, what was demonstrated against what, credits, and the open technical questions.\n\n## What to decide or do\n- Two classes: OOM longjmp leaving request memory uninitialised (CWE-416/755/824/1325/1419), and worker global state pointing at freed request memory across requests.\n- mod_php exploited pre-application with default limits; FPM via session upload progress for 109619; FPM for 109618 disputed between the GHSA and the Foundation blog.\n- Credits on both GHSAs: lcfr-hax, sagitzadik-wiz, amyb-oai, tomash-areion. The last is unexplained.\n- Open: the Fediverse report of a third bug or incomplete fix; Calif's hash pre-image; whether the embedded demo is the deleted video.\n- The fix changes the engine: soft OOM at a VM safe point, hard OOM via _exit(). Expect behavioural differences under memory pressure.\n\n## Your reading path\n- Your briefing\n- The code\n- The two flaws\n- Who found it\n- In context: 2008 to 2026\n\nChoose *read as Ash* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- the two bug classes\n- what was demonstrated against which SAPI\n- the fix in the code\n- the open questions\n\n### What you can skip\n- the board line\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 5,
     "hash": "5eeb1ae03230",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a security researcher: What are the bug classes, what was demonstrated, and what is still open?\n\nThe 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.\n\nBriefing for Ash, security researcher · ******Deeply technical\n\n# What are the bug classes, what was demonstrated, and what is still open?\n\nA\nThe answer in thirty seconds\n\nTwo classes: an out-of-memory longjmp leaving request memory uninitialised, and worker global state pointing at freed request memory across requests. mod_php was exploited before application code; FPM for the first flaw is disputed. The fix removes longjmp for OOM. A report of an incomplete fix is open.\n\nRead the site as Ash →\n\nBug classes, what was demonstrated against what, credits, and the open technical questions.\n\n## What to decide or do\n- Two classes: OOM longjmp leaving request memory uninitialised (CWE-416/755/824/1325/1419), and worker global state pointing at freed request memory across requests.\n- mod_php exploited pre-application with default limits; FPM via session upload progress for 109619; FPM for 109618 disputed between the GHSA and the Foundation blog.\n- Credits on both GHSAs: lcfr-hax, sagitzadik-wiz, amyb-oai, tomash-areion. The last is unexplained.\n- Open: the Fediverse report of a third bug or incomplete fix; Calif's hash pre-image; whether the embedded demo is the deleted video.\n- The fix changes the engine: soft OOM at a VM safe point, hard OOM via _exit(). Expect behavioural differences under memory pressure.\n\n## Your reading path\n- Your briefing\n- The code\n- The two flaws\n- Who found it\n- In context: 2008 to 2026\n\nChoose *read as Ash* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- the two bug classes\n- what was demonstrated against which SAPI\n- the fix in the code\n- the open questions\n\n### What you can skip\n- the board line\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | **A3** Echoed●●●○○○ opinion measures differently status overstated | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | **A6** Established●●●●●● | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | **A2** Reported●●○○○○ disputed status overstated | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | **A3** Echoed●●●○○○ opinion measures differently | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | **A2** Reported●●○○○○ | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | **A2** Reported●●○○○○ opinion measures differently | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | **A6** Established●●●●●● | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | **A2** Reported●●○○○○ | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | **A2** Reported●●○○○○ opinion disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | **A4** Corroborated●●●●○○ measures differently status overstated | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | **A2** Reported●●○○○○ disputed | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | **A4** Corroborated●●●●○○ | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | **A3** Echoed●●●○○○ | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | **A2** Reported●●○○○○ | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | **A2** Reported●●○○○○ opinion disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 6,
     "hash": "556281a0960c",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a security researcher: What are the bug classes, what was demonstrated, and what is still open?\n\nThe 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.\n\nBriefing for Ash, security researcher · ******Deeply technical\n\n# What are the bug classes, what was demonstrated, and what is still open?\n\nA\nThe answer in thirty seconds\n\nTwo classes: an out-of-memory longjmp leaving request memory uninitialised, and worker global state pointing at freed request memory across requests. mod_php was exploited before application code; FPM for the first flaw is disputed. The fix removes longjmp for OOM. A report of an incomplete fix is open.\n\nRead the site as Ash →\n\nBug classes, what was demonstrated against what, credits, and the open technical questions.\n\n## What to decide or do\n- Two classes: OOM longjmp leaving request memory uninitialised (CWE-416/755/824/1325/1419), and worker global state pointing at freed request memory across requests.\n- mod_php exploited pre-application with default limits; FPM via session upload progress for 109619; FPM for 109618 disputed between the GHSA and the Foundation blog.\n- Credits on both GHSAs: lcfr-hax, sagitzadik-wiz, amyb-oai, tomash-areion. The last is unexplained.\n- Open: the Fediverse report of a third bug or incomplete fix; Calif's hash pre-image; whether the embedded demo is the deleted video.\n- The fix changes the engine: soft OOM at a VM safe point, hard OOM via _exit(). Expect behavioural differences under memory pressure.\n\n## Your reading path\n- Your briefing\n- The code\n- The two flaws\n- Who found it\n- In context: 2008 to 2026\n\nChoose *read as Ash* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- the two bug classes\n- what was demonstrated against which SAPI\n- the fix in the code\n- the open questions\n\n### What you can skip\n- the board line\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | **A3** Echoed●●●○○○ opinion measures differently status overstated | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | **A6** Established●●●●●● | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | **A2** Reported●●○○○○ disputed status overstated | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | **A3** Echoed●●●○○○ opinion measures differently | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | **A2** Reported●●○○○○ | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | **A2** Reported●●○○○○ opinion measures differently | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | **A6** Established●●●●●● | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | **A2** Reported●●○○○○ | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | **A2** Reported●●○○○○ opinion disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | **A4** Corroborated●●●●○○ measures differently status overstated | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | **A2** Reported●●○○○○ disputed | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | **A4** Corroborated●●●●○○ | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | **A3** Echoed●●●○○○ | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | **A2** Reported●●○○○○ | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | **A2** Reported●●○○○○ opinion disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Analyst or policy advisor · CISO · CTO · CFO · Data protection officer · Head of AppSec · Developer · Communications team."
    }
   ]
  },
  "briefing-analyst": {
   "title": "Briefing: Analyst or advisor",
   "kind": "briefing",
   "path": "briefings/analyst/index.html",
   "scope": "analyst",
   "versions": [
    {
     "v": 1,
     "hash": "9937d2fe37e2",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a analyst or advisor: How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nThe php2shell story for a analyst or advisor: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Analyst or advisor\n\n# How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nWhat this incident says about coordinated disclosure once models can find bugs, and once a leak can become a proof of concept faster than a patch can ship. The claims below are the evidence; the reading is the site's.\n\n## What to decide or do\n- The window between leak and release was 22.5 hours and the window between first honeypot hit and release was four days. Both are shorter than the two months the fix took.\n- Three AI-assisted teams converged on a bug class seen and shelved in 2024. The constraint that failed in 2024 was proving exploitability, and that is what models now appear to lower the cost of.\n- The defensive side moved early too: WAF rules 9 hours ahead, images 6 hours ahead (against the embargo), agencies within the hour. The system is faster in both directions.\n- The public numbers were not produced for decision-making and should not be used for it; the one agency that counted got about 6,000 in a country of 1.9 million people.\n- Agencies diverged on the hardest question, offline or not, along lines that look institutional rather than technical.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n\n| Claim | Who says it | Status | Sources |\n|---|---|---|---|\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | Calif Ryan Austin , Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | BBC News Wiz |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixChainguard reportedly does not dispute the time but denies leaking (Techzine, blocked by a bot challenge; snippet only). | PHP Foundation | disputed | PHP Foundation Techzine |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | BBC News php.net php-src |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | BBC News |\n| PHP is exposed on 2,608,039 internet-facing hosts | VulnCheck, via The Hacker News | reported | THN |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | CISA CISA CVE record |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network, and proof-of-concept attempts started about 02:00 UTC on 21 OctoberAmazon's own post has not been found. | CJ Moses, Amazon, via The Hacker News | reported | THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | Cloudflare |\n| Amazon and Cloudflare saw sites being probed for the flawSecond-hand, but consistent with what both companies have said themselves. | Alan Woodward, via the BBC | reported | BBC News Cloudflare THN |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | CERT.LV |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | BBC News |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher."
    },
    {
     "v": 2,
     "hash": "fbcb2ece98f2",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a analyst or advisor: How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nThe php2shell story for a analyst or advisor: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Analyst or advisor\n\n# How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nWhat this incident says about coordinated disclosure once models can find bugs, and once a leak can become a proof of concept faster than a patch can ship. The claims below are the evidence; the reading is the site's.\n\n## What to decide or do\n- The window between leak and release was 22.5 hours and the window between first honeypot hit and release was four days. Both are shorter than the two months the fix took.\n- Three AI-assisted teams converged on a bug class seen and shelved in 2024. The constraint that failed in 2024 was proving exploitability, and that is what models now appear to lower the cost of.\n- The defensive side moved early too: WAF rules 9 hours ahead, images 6 hours ahead (against the embargo), agencies within the hour. The system is faster in both directions.\n- The public numbers were not produced for decision-making and should not be used for it; the one agency that counted got about 6,000 in a country of 1.9 million people.\n- Agencies diverged on the hardest question, offline or not, along lines that look institutional rather than technical.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin , Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src , read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · CISO · CTO · CFO · Head of AppSec · Developer · Media and communications team."
    },
    {
     "v": 3,
     "hash": "43ec3bbb42b8",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a analyst or advisor: How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nThe php2shell story for a 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.\n\nBriefing for Blake, analyst or policy advisor · ******Some technical\n\n# How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nB\nThe answer in thirty seconds\n\nA bug class seen and shelved in 2024 was turned into working exploits by three AI-assisted teams within three weeks in August 2026. The disclosure leaked 22.5 hours early. Agencies split on the hardest question, offline or not, along lines that look institutional rather than technical.\n\nRead the site as Blake →\n\nWhat this incident says about coordinated disclosure once models can find bugs, and once a leak can become a proof of concept faster than a patch can ship. The claims below are the evidence; the reading is the site's.\n\n## What to decide or do\n- The window between leak and release was 22.5 hours and the window between first honeypot hit and release was four days. Both are shorter than the two months the fix took.\n- Three AI-assisted teams converged on a bug class seen and shelved in 2024. The constraint that failed in 2024 was proving exploitability, and that is what models now appear to lower the cost of.\n- The defensive side moved early too: WAF rules 9 hours ahead, images 6 hours ahead (against the embargo), agencies within the hour. The system is faster in both directions.\n- The public numbers were not produced for decision-making and should not be used for it; the one agency that counted got about 6,000 in a country of 1.9 million people.\n- Agencies diverged on the hardest question, offline or not, along lines that look institutional rather than technical.\n\n## Your reading path\n- Your briefing\n- Who found it\n- How disclosure broke\n- In context: 2008 to 2026\n- The agencies\n- The numbers\n\nChoose *read as Blake* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- how coordinated disclosure failed\n- what AI-assisted discovery changes\n- why agencies diverged\n- the precedent\n\n### What you can skip\n- server settings\n- the code\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin , Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src , read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "eb6325ea4a2b",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a analyst or advisor: How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nThe php2shell story for a 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.\n\nBriefing for Blake, analyst or policy advisor · ******Some technical\n\n# How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nB\nThe answer in thirty seconds\n\nA bug class seen and shelved in 2024 was turned into working exploits by three AI-assisted teams within three weeks in August 2026. The disclosure leaked 22.5 hours early. Agencies split on the hardest question, offline or not, along lines that look institutional rather than technical.\n\nRead the site as Blake →\n\nWhat this incident says about coordinated disclosure once models can find bugs, and once a leak can become a proof of concept faster than a patch can ship. The claims below are the evidence; the reading is the site's.\n\n## What to decide or do\n- The window between leak and release was 22.5 hours and the window between first honeypot hit and release was four days. Both are shorter than the two months the fix took.\n- Three AI-assisted teams converged on a bug class seen and shelved in 2024. The constraint that failed in 2024 was proving exploitability, and that is what models now appear to lower the cost of.\n- The defensive side moved early too: WAF rules 9 hours ahead, images 6 hours ahead (against the embargo), agencies within the hour. The system is faster in both directions.\n- The public numbers were not produced for decision-making and should not be used for it; the one agency that counted got about 6,000 in a country of 1.9 million people.\n- Agencies diverged on the hardest question, offline or not, along lines that look institutional rather than technical.\n\n## Your reading path\n- Your briefing\n- Who found it\n- How disclosure broke\n- In context: 2008 to 2026\n- The agencies\n- The numbers\n\nChoose *read as Blake* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- how coordinated disclosure failed\n- what AI-assisted discovery changes\n- why agencies diverged\n- the precedent\n\n### What you can skip\n- server settings\n- the code\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 5,
     "hash": "a5b7868d0860",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for an analyst or advisor: How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nThe 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.\n\nBriefing for Blake, analyst or policy advisor · ******Some technical\n\n# How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nB\nThe answer in thirty seconds\n\nA bug class seen and shelved in 2024 was turned into working exploits by three AI-assisted teams within three weeks in August 2026. The disclosure leaked 22.5 hours early. Agencies split on the hardest question, offline or not, along lines that look institutional rather than technical.\n\nRead the site as Blake →\n\nWhat this incident says about coordinated disclosure once models can find bugs, and once a leak can become a proof of concept faster than a patch can ship. The claims below are the evidence; the reading is the site's.\n\n## What to decide or do\n- The window between leak and release was 22.5 hours and the window between first honeypot hit and release was four days. Both are shorter than the two months the fix took.\n- Three AI-assisted teams converged on a bug class seen and shelved in 2024. The constraint that failed in 2024 was proving exploitability, and that is what models now appear to lower the cost of.\n- The defensive side moved early too: WAF rules 9 hours ahead, images 6 hours ahead (against the embargo), agencies within the hour. The system is faster in both directions.\n- The public numbers were not produced for decision-making and should not be used for it; the one agency that counted got about 6,000 in a country of 1.9 million people.\n- Agencies diverged on the hardest question, offline or not, along lines that look institutional rather than technical.\n\n## Your reading path\n- Your briefing\n- Who found it\n- How disclosure broke\n- In context: 2008 to 2026\n- The agencies\n- The numbers\n\nChoose *read as Blake* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- how coordinated disclosure failed\n- what AI-assisted discovery changes\n- why agencies diverged\n- the precedent\n\n### What you can skip\n- server settings\n- the code\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 6,
     "hash": "209c1ce32988",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for an analyst or advisor: How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nThe 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.\n\nBriefing for Blake, analyst or policy advisor · ******Some technical\n\n# How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nB\nThe answer in thirty seconds\n\nA bug class seen and shelved in 2024 was turned into working exploits by three AI-assisted teams within three weeks in August 2026. The disclosure leaked 22.5 hours early. Agencies split on the hardest question, offline or not, along lines that look institutional rather than technical.\n\nRead the site as Blake →\n\nWhat this incident says about coordinated disclosure once models can find bugs, and once a leak can become a proof of concept faster than a patch can ship. The claims below are the evidence; the reading is the site's.\n\n## What to decide or do\n- The window between leak and release was 22.5 hours and the window between first honeypot hit and release was four days. Both are shorter than the two months the fix took.\n- Three AI-assisted teams converged on a bug class seen and shelved in 2024. The constraint that failed in 2024 was proving exploitability, and that is what models now appear to lower the cost of.\n- The defensive side moved early too: WAF rules 9 hours ahead, images 6 hours ahead (against the embargo), agencies within the hour. The system is faster in both directions.\n- The public numbers were not produced for decision-making and should not be used for it; the one agency that counted got about 6,000 in a country of 1.9 million people.\n- Agencies diverged on the hardest question, offline or not, along lines that look institutional rather than technical.\n\n## Your reading path\n- Your briefing\n- Who found it\n- How disclosure broke\n- In context: 2008 to 2026\n- The agencies\n- The numbers\n\nChoose *read as Blake* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- how coordinated disclosure failed\n- what AI-assisted discovery changes\n- why agencies diverged\n- the precedent\n\n### What you can skip\n- server settings\n- the code\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | **A3** Echoed●●●○○○ opinion measures differently status overstated | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | **A6** Established●●●●●● | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | **A2** Reported●●○○○○ disputed status overstated | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | **A3** Echoed●●●○○○ opinion measures differently | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | **A2** Reported●●○○○○ | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | **A2** Reported●●○○○○ opinion measures differently | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | **A6** Established●●●●●● | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | **A2** Reported●●○○○○ | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | **A2** Reported●●○○○○ opinion disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | **A4** Corroborated●●●●○○ measures differently status overstated | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | **A2** Reported●●○○○○ disputed | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | **A4** Corroborated●●●●○○ | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | **A3** Echoed●●●○○○ | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | **A2** Reported●●○○○○ | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | **A2** Reported●●○○○○ opinion disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | **A6** Established●●●●●● | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | **A2** Reported●●○○○○ disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | **A2** Reported●●○○○○ disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | refuted measures differently | 2/3 | BBC News php.net php-src |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 7,
     "hash": "8afcb1b7d1b3",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for an analyst or advisor: How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nThe 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.\n\nBriefing for Blake, analyst or policy advisor · ******Some technical\n\n# How did coordinated disclosure fail, and what does AI-assisted discovery change?\n\nB\nThe answer in thirty seconds\n\nA bug class seen and shelved in 2024 was turned into working exploits by three AI-assisted teams within three weeks in August 2026. The disclosure leaked 22.5 hours early. Agencies split on the hardest question, offline or not, along lines that look institutional rather than technical.\n\nRead the site as Blake →\n\nWhat this incident says about coordinated disclosure once models can find bugs, and once a leak can become a proof of concept faster than a patch can ship. The claims below are the evidence; the reading is the site's.\n\n## What to decide or do\n- The window between leak and release was 22.5 hours and the window between first honeypot hit and release was four days. Both are shorter than the two months the fix took.\n- Three AI-assisted teams converged on a bug class seen and shelved in 2024. The constraint that failed in 2024 was proving exploitability, and that is what models now appear to lower the cost of.\n- The defensive side moved early too: WAF rules 9 hours ahead, images 6 hours ahead (against the embargo), agencies within the hour. The system is faster in both directions.\n- The public numbers were not produced for decision-making and should not be used for it; the one agency that counted got about 6,000 in a country of 1.9 million people.\n- Agencies diverged on the hardest question, offline or not, along lines that look institutional rather than technical.\n\n## Your reading path\n- Your briefing\n- Who found it\n- How disclosure broke\n- In context: 2008 to 2026\n- The agencies\n- The numbers\n\nChoose *read as Blake* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- how coordinated disclosure failed\n- what AI-assisted discovery changes\n- why agencies diverged\n- the precedent\n\n### What you can skip\n- server settings\n- the code\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | **A3** Echoed●●●○○○ opinion measures differently status overstated | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | **A6** Established●●●●●● | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | **A2** Reported●●○○○○ disputed status overstated | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | **A3** Echoed●●●○○○ opinion measures differently | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | **A2** Reported●●○○○○ | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | **A2** Reported●●○○○○ opinion measures differently | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | **A6** Established●●●●●● | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | **A2** Reported●●○○○○ | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | **A2** Reported●●○○○○ opinion disputed | 1/2 | OpenAI on X THN |\n| The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leakThe php.net ChangeLog still dates all four releases 22 October. Wiz's X thread still says 22 October. | PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release') | confirmed | **A4** Corroborated●●●●○○ measures differently status overstated | 4/4 | PHP Foundation oss-security Wiz on X php.net |\n| On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leakedPrimary party. The Foundation does not say who or where. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP Foundation |\n| The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came downContradicts the Foundation's 'no technical details leaked' and The Hacker News's 'a proof-of-concept exploit leaked'. No copy of the post, screenshot or video is in the vault. | Alexandre Daubois (PHP security team, personal blog) | reported | **A2** Reported●●○○○○ disputed | 0/1 | Daubois |\n| watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release | Daubois; CERT-EU lists a watchTowr X post among public reports | reported | **A4** Corroborated●●●●○○ | 1/2 | Daubois CERT-EU |\n| Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'Calif's own page does not mention a leak or a deleted video; it embeds two demo videos. Whether one of them is the deleted video is unknown. | PHP Foundation | reported | **A3** Echoed●●●○○○ | 3/4 | PHP Foundation PHP Foundation BBC News Calif |\n| Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked | PHP Foundation | reported | **A2** Reported●●○○○○ | 1/1 | PHP Foundation |\n| Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fixDan Lorenc (via The Register): 'I made the call to get these out early when exploits hit in the wild'; several unnamed vendors had reported exploits; Chainguard's honeypots trapped IPs; a researcher warned the company on the Friday and its team then found the bugs independently with an AI harness. No evidence published. The PHP security team found no functional exploit by release time. | PHP Foundation; Chainguard's CEO accepts the time and denies leaking | disputed | **A2** Reported●●○○○○ opinion disputed | 1/3 | PHP Foundation The Register Feross Aboukhadijeh on X on X |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | **A6** Established●●●●●● | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | **A2** Reported●●○○○○ disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | **A2** Reported●●○○○○ disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | refuted measures differently | 2/3 | BBC News php.net php-src |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · CISO · CTO · CFO · Data protection officer · Head of AppSec · Developer · Communications team."
    }
   ]
  },
  "fact-two-cves-9.2": {
   "title": "Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fix",
   "kind": "fact",
   "path": "facts/two-cves-9.2/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "b2222ca4dae7",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35\nWho says it: PHP Group (CNA), GitHub advisories, php.net\nStatus: confirmed\nTopic: technical\nSources: cve-cve-2026-109618, cve-cve-2026-109619, github-ghsa-w8hw-w9fx-j79w, github-ghsa-6wmf-4rv5-p3rp, php-net-advisory"
    }
   ]
  },
  "fact-cvss-10": {
   "title": "The flaws are CVSS 10.0",
   "kind": "fact",
   "path": "facts/cvss-10/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "5de3e8031bd1",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The flaws are CVSS 10.0\nWho says it: social posts on 20 October, relayed by a vendor and a news site\nStatus: contradicted\nTopic: technical\nSources: php-foundation-blog-security-release, daubois-blog-php2shell-rumors"
    }
   ]
  },
  "fact-rce-modphp": {
   "title": "Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any app",
   "kind": "fact",
   "path": "facts/rce-modphp/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "de0376f32fa4",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs\nWho says it: PHP security team (GHSA, oss-security), php.net\nStatus: confirmed\nTopic: technical\nSources: github-ghsa-w8hw-w9fx-j79w, openwall-oss-security-2026-10-21-6, php-net-advisory"
    }
   ]
  },
  "fact-rce-fpm": {
   "title": "Remote code execution is confirmed on PHP-FPM",
   "kind": "fact",
   "path": "facts/rce-fpm/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "be8a7f57d03b",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Remote code execution is confirmed on PHP-FPM\nWho says it: PHP Foundation blog; GHSA-6wmf for the session path\nStatus: disputed\nTopic: technical\nSources: php-foundation-blog-security-release, github-ghsa-6wmf-4rv5-p3rp, github-ghsa-w8hw-w9fx-j79w, openwall-oss-security-2026-10-21-6"
    }
   ]
  },
  "fact-fix-bailout": {
   "title": "The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the ",
   "kind": "fact",
   "path": "facts/fix-bailout/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "d60837dab5b1",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout'\nWho says it: PHP security team\nStatus: confirmed\nTopic: technical\nSources: github-ghsa-w8hw-w9fx-j79w, php-net-changelog-8, github-php-src-branch-7.4-backport"
    }
   ]
  },
  "fact-fix-incomplete": {
   "title": "The 8.5.12 fix may be incomplete, or there is a third, different bug",
   "kind": "fact",
   "path": "facts/fix-incomplete/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "903f23d083b2",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The 8.5.12 fix may be incomplete, or there is a third, different bug\nWho says it: Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez\nStatus: unverified\nTopic: technical\nSources: openwall-oss-security-109619-thread"
    }
   ]
  },
  "fact-versions-old": {
   "title": "All PHP versions from 5 onwards are affected by at least one of the flaws",
   "kind": "fact",
   "path": "facts/versions-old/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "50ba76d06044",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "All PHP versions from 5 onwards are affected by at least one of the flaws\nWho says it: NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1)\nStatus: disputed\nTopic: technical\nSources: ncsc-nl-advisories, x-wiz-io-php2shell, certfr-2026-ale-014, openwall-oss-security-109619-thread"
    }
   ]
  },
  "fact-only-update": {
   "title": "Updating is the only complete mitigation; the configuration measures reduce exposure to sp",
   "kind": "fact",
   "path": "facts/only-update/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "32c25b4a6db1",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe\nWho says it: php.net; PHP security team\nStatus: confirmed\nTopic: technical\nSources: php-net-advisory, openwall-oss-security-2026-10-21-7, github-ghsa-6wmf-4rv5-p3rp"
    }
   ]
  },
  "fact-waf": {
   "title": "A web application firewall may provide some protection until systems are patched",
   "kind": "fact",
   "path": "facts/waf/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "ad961b9eca40",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "A web application firewall may provide some protection until systems are patched\nWho says it: CISA\nStatus: disputed\nTopic: technical\nSources: cisa-alert-php-20261021, ch-bacs-warnung-php, cloudflare-blog-php2shell-waf"
    }
   ]
  },
  "fact-wordpress-drupal": {
   "title": "Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcu",
   "kind": "fact",
   "path": "facts/wordpress-drupal/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "5526257d23cb",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS\nWho says it: Calif; Wiz for WordPress and Drupal\nStatus: reported\nTopic: technical\nSources: calif-php2shell, wiz-blog-php2shell"
    }
   ]
  },
  "fact-scale-70pc-internet": {
   "title": "Roughly 70% of the Internet is affected",
   "kind": "fact",
   "path": "facts/scale-70pc-internet/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "651204359f46",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Roughly 70% of the Internet is affected\nWho says it: Wiz (headline, X post); BBC attributing Wiz\nStatus: unverified\nTopic: scale\nSources: wiz-blog-php2shell, x-wiz-io-php2shell, bbc-live-ckgel5xp2xv9t"
    }
   ]
  },
  "fact-scale-70pc-websites": {
   "title": "PHP is used by almost 70% of websites",
   "kind": "fact",
   "path": "facts/scale-70pc-websites/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "fac35e957947",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "PHP is used by almost 70% of websites\nWho says it: Cloudflare; OpenAI ('an estimated 70%'); Wiz body text\nStatus: reported\nTopic: scale\nSources: cloudflare-blog-php2shell-waf, x-openai-php2shell, wiz-blog-php2shell"
    }
   ]
  },
  "fact-scale-30m": {
   "title": "Something like 30 million websites could be affected",
   "kind": "fact",
   "path": "facts/scale-30m/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "6c115f410d62",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Something like 30 million websites could be affected\nWho says it: Alan Woodward, via the BBC\nStatus: reported\nTopic: scale\nSources: bbc-live-ckgel5xp2xv9t"
    }
   ]
  },
  "fact-scale-2.6m-hosts": {
   "title": "PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 mi",
   "kind": "fact",
   "path": "facts/scale-2.6m-hosts/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "240ea42d110b",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "PHP is exposed on 2,608,039 internet-facing hosts\nWho says it: VulnCheck, via The Hacker News\nStatus: reported\nTopic: scale\nSources: thehackernews-php2shell-4days"
    },
    {
     "v": 2,
     "hash": "d822fdf94263",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 October\nWho says it: VulnCheck and Censys, via The Hacker News and SecurityWeek\nStatus: reported\nTopic: scale\nSources: thehackernews-php2shell-4days, securityweek-exploitation-days-before"
    }
   ]
  },
  "fact-scale-latvia": {
   "title": "About 6,000 potentially affected resources in Latvia, a few hundred in the public sector",
   "kind": "fact",
   "path": "facts/scale-latvia/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "2b4bcfa874e6",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "About 6,000 potentially affected resources in Latvia, a few hundred in the public sector\nWho says it: CERT.LV\nStatus: reported\nTopic: scale\nSources: certlv-php-preventive"
    }
   ]
  },
  "fact-scale-ncsc-nl": {
   "title": "674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, ",
   "kind": "fact",
   "path": "facts/scale-ncsc-nl/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "1f75e174dd6e",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerable\nWho says it: NCSC-NL, counted by this site from the file at commit cca173c64ec5\nStatus: confirmed\nTopic: scale\nSources: ncsc-nl-php2shell-software-list"
    }
   ]
  },
  "fact-ai-found": {
   "title": "The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet init",
   "kind": "fact",
   "path": "facts/ai-found/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "68655e4118b9",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiative\nWho says it: BBC; OpenAI; Calif; Wiz\nStatus: reported\nTopic: discovery\nSources: bbc-live-ckgel5xp2xv9t, x-openai-php2shell, calif-php2shell, wiz-blog-php2shell"
    }
   ]
  },
  "fact-who-first": {
   "title": "Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 1",
   "kind": "fact",
   "path": "facts/who-first/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "21b6c41bbe7d",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 August\nWho says it: Calif; PHP Foundation (report date)\nStatus: confirmed\nTopic: discovery\nSources: calif-php2shell, x-lcfr-hax-hash-tweet, php-foundation-blog-security-release"
    }
   ]
  },
  "fact-openai-same-day": {
   "title": "OpenAI independently reported the same root cause on 11 August, with further vectors on 18",
   "kind": "fact",
   "path": "facts/openai-same-day/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "e1a2c9d4e3fc",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "OpenAI independently reported the same root cause on 11 August, with further vectors on 18 September\nWho says it: PHP Foundation\nStatus: reported\nTopic: discovery\nSources: php-foundation-blog-security-release, github-ghsa-w8hw-w9fx-j79w"
    }
   ]
  },
  "fact-wiz-independent": {
   "title": "Wiz Research independently discovered the first flaw on 19 August and reported on 24 Augus",
   "kind": "fact",
   "path": "facts/wiz-independent/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "6430bdc82682",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Wiz Research independently discovered the first flaw on 19 August and reported on 24 August\nWho says it: Wiz; PHP Foundation (24 August)\nStatus: reported\nTopic: discovery\nSources: wiz-blog-php2shell, php-foundation-blog-security-release"
    }
   ]
  },
  "fact-four-reporters": {
   "title": "The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-",
   "kind": "fact",
   "path": "facts/four-reporters/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "4713e9be60b0",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areion\nWho says it: GitHub security advisories\nStatus: confirmed\nTopic: discovery\nSources: github-ghsa-w8hw-w9fx-j79w, github-ghsa-6wmf-4rv5-p3rp, daubois-blog-php2shell-rumors"
    }
   ]
  },
  "fact-quarkslab-2024": {
   "title": "The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and t",
   "kind": "fact",
   "path": "facts/quarkslab-2024/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "ef56fae6483a",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixed\nWho says it: PHP Foundation; Calif\nStatus: confirmed\nTopic: discovery\nSources: php-foundation-blog-security-release, calif-php2shell"
    }
   ]
  },
  "fact-ahead-of-attackers": {
   "title": "Frontier AI found the flaw ahead of attackers, giving defenders time to prepare",
   "kind": "fact",
   "path": "facts/ahead-of-attackers/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "30f37fdfd9d0",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Frontier AI found the flaw ahead of attackers, giving defenders time to prepare\nWho says it: OpenAI\nStatus: disputed\nTopic: discovery\nSources: x-openai-php2shell, thehackernews-php2shell-4days"
    }
   ]
  },
  "fact-most-severe": {
   "title": "The most severe flaws ever detected by AI",
   "kind": "fact",
   "path": "facts/most-severe/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "2d9137bf826d",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The most severe flaws ever detected by AI\nWho says it: BBC attributing Wiz\nStatus: reported\nTopic: discovery\nSources: bbc-live-ckgel5xp2xv9t, wiz-blog-php2shell"
    }
   ]
  },
  "fact-leak-cve-ids": {
   "title": "On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social me",
   "kind": "fact",
   "path": "facts/leak-cve-ids/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "3742e4a72141",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "On 20 October at about 15:00 UTC the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS score; no technical details leaked\nWho says it: PHP Foundation\nStatus: reported\nTopic: leak\nSources: php-foundation-blog-security-release, phpfoundation-blog-security-release-leak"
    }
   ]
  },
  "fact-leak-hn": {
   "title": "The leak started with an anonymous Hacker News post citing a reliable source, which came d",
   "kind": "fact",
   "path": "facts/leak-hn/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "3f13b4da3cb0",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The leak started with an anonymous Hacker News post citing a reliable source, which came down after screenshots spread; a screenshot of the 'PHP2Shell tool' credited to Calif.io and a short exploitation video also went up and came down\nWho says it: Alexandre Daubois (PHP security team, personal blog)\nStatus: reported\nTopic: leak\nSources: daubois-blog-php2shell-rumors"
    }
   ]
  },
  "fact-leak-watchtowr": {
   "title": "watchTowr confirmed in public that the bugs were real and posted both CVE numbers before t",
   "kind": "fact",
   "path": "facts/leak-watchtowr/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "e5b40c4d9b0f",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "watchTowr confirmed in public that the bugs were real and posted both CVE numbers before the release\nWho says it: Daubois; CERT-EU lists a watchTowr X post among public reports\nStatus: reported\nTopic: leak\nSources: daubois-blog-php2shell-rumors, certeu-sa-2026-018"
    }
   ]
  },
  "fact-leak-video": {
   "title": "Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of con",
   "kind": "fact",
   "path": "facts/leak-video/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "3129d7043422",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Calif mistakenly published a video around 20:00 UTC on 20 October showing its proof of concept against a number of targets; copies circulated and 'contributed to accelerated development of various PoCs'\nWho says it: PHP Foundation\nStatus: reported\nTopic: leak\nSources: php-foundation-blog-security-release, phpfoundation-blog-security-release-leak, bbc-live-ckgel5xp2xv9t, calif-php2shell"
    }
   ]
  },
  "fact-leak-mitigations": {
   "title": "Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on",
   "kind": "fact",
   "path": "facts/leak-mitigations/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "99f9ebe62a56",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Mitigation advice given to a few critical-infrastructure providers from about 23:00 UTC on 20 October may have leaked\nWho says it: PHP Foundation\nStatus: reported\nTopic: leak\nSources: php-foundation-blog-security-release"
    }
   ]
  },
  "fact-chainguard": {
   "title": "Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built i",
   "kind": "fact",
   "path": "facts/chainguard/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "94777b2ff7b9",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fix\nWho says it: PHP Foundation\nStatus: disputed\nTopic: leak\nSources: php-foundation-blog-security-release, techzine-php-chainguard"
    },
    {
     "v": 2,
     "hash": "efcb96328d52",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Chainguard unilaterally broke the embargo on 21 October at 07:41 UTC by publishing built images containing the fix\nWho says it: PHP Foundation; Chainguard's CEO accepts the time and denies leaking\nStatus: disputed\nTopic: leak\nSources: php-foundation-blog-security-release, theregister-php-blames-chainguard, x-feross-chainguard"
    }
   ]
  },
  "fact-release-moved": {
   "title": "The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the",
   "kind": "fact",
   "path": "facts/release-moved/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "8357420e3f96",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The release moved forward from 22 October 14:00 UTC to 21 October 14:00 UTC because of the leak\nWho says it: PHP Foundation; php.net pre-announcement; Wiz thread ('Apply the Oct 22 security release')\nStatus: confirmed\nTopic: leak\nSources: php-foundation-blog-security-release, openwall-oss-security-2026-10-20-34, x-wiz-io-php2shell, php-net-changelog-8"
    }
   ]
  },
  "fact-disclosure-22oct": {
   "title": "The flaws were disclosed on 22 October 2026",
   "kind": "fact",
   "path": "facts/disclosure-22oct/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "574cedc7a2e6",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The flaws were disclosed on 22 October 2026\nWho says it: BBC framing (UK morning coverage)\nStatus: contradicted\nTopic: timing\nSources: bbc-live-ckgel5xp2xv9t, php-net-advisory, github-php-src-tag-php-8.5.12"
    }
   ]
  },
  "fact-release-time": {
   "title": "The fixes were released at 14:00 UTC on 21 October",
   "kind": "fact",
   "path": "facts/release-time/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "eaa236fb6f30",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The fixes were released at 14:00 UTC on 21 October\nWho says it: php.net pre-announcement; Daubois; CERT-FR (16:00 Paris)\nStatus: disputed\nTopic: timing\nSources: openwall-oss-security-2026-10-20-34, daubois-blog-php2shell-rumors, certfr-2026-ale-014, certeu-sa-2026-018, github-php-src-tags, github-ghsa-w8hw-w9fx-j79w, github-php-src-tag-php-8.5.12, php-net-advisory"
    }
   ]
  },
  "fact-preannounce-time": {
   "title": "The pre-announcement was published at 19:30 UTC on 20 October",
   "kind": "fact",
   "path": "facts/preannounce-time/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "1efe06eeeeb5",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The pre-announcement was published at 19:30 UTC on 20 October\nWho says it: PHP Foundation\nStatus: disputed\nTopic: timing\nSources: php-foundation-blog-security-release, openwall-oss-security-2026-10-20-34, php-net-advisory"
    }
   ]
  },
  "fact-no-exploitation": {
   "title": "There is no evidence yet that hackers have exploited the flaw",
   "kind": "fact",
   "path": "facts/no-exploitation/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "d77d00fd272c",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "There is no evidence yet that hackers have exploited the flaw\nWho says it: Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October\nStatus: reported\nTopic: exploitation\nSources: bbc-live-ckgel5xp2xv9t"
    }
   ]
  },
  "fact-cisa-none": {
   "title": "CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities ",
   "kind": "fact",
   "path": "facts/cisa-none/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "066f190bb07b",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalog\nWho says it: CISA\nStatus: confirmed\nTopic: exploitation\nSources: cisa-alert-php-20261021, cisa-kev-json, cve-cve-2026-109618"
    }
   ]
  },
  "fact-nz-active": {
   "title": "Reports of active exploitation exist",
   "kind": "fact",
   "path": "facts/nz-active/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "fc1ba26f1d1e",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Reports of active exploitation exist\nWho says it: NCSC New Zealand\nStatus: reported\nTopic: exploitation\nSources: ncsc-nz-alert-php"
    }
   ]
  },
  "fact-amazon-honeypot": {
   "title": "An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; pro",
   "kind": "fact",
   "path": "facts/amazon-honeypot/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "57f2b409c32f",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network, and proof-of-concept attempts started about 02:00 UTC on 21 October\nWho says it: CJ Moses, Amazon, via The Hacker News\nStatus: reported\nTopic: exploitation\nSources: thehackernews-php2shell-4days"
    },
    {
     "v": 2,
     "hash": "84c8a407b41a",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'\nWho says it: Amazon (CJ Moses, AWS Security Blog)\nStatus: reported\nTopic: exploitation\nSources: aws-security-blog-madpot, thehackernews-php2shell-4days"
    }
   ]
  },
  "fact-cloudflare-traffic": {
   "title": "Cloudflare observed attack traffic targeting its customers after the leak, with attackers ",
   "kind": "fact",
   "path": "facts/cloudflare-traffic/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "bf0395197e84",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloads\nWho says it: Cloudflare\nStatus: reported\nTopic: exploitation\nSources: cloudflare-blog-php2shell-waf"
    }
   ]
  },
  "fact-probing": {
   "title": "Amazon and Cloudflare saw sites being probed for the flaw",
   "kind": "fact",
   "path": "facts/probing/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "192922e747b4",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Amazon and Cloudflare saw sites being probed for the flaw\nWho says it: Alan Woodward, via the BBC\nStatus: reported\nTopic: exploitation\nSources: bbc-live-ckgel5xp2xv9t, cloudflare-blog-php2shell-waf, thehackernews-php2shell-4days"
    },
    {
     "v": 2,
     "hash": "943478ded2fe",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Amazon and Cloudflare saw sites being probed for the flaw\nWho says it: Alan Woodward, via the BBC; confirmed by both companies' own posts\nStatus: confirmed\nTopic: exploitation\nSources: bbc-live-ckgel5xp2xv9t, cloudflare-blog-php2shell-waf, aws-security-blog-madpot"
    }
   ]
  },
  "fact-latvia-attempts": {
   "title": "Automated exploitation attempts were seen in Latvia; none succeeded",
   "kind": "fact",
   "path": "facts/latvia-attempts/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "a2fc87d9b9db",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Automated exploitation attempts were seen in Latvia; none succeeded\nWho says it: CERT.LV\nStatus: reported\nTopic: exploitation\nSources: certlv-php-preventive"
    }
   ]
  },
  "fact-vibe-code": {
   "title": "Criminals are using AI to 'vibe code' an attack method",
   "kind": "fact",
   "path": "facts/vibe-code/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "9a9113aa16f0",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Criminals are using AI to 'vibe code' an attack method\nWho says it: unnamed researchers, via the BBC\nStatus: unverified\nTopic: exploitation\nSources: bbc-live-ckgel5xp2xv9t"
    }
   ]
  },
  "fact-offline-nsa": {
   "title": "If an immediate update is not feasible, take the system offline until it can be fully miti",
   "kind": "fact",
   "path": "facts/offline-nsa/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "b20163c138b1",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "If an immediate update is not feasible, take the system offline until it can be fully mitigated\nWho says it: NSA Cybersecurity\nStatus: confirmed\nTopic: advice\nSources: nsa-x-2112903220209098897, nsa-press-php-4630238"
    }
   ]
  },
  "fact-offline-cisa": {
   "title": "Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PH",
   "kind": "fact",
   "path": "facts/offline-cisa/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "5a2ee901d4d7",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline\nWho says it: CISA\nStatus: confirmed\nTopic: advice\nSources: cisa-alert-php-20261021"
    }
   ]
  },
  "fact-offline-ncsc": {
   "title": "'Where immediate remediation is not feasible, organisations should consider taking the sys",
   "kind": "fact",
   "path": "facts/offline-ncsc/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "4e28584c9e6c",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'\nWho says it: UK NCSC, as quoted by the BBC\nStatus: disputed\nTopic: advice\nSources: bbc-live-ckgel5xp2xv9t, ncsc-news-php, cccs-al26-026"
    }
   ]
  },
  "fact-offline-allies": {
   "title": "The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking system",
   "kind": "fact",
   "path": "facts/offline-allies/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "201ef2c3ac6e",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasible\nWho says it: BBC\nStatus: contradicted\nTopic: advice\nSources: bbc-live-ckgel5xp2xv9t, acsc-alert-php, certeu-sa-2026-018, ncsc-nl-php2shell, acn-it-php2shell, jpcert-at260033"
    }
   ]
  },
  "fact-affected-sites": {
   "title": "Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, ",
   "kind": "fact",
   "path": "facts/affected-sites/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "4d8b9095660c",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offline\nWho says it: BBC\nStatus: reported\nTopic: impact\nSources: bbc-live-ckgel5xp2xv9t"
    }
   ]
  },
  "fact-latvia-offline": {
   "title": "Latvia restricted access from abroad to several state digital resources, possibly until 26",
   "kind": "fact",
   "path": "facts/latvia-offline/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "e8983e830ac0",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTC\nWho says it: CERT.LV\nStatus: confirmed\nTopic: impact\nSources: certlv-php-preventive"
    }
   ]
  },
  "fact-gov-patch-required": {
   "title": "The risks require immediate patching across United States Government departments and agenc",
   "kind": "fact",
   "path": "facts/gov-patch-required/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "f2b85d866aa7",
     "site": "0.1.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The risks require immediate patching across United States Government departments and agencies\nWho says it: NSA\nStatus: reported\nTopic: advice\nSources: nsa-press-php-4630238, cisa-home"
    }
   ]
  },
  "page-code": {
   "title": "The code",
   "kind": "page",
   "path": "code/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "8ee398496a38",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The code: where php2shell lives and what the fix does\n\nRead 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.\n\n# The code: where the bug is, and what the fix does\n\nThe editor's question was where the flaw actually lives: in PHP, in C, in the engine? The answer, read from the repository rather than from any article, is the Zend engine's memory manager and request lifecycle, in C, below every PHP application. This page is built from a clone of php/php-src: the fix commit, its parent, the branch it landed on, the end-of-life backport, and the diff between the last vulnerable and first fixed release. The patches and the commit metadata are in the vault with their hashes. php/php-src , read from a clone PHP PHP php.net php-src php.net Daubois Fastly Imperva Threat Research OpenAI / Wiz / Calif joint microsi OpenAI on X\n\n## The fix commit\n\n`3584a98bda0f2c0d367255b046798b0d3a221a19`, **Avoid state corruption via bailout**, by Arnaud Le Blanc with Ilija Tovilo, Jakub Zelenka (bukka), Nora Dossche, Nicolas Grekas. Authored **2026-10-18 15:26:39 UTC**; committed to the public branch **2026-10-21 14:06:22 UTC**, six minutes after the planned release time. Parent `512c04e39f67`. The commit message, in full:\n- Replace bailout on OOM with UnwindExit\n- Properly reset various globals that may be accessed during startup\n- Fix GHSA-w8hw-w9fx-j79w (CVE-2026-109618)\n- Fix GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)\n\n389 files changed, 10,689 insertions, 976 deletions; 113 of the files are not tests.\n\n| Area | Files in the fix |\n|---|---|\n| Zend/ (the engine) | 96 |\n| ext/standard | 52 |\n| tests/ | 34 |\n| ext/mbstring | 30 |\n| ext/gd | 19 |\n| ext/date | 17 |\n| ext/soap | 14 |\n| ext/zlib | 11 |\n| ext/session | 5 |\n| main/ (request lifecycle, input parsing) | 7 |\n| sapi/ | 5 |\n\nTiming, from the commit and merge timestamps:\n\n| When (UTC) | What |\n|---|---|\n| 2026-10-21 14:06:22 UTC | commit date: the fix enters the public PHP-8.2 branch (committer time; author time is 18 October 15:26 UTC) |\n| 2026-10-21 14:12:35 UTC | Ilija Tovilo merges PHP-8.2 into PHP-8.3 |\n| 2026-10-21 14:27:03 UTC | merges PHP-8.3 into PHP-8.4 |\n| 2026-10-21 14:30:04 UTC | merges PHP-8.4 into PHP-8.5 |\n| 2026-10-21 15:34:31 UTC | NEWS entry added (author time 18 October) |\n\n## Where the bug is\n- **The language a site is written in (PHP code)** ✗ not where the bug is: Not where the bug is. A site's own PHP code can be perfect; php2shell.com's phrase is that a 'Hello World' application on an affected version is affected.\n- **The Zend engine (C): memory manager, request start-up and shutdown** ✓ in scope: Where both bugs are. Zend/zend_alloc.c is PHP's allocator; main/main.c runs a request's start-up and shutdown; main/rfc1867.c parses multipart bodies; main/php_variables.c registers $_GET, $_POST and friends; ext/session/session.c hooks the multipart parser for upload progress. All C.\n- **The SAPI (how PHP is attached to the web server)** ✓ in scope: Where exploitability differs. mod_php runs request shutdown even when start-up failed, 'before any application-specific code begins execution'; FPM is susceptible by source analysis; the fix touches sapi/ in five files.\n- **The web server, the WAF, the operating system** ✗ not where the bug is: Not where the bug is, but where the controls are: a WAF matches the request shape, the OS limits what the worker can do once it is code execution.\n\n## What the fix does, step by step\n\nThe site's reading of the diff, checked against the two GitHub advisories. Each step names the function or file it comes from; the hunks below are verbatim.\n- **Before the fix.** When a request pushed PHP past memory_limit, the allocator called zend_mm_safe_error, which raised a fatal error inside a zend_try and then called zend_bailout(): a C longjmp back to the request's top-level handler. The jump abandons whatever function was half-way through building request state. On mod_php the request shutdown then runs anyway and reads that half-built state. That is CVE-2026-109618, 'RCE via OOM corruption'. The same longjmp, or any fatal error, could leave global state pointing into request memory that is about to be freed; the next request on the same worker reads it. That is CVE-2026-109619, 'RCE via stale global state'.\n- **The attacker's lever.** The attacker needs to make the allocator fail at a moment of their choosing. The confirmed ways are request-shaped: a multipart body with many parts or long headers (rfc1867.c), deeply nested form field names (php_variables.c and the hash table), and the session upload-progress feature, which is on by default and does work inside the multipart parser before the application runs. Several vendors say the exploit also needs to know the running binary's layout on x86_64, which is why the CVSS vector says attack complexity high.\n- **After the fix: the soft limit.** zend_mm_check_limit no longer jumps. If an allocation would exceed memory_limit (now the soft limit), it queues a 'delayed OOM' error and lets the allocation succeed. At the next VM safe point zend_handle_delayed_oom runs, throws an UnwindExit that unwinds the PHP frames in an orderly way, and raises the fatal error with the request's state intact. The commit's own comment: 'When the soft limit is to be exceeded, a delayed OOM error is queued. When the hard limit is to be exceeded, the function does not return.'\n- **After the fix: the hard limit.** A new memory_hard_limit_percent setting defines a ceiling above memory_limit. Reaching it calls zend_mm_hard_limit_error and the process ends with _exit(), with no cleanup to corrupt. Allocations that callers can tolerate failing become 'fallible' and return NULL instead of jumping. zend_mm_panic now also uses _exit rather than exit.\n- **After the fix: the globals.** shutdown_executor, php_request_shutdown and sapi_deactivate set the pointers they free to NULL or UNDEF ('may be accessed before php_request_startup()'), so a later request cannot find stale state. A new max_multipart_body_parts setting bounds the number of parts the parser will accept; the multipart header parser keeps only Content-Disposition and Content-Type and ignores duplicates; the session upload-progress callback is changed.\n- **Why it touched 389 files.** Every place in the engine and the bundled extensions that used to say 'allocation failed, bail out' had to be rewritten to the new contract: queue the error, fail the allocation, or hit the hard limit. That is why ext/standard, mbstring, gd, date and soap are in the diff, and why the PHP Foundation says the fix 'required a major change to the PHP engine' and took two months.\n- **The 7.4 branch.** The end-of-life backport is a different, smaller change (17 engine files): it makes every memory error exit the process immediately (zend_mm_safe_error_ex calling _exit) instead of unwinding, resets the same globals, caps multipart parts and disables the session upload-progress callback outright. It is labelled 'Minimal mitigation for EOL version' in the commit. A worker that _exits on every OOM is safe from this bug class and worse at availability.\n\n## The hunks that matter\n\n/* Zend/zend_alloc.c, the fix: the allocator no longer jumps */ static zend_always_inline zend_result zend_mm_check_limit(zend_mm_heap *heap, size_t add_size, bool gc, bool *did_gc ...) { /* Is the soft limit exceeded or going to be exceeded? */ if (UNEXPECTED(heap->limit real_size || add_size > heap->limit - heap->real_size)) { if (gc && zend_mm_gc(heap)) { ... } if (!heap->fallible && add_size > heap->hard_limit - heap->real_size) { zend_mm_hard_limit_error(heap, add_size ...); /* does not return: _exit() */ } if (!gc || (heap->limit real_size || add_size > heap->limit - heap->real_size)) { if (!ZEND_HAS_OOM()) { zend_mm_delayed_error(\"Allowed memory size of %zu bytes exhausted (tried to allocate %zu bytes)\", ...); } return heap->fallible ? FAILURE : SUCCESS; /* the allocation goes ahead, or fails cleanly */ } } return SUCCESS; } /* and what used to be there (the 7.4 branch shows the old shape being replaced) */ - heap->overflow = 1; - zend_try { - zend_error_noreturn(E_ERROR, format, limit, ... size); - } zend_catch { - } zend_end_try(); - heap->overflow = 0; - zend_bailout(); /* longjmp out of the allocation */ - exit(1); /* Zend/zend_execute_API.c: the delayed error is handled at a safe point */ ZEND_API void ZEND_FASTCALL zend_handle_delayed_oom(void) { ... if (execute_data) { EG(exception) = NULL; /* Object allocation should succeed unless it trips the hard limit */ zend_throw_unwind_exit(); /* unwind PHP frames in order */ } zend_try { zend_error_zstr_at(E_ERROR, info->filename, info->lineno, info->message); } zend_catch { } zend_end_try(); ... /* No userland frame to unwind: ... Let it propagate and abort the request, the way an immediate OOM does. */ if (!execute_data) { zend_bailout(); } } /* main/main.c: two settings that did not exist before */ + PHP_INI_ENTRY(\"max_multipart_body_parts\", \"-1\", PHP_INI_SYSTEM|PHP_INI_PERDIR, NULL) + PHP_INI_ENTRY(\"memory_hard_limit_percent\", NULL, PHP_INI_ALL, OnChangeMemoryHardLimitPercent) /* main/main.c: the stale-state class, in one line */ for (i=0; i\n\n## The end-of-life backport, and how it differs\n\nBranch `PHP-7.4-CVE-2026-109618-109619`, commit `712e60f9e`, same title, same author, authored 2026-10-18 18:09:54 UTC. The commit says *Minimal mitigation for EOL version.*. 17 files: `Zend/zend_alloc.c (+68)`, `Zend/zend_execute_API.c (+13)`, `Zend/zend_hash.c (+13)`, `Zend/zend_types.h (26)`, `Zend/zend_vm_def.h (+11)`, `main/rfc1867.c (+39)`, `main/php_variables.c (8)`, `main/main.c (+6)`, `main/SAPI.c (+5)`, `ext/session/session.c (2)`, `Zend/zend_API.h, zend_alloc.h, zend_hash.h, zend_llist.c, zend_multiply.h, zend_strtod.c, zend_vm_execute.h`. Instead of the delayed error and the unwind, every memory error calls a new `zend_mm_safe_error_ex` that prints the fatal and `_exit`s the process; the same globals are reset; a `max_multipart_body_parts` cap is added; the multipart header parser keeps only the two headers it uses; and the session upload-progress callback is disabled with a one-line `|| true`. A worker that dies on every out-of-memory cannot be exploited this way and will be worse at staying up.\n\n## What the code does not tell us\n- Which of the 389 files are the security fix and which are the refactor the fix needed is not separable from the diff alone; the GHSA text and the commit body are the only guide.\n- The 2024 trail: the Foundation says a core developer saw the first signs of the OOM problem while fixing a 2024 audit finding. That developer, that fix and that issue are not named in any captured source, and this site's shallow clone does not reach 2024 history.\n- Whether the Fediverse report of an incomplete fix in 8.5.12 concerns one of these paths.\n\nHow the bug is reached from a request is on the two flaws; what to watch for on a host is on detection and defence."
    },
    {
     "v": 2,
     "hash": "cfc2713d6fbc",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The code: where php2shell lives and what the fix does\n\nRead 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.\n\n# The code: where the bug is, and what the fix does\n\nIn plain English Where exactly the bug sits in PHP's own source code, and what the fix changed. Technical; the short version is that PHP used to abandon work mid-way when memory ran out, and now it stops safely.\n\nThe editor's question was where the flaw actually lives: in PHP, in C, in the engine? The answer, read from the repository rather than from any article, is the Zend engine's memory manager and request lifecycle, in C, below every PHP application. This page is built from a clone of php/php-src: the fix commit, its parent, the branch it landed on, the end-of-life backport, and the diff between the last vulnerable and first fixed release. The patches and the commit metadata are in the vault with their hashes. php/php-src , read from a clone PHP PHP php.net php-src php.net Daubois Fastly Imperva Threat Research OpenAI / Wiz / Calif joint microsi OpenAI on X\n\n## The fix commit\n\n`3584a98bda0f2c0d367255b046798b0d3a221a19`, **Avoid state corruption via bailout**, by Arnaud Le Blanc with Ilija Tovilo, Jakub Zelenka (bukka), Nora Dossche, Nicolas Grekas. Authored **2026-10-18 15:26:39 UTC**; committed to the public branch **2026-10-21 14:06:22 UTC**, six minutes after the planned release time. Parent `512c04e39f67`. The commit message, in full:\n- Replace bailout on OOM with UnwindExit\n- Properly reset various globals that may be accessed during startup\n- Fix GHSA-w8hw-w9fx-j79w (CVE-2026-109618)\n- Fix GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)\n\n389 files changed, 10,689 insertions, 976 deletions; 113 of the files are not tests.\n\n| Area | Files in the fix |\n|---|---|\n| Zend/ (the engine) | 96 |\n| ext/standard | 52 |\n| tests/ | 34 |\n| ext/mbstring | 30 |\n| ext/gd | 19 |\n| ext/date | 17 |\n| ext/soap | 14 |\n| ext/zlib | 11 |\n| ext/session | 5 |\n| main/ (request lifecycle, input parsing) | 7 |\n| sapi/ | 5 |\n\nTiming, from the commit and merge timestamps:\n\n| When (UTC) | What |\n|---|---|\n| 2026-10-21 14:06:22 UTC | commit date: the fix enters the public PHP-8.2 branch (committer time; author time is 18 October 15:26 UTC) |\n| 2026-10-21 14:12:35 UTC | Ilija Tovilo merges PHP-8.2 into PHP-8.3 |\n| 2026-10-21 14:27:03 UTC | merges PHP-8.3 into PHP-8.4 |\n| 2026-10-21 14:30:04 UTC | merges PHP-8.4 into PHP-8.5 |\n| 2026-10-21 15:34:31 UTC | NEWS entry added (author time 18 October) |\n\n## Where the bug is\n- **The language a site is written in (PHP code)** ✗ not where the bug is: Not where the bug is. A site's own PHP code can be perfect; php2shell.com's phrase is that a 'Hello World' application on an affected version is affected.\n- **The Zend engine (C): memory manager, request start-up and shutdown** ✓ in scope: Where both bugs are. Zend/zend_alloc.c is PHP's allocator; main/main.c runs a request's start-up and shutdown; main/rfc1867.c parses multipart bodies; main/php_variables.c registers $_GET, $_POST and friends; ext/session/session.c hooks the multipart parser for upload progress. All C.\n- **The SAPI (how PHP is attached to the web server)** ✓ in scope: Where exploitability differs. mod_php runs request shutdown even when start-up failed, 'before any application-specific code begins execution'; FPM is susceptible by source analysis; the fix touches sapi/ in five files.\n- **The web server, the WAF, the operating system** ✗ not where the bug is: Not where the bug is, but where the controls are: a WAF matches the request shape, the OS limits what the worker can do once it is code execution.\n\n## What the fix does, step by step\n\nThe site's reading of the diff, checked against the two GitHub advisories. Each step names the function or file it comes from; the hunks below are verbatim.\n- **Before the fix.** When a request pushed PHP past memory_limit, the allocator called zend_mm_safe_error, which raised a fatal error inside a zend_try and then called zend_bailout(): a C longjmp back to the request's top-level handler. The jump abandons whatever function was half-way through building request state. On mod_php the request shutdown then runs anyway and reads that half-built state. That is CVE-2026-109618, 'RCE via OOM corruption'. The same longjmp, or any fatal error, could leave global state pointing into request memory that is about to be freed; the next request on the same worker reads it. That is CVE-2026-109619, 'RCE via stale global state'.\n- **The attacker's lever.** The attacker needs to make the allocator fail at a moment of their choosing. The confirmed ways are request-shaped: a multipart body with many parts or long headers (rfc1867.c), deeply nested form field names (php_variables.c and the hash table), and the session upload-progress feature, which is on by default and does work inside the multipart parser before the application runs. Several vendors say the exploit also needs to know the running binary's layout on x86_64, which is why the CVSS vector says attack complexity high.\n- **After the fix: the soft limit.** zend_mm_check_limit no longer jumps. If an allocation would exceed memory_limit (now the soft limit), it queues a 'delayed OOM' error and lets the allocation succeed. At the next VM safe point zend_handle_delayed_oom runs, throws an UnwindExit that unwinds the PHP frames in an orderly way, and raises the fatal error with the request's state intact. The commit's own comment: 'When the soft limit is to be exceeded, a delayed OOM error is queued. When the hard limit is to be exceeded, the function does not return.'\n- **After the fix: the hard limit.** A new memory_hard_limit_percent setting defines a ceiling above memory_limit. Reaching it calls zend_mm_hard_limit_error and the process ends with _exit(), with no cleanup to corrupt. Allocations that callers can tolerate failing become 'fallible' and return NULL instead of jumping. zend_mm_panic now also uses _exit rather than exit.\n- **After the fix: the globals.** shutdown_executor, php_request_shutdown and sapi_deactivate set the pointers they free to NULL or UNDEF ('may be accessed before php_request_startup()'), so a later request cannot find stale state. A new max_multipart_body_parts setting bounds the number of parts the parser will accept; the multipart header parser keeps only Content-Disposition and Content-Type and ignores duplicates; the session upload-progress callback is changed.\n- **Why it touched 389 files.** Every place in the engine and the bundled extensions that used to say 'allocation failed, bail out' had to be rewritten to the new contract: queue the error, fail the allocation, or hit the hard limit. That is why ext/standard, mbstring, gd, date and soap are in the diff, and why the PHP Foundation says the fix 'required a major change to the PHP engine' and took two months.\n- **The 7.4 branch.** The end-of-life backport is a different, smaller change (17 engine files): it makes every memory error exit the process immediately (zend_mm_safe_error_ex calling _exit) instead of unwinding, resets the same globals, caps multipart parts and disables the session upload-progress callback outright. It is labelled 'Minimal mitigation for EOL version' in the commit. A worker that _exits on every OOM is safe from this bug class and worse at availability.\n\n## The hunks that matter\n\n/* Zend/zend_alloc.c, the fix: the allocator no longer jumps */ static zend_always_inline zend_result zend_mm_check_limit(zend_mm_heap *heap, size_t add_size, bool gc, bool *did_gc ...) { /* Is the soft limit exceeded or going to be exceeded? */ if (UNEXPECTED(heap->limit real_size || add_size > heap->limit - heap->real_size)) { if (gc && zend_mm_gc(heap)) { ... } if (!heap->fallible && add_size > heap->hard_limit - heap->real_size) { zend_mm_hard_limit_error(heap, add_size ...); /* does not return: _exit() */ } if (!gc || (heap->limit real_size || add_size > heap->limit - heap->real_size)) { if (!ZEND_HAS_OOM()) { zend_mm_delayed_error(\"Allowed memory size of %zu bytes exhausted (tried to allocate %zu bytes)\", ...); } return heap->fallible ? FAILURE : SUCCESS; /* the allocation goes ahead, or fails cleanly */ } } return SUCCESS; } /* and what used to be there (the 7.4 branch shows the old shape being replaced) */ - heap->overflow = 1; - zend_try { - zend_error_noreturn(E_ERROR, format, limit, ... size); - } zend_catch { - } zend_end_try(); - heap->overflow = 0; - zend_bailout(); /* longjmp out of the allocation */ - exit(1); /* Zend/zend_execute_API.c: the delayed error is handled at a safe point */ ZEND_API void ZEND_FASTCALL zend_handle_delayed_oom(void) { ... if (execute_data) { EG(exception) = NULL; /* Object allocation should succeed unless it trips the hard limit */ zend_throw_unwind_exit(); /* unwind PHP frames in order */ } zend_try { zend_error_zstr_at(E_ERROR, info->filename, info->lineno, info->message); } zend_catch { } zend_end_try(); ... /* No userland frame to unwind: ... Let it propagate and abort the request, the way an immediate OOM does. */ if (!execute_data) { zend_bailout(); } } /* main/main.c: two settings that did not exist before */ + PHP_INI_ENTRY(\"max_multipart_body_parts\", \"-1\", PHP_INI_SYSTEM|PHP_INI_PERDIR, NULL) + PHP_INI_ENTRY(\"memory_hard_limit_percent\", NULL, PHP_INI_ALL, OnChangeMemoryHardLimitPercent) /* main/main.c: the stale-state class, in one line */ for (i=0; i\n\n## The end-of-life backport, and how it differs\n\nBranch `PHP-7.4-CVE-2026-109618-109619`, commit `712e60f9e`, same title, same author, authored 2026-10-18 18:09:54 UTC. The commit says *Minimal mitigation for EOL version.*. 17 files: `Zend/zend_alloc.c (+68)`, `Zend/zend_execute_API.c (+13)`, `Zend/zend_hash.c (+13)`, `Zend/zend_types.h (26)`, `Zend/zend_vm_def.h (+11)`, `main/rfc1867.c (+39)`, `main/php_variables.c (8)`, `main/main.c (+6)`, `main/SAPI.c (+5)`, `ext/session/session.c (2)`, `Zend/zend_API.h, zend_alloc.h, zend_hash.h, zend_llist.c, zend_multiply.h, zend_strtod.c, zend_vm_execute.h`. Instead of the delayed error and the unwind, every memory error calls a new `zend_mm_safe_error_ex` that prints the fatal and `_exit`s the process; the same globals are reset; a `max_multipart_body_parts` cap is added; the multipart header parser keeps only the two headers it uses; and the session upload-progress callback is disabled with a one-line `|| true`. A worker that dies on every out-of-memory cannot be exploited this way and will be worse at staying up.\n\n## What the code does not tell us\n- Which of the 389 files are the security fix and which are the refactor the fix needed is not separable from the diff alone; the GHSA text and the commit body are the only guide.\n- The 2024 trail: the Foundation says a core developer saw the first signs of the OOM problem while fixing a 2024 audit finding. That developer, that fix and that issue are not named in any captured source, and this site's shallow clone does not reach 2024 history.\n- Whether the Fediverse report of an incomplete fix in 8.5.12 concerns one of these paths.\n\nHow the bug is reached from a request is on the two flaws; what to watch for on a host is on detection and defence."
    },
    {
     "v": 3,
     "hash": "4437c0eba1fb",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The code: where php2shell lives and what the fix does\n\nRead 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.\n\n# The code: where the bug is, and what the fix does\n\nIn plain English Where exactly the bug sits in PHP's own source code, and what the fix changed. Technical; the short version is that PHP used to abandon work mid-way when memory ran out, and now it stops safely.\n\nThe editor's question was where the flaw actually lives: in PHP, in C, in the engine? The answer, read from the repository rather than from any article, is the Zend engine's memory manager and request lifecycle, in C, below every PHP application. This page is built from a clone of php/php-src: the fix commit, its parent, the branch it landed on, the end-of-life backport, and the diff between the last vulnerable and first fixed release. The patches and the commit metadata are in the vault with their hashes. php/php-src, read from a clone PHP PHP php.net php-src php.net Daubois Fastly Imperva Threat Research OpenAI / Wiz / Calif joint… OpenAI on X\n\n## The fix commit\n\n`3584a98bda0f2c0d367255b046798b0d3a221a19`, **Avoid state corruption via bailout**, by Arnaud Le Blanc with Ilija Tovilo, Jakub Zelenka (bukka), Nora Dossche, Nicolas Grekas. Authored **2026-10-18 15:26:39 UTC**; committed to the public branch **2026-10-21 14:06:22 UTC**, six minutes after the planned release time. Parent `512c04e39f67`. The commit message, in full:\n- Replace bailout on OOM with UnwindExit\n- Properly reset various globals that may be accessed during startup\n- Fix GHSA-w8hw-w9fx-j79w (CVE-2026-109618)\n- Fix GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)\n\n389 files changed, 10,689 insertions, 976 deletions; 113 of the files are not tests.\n\n| Area | Files in the fix |\n|---|---|\n| Zend/ (the engine) | 96 |\n| ext/standard | 52 |\n| tests/ | 34 |\n| ext/mbstring | 30 |\n| ext/gd | 19 |\n| ext/date | 17 |\n| ext/soap | 14 |\n| ext/zlib | 11 |\n| ext/session | 5 |\n| main/ (request lifecycle, input parsing) | 7 |\n| sapi/ | 5 |\n\nTiming, from the commit and merge timestamps:\n\n| When (UTC) | What |\n|---|---|\n| 2026-10-21 14:06:22 UTC | commit date: the fix enters the public PHP-8.2 branch (committer time; author time is 18 October 15:26 UTC) |\n| 2026-10-21 14:12:35 UTC | Ilija Tovilo merges PHP-8.2 into PHP-8.3 |\n| 2026-10-21 14:27:03 UTC | merges PHP-8.3 into PHP-8.4 |\n| 2026-10-21 14:30:04 UTC | merges PHP-8.4 into PHP-8.5 |\n| 2026-10-21 15:34:31 UTC | NEWS entry added (author time 18 October) |\n\n## Where the bug is\n- **The language a site is written in (PHP code)** ✗ not where the bug is: Not where the bug is. A site's own PHP code can be perfect; php2shell.com's phrase is that a 'Hello World' application on an affected version is affected.\n- **The Zend engine (C): memory manager, request start-up and shutdown** ✓ in scope: Where both bugs are. Zend/zend_alloc.c is PHP's allocator; main/main.c runs a request's start-up and shutdown; main/rfc1867.c parses multipart bodies; main/php_variables.c registers $_GET, $_POST and friends; ext/session/session.c hooks the multipart parser for upload progress. All C.\n- **The SAPI (how PHP is attached to the web server)** ✓ in scope: Where exploitability differs. mod_php runs request shutdown even when start-up failed, 'before any application-specific code begins execution'; FPM is susceptible by source analysis; the fix touches sapi/ in five files.\n- **The web server, the WAF, the operating system** ✗ not where the bug is: Not where the bug is, but where the controls are: a WAF matches the request shape, the OS limits what the worker can do once it is code execution.\n\n## What the fix does, step by step\n\nThe site's reading of the diff, checked against the two GitHub advisories. Each step names the function or file it comes from; the hunks below are verbatim.\n- **Before the fix.** When a request pushed PHP past memory_limit, the allocator called zend_mm_safe_error, which raised a fatal error inside a zend_try and then called zend_bailout(): a C longjmp back to the request's top-level handler. The jump abandons whatever function was half-way through building request state. On mod_php the request shutdown then runs anyway and reads that half-built state. That is CVE-2026-109618, 'RCE via OOM corruption'. The same longjmp, or any fatal error, could leave global state pointing into request memory that is about to be freed; the next request on the same worker reads it. That is CVE-2026-109619, 'RCE via stale global state'.\n- **The attacker's lever.** The attacker needs to make the allocator fail at a moment of their choosing. The confirmed ways are request-shaped: a multipart body with many parts or long headers (rfc1867.c), deeply nested form field names (php_variables.c and the hash table), and the session upload-progress feature, which is on by default and does work inside the multipart parser before the application runs. Several vendors say the exploit also needs to know the running binary's layout on x86_64, which is why the CVSS vector says attack complexity high.\n- **After the fix: the soft limit.** zend_mm_check_limit no longer jumps. If an allocation would exceed memory_limit (now the soft limit), it queues a 'delayed OOM' error and lets the allocation succeed. At the next VM safe point zend_handle_delayed_oom runs, throws an UnwindExit that unwinds the PHP frames in an orderly way, and raises the fatal error with the request's state intact. The commit's own comment: 'When the soft limit is to be exceeded, a delayed OOM error is queued. When the hard limit is to be exceeded, the function does not return.'\n- **After the fix: the hard limit.** A new memory_hard_limit_percent setting defines a ceiling above memory_limit. Reaching it calls zend_mm_hard_limit_error and the process ends with _exit(), with no cleanup to corrupt. Allocations that callers can tolerate failing become 'fallible' and return NULL instead of jumping. zend_mm_panic now also uses _exit rather than exit.\n- **After the fix: the globals.** shutdown_executor, php_request_shutdown and sapi_deactivate set the pointers they free to NULL or UNDEF ('may be accessed before php_request_startup()'), so a later request cannot find stale state. A new max_multipart_body_parts setting bounds the number of parts the parser will accept; the multipart header parser keeps only Content-Disposition and Content-Type and ignores duplicates; the session upload-progress callback is changed.\n- **Why it touched 389 files.** Every place in the engine and the bundled extensions that used to say 'allocation failed, bail out' had to be rewritten to the new contract: queue the error, fail the allocation, or hit the hard limit. That is why ext/standard, mbstring, gd, date and soap are in the diff, and why the PHP Foundation says the fix 'required a major change to the PHP engine' and took two months.\n- **The 7.4 branch.** The end-of-life backport is a different, smaller change (17 engine files): it makes every memory error exit the process immediately (zend_mm_safe_error_ex calling _exit) instead of unwinding, resets the same globals, caps multipart parts and disables the session upload-progress callback outright. It is labelled 'Minimal mitigation for EOL version' in the commit. A worker that _exits on every OOM is safe from this bug class and worse at availability.\n\n## The hunks that matter\n\n/* Zend/zend_alloc.c, the fix: the allocator no longer jumps */ static zend_always_inline zend_result zend_mm_check_limit(zend_mm_heap *heap, size_t add_size, bool gc, bool *did_gc ...) { /* Is the soft limit exceeded or going to be exceeded? */ if (UNEXPECTED(heap->limit real_size || add_size > heap->limit - heap->real_size)) { if (gc && zend_mm_gc(heap)) { ... } if (!heap->fallible && add_size > heap->hard_limit - heap->real_size) { zend_mm_hard_limit_error(heap, add_size ...); /* does not return: _exit() */ } if (!gc || (heap->limit real_size || add_size > heap->limit - heap->real_size)) { if (!ZEND_HAS_OOM()) { zend_mm_delayed_error(\"Allowed memory size of %zu bytes exhausted (tried to allocate %zu bytes)\", ...); } return heap->fallible ? FAILURE : SUCCESS; /* the allocation goes ahead, or fails cleanly */ } } return SUCCESS; } /* and what used to be there (the 7.4 branch shows the old shape being replaced) */ - heap->overflow = 1; - zend_try { - zend_error_noreturn(E_ERROR, format, limit, ... size); - } zend_catch { - } zend_end_try(); - heap->overflow = 0; - zend_bailout(); /* longjmp out of the allocation */ - exit(1); /* Zend/zend_execute_API.c: the delayed error is handled at a safe point */ ZEND_API void ZEND_FASTCALL zend_handle_delayed_oom(void) { ... if (execute_data) { EG(exception) = NULL; /* Object allocation should succeed unless it trips the hard limit */ zend_throw_unwind_exit(); /* unwind PHP frames in order */ } zend_try { zend_error_zstr_at(E_ERROR, info->filename, info->lineno, info->message); } zend_catch { } zend_end_try(); ... /* No userland frame to unwind: ... Let it propagate and abort the request, the way an immediate OOM does. */ if (!execute_data) { zend_bailout(); } } /* main/main.c: two settings that did not exist before */ + PHP_INI_ENTRY(\"max_multipart_body_parts\", \"-1\", PHP_INI_SYSTEM|PHP_INI_PERDIR, NULL) + PHP_INI_ENTRY(\"memory_hard_limit_percent\", NULL, PHP_INI_ALL, OnChangeMemoryHardLimitPercent) /* main/main.c: the stale-state class, in one line */ for (i=0; i\n\n## The end-of-life backport, and how it differs\n\nBranch `PHP-7.4-CVE-2026-109618-109619`, commit `712e60f9e`, same title, same author, authored 2026-10-18 18:09:54 UTC. The commit says *Minimal mitigation for EOL version.*. 17 files: `Zend/zend_alloc.c (+68)`, `Zend/zend_execute_API.c (+13)`, `Zend/zend_hash.c (+13)`, `Zend/zend_types.h (26)`, `Zend/zend_vm_def.h (+11)`, `main/rfc1867.c (+39)`, `main/php_variables.c (8)`, `main/main.c (+6)`, `main/SAPI.c (+5)`, `ext/session/session.c (2)`, `Zend/zend_API.h, zend_alloc.h, zend_hash.h, zend_llist.c, zend_multiply.h, zend_strtod.c, zend_vm_execute.h`. Instead of the delayed error and the unwind, every memory error calls a new `zend_mm_safe_error_ex` that prints the fatal and `_exit`s the process; the same globals are reset; a `max_multipart_body_parts` cap is added; the multipart header parser keeps only the two headers it uses; and the session upload-progress callback is disabled with a one-line `|| true`. A worker that dies on every out-of-memory cannot be exploited this way and will be worse at staying up.\n\n## What the code does not tell us\n- Which of the 389 files are the security fix and which are the refactor the fix needed is not separable from the diff alone; the GHSA text and the commit body are the only guide.\n- The 2024 trail: the Foundation says a core developer saw the first signs of the OOM problem while fixing a 2024 audit finding. That developer, that fix and that issue are not named in any captured source, and this site's shallow clone does not reach 2024 history.\n- Whether the Fediverse report of an incomplete fix in 8.5.12 concerns one of these paths.\n\nHow the bug is reached from a request is on the two flaws; what to watch for on a host is on detection and defence."
    }
   ]
  },
  "page-impact": {
   "title": "Impact: offline vs compromised",
   "kind": "page",
   "path": "impact/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "5bc1d9f9e5eb",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Impact: taken offline versus compromised\n\nTwo 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.\n\n# Impact: what was taken offline, and what was compromised\n\nTwo ledgers, because they measure different things. Taking a system offline is a decision an operator makes and can confirm, and the first table is full. Being compromised is a fact only evidence establishes, and the second table has, as of the latest capture, no confirmed entry. That gap is the most important finding on this site: the reported cost of php2shell so far is the cost of precaution.\n\nTwo ledgers. The first is systems taken offline, which is a decision an operator makes and can confirm; the second is systems compromised, which only evidence can establish. The columns say whether the entry comes from the organisation itself or from the press, because the difference is the whole point.\n\n## Taken offline\n\n| Who | What happened | When | Who says so | Status | Sources |\n|---|---|---|---|---|---|\n| **NCSC.nl (the Dutch national cyber security centre's own site)** NL | Taken offline 'uit voorzorg' (as a precaution); DigiD, MijnOverheid and Overheid.nl also offline; no signs of active exploitation of those services at the time | 2026-10-21 | the Dutch government (Rijksoverheid news) | confirmed | Rijksoverheid / NCSC-NL Dutch IT Leaders TPO.nl |\n| **Finland's government public web services (Valtori)** FI | Incoming public traffic restricted from 12:45 local (09:45 UTC); described as preventive, not a response to a breach; internal networks unaffected | 2026-10-21 09:45 UTC | Yle and Helsinki Times quoting Valtori and the National Cyber Security Centre Finland | reported | Yle Helsinki Times |\n| **Latvia: several state digital resources, lsm.lv, 112.lv** LV | Access restricted from abroad; state website platform patched by 20:00 UTC; lsm.lv and 112.lv restored; restrictions on others possibly until 26 October | 2026-10-21 15:25 UTC | CERT.LV itself | confirmed | CERT.LV |\n| **Wikimedia Foundation: 'a number of other systems'** US | 'taken down a number of other systems as a precautionary measure until they can be safely patched'; parts of Wikipedia affected | 2026-10-21 | the Foundation, as quoted by CNN and The Cyber Express; the BBC | reported | CNN The Cyber Express BBC News |\n| **Weird Gloop (RuneScape and other game wikis, about 500 million page views a month)** UK | Web servers off for 13 hours, 'the longest outage we've ever had'; about 94% of page views still served from cache | 2026-10-21 | Weird Gloop itself | confirmed | Weird Gloop |\n| **City of Edinburgh Council** UK | Website offline from late Wednesday afternoon; the council says 'essential maintenance' and is 'waiting on an update from our provider'; it has not confirmed a link | 2026-10-21 | The Scotsman quoting a council spokesperson | reported | The Scotsman |\n| **Oxford City Council and Oxfordshire County Council** UK | Sites removed from service; the city council's post: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | 2026-10-21 | Oxford Chronicle quoting the councils' social posts | reported | Oxford Chronicle |\n| **Metropolitan Police, Office for Budget Responsibility; errors on Bristol, Lambeth and Barnet council sites** UK | Reported unavailable; a minister said there was no breach of Budget security | 2026-10-21 | LBC, Insurance Business, East Anglian Daily Times | reported | LBC Insurance Business East Anglian Daily Times |\n| **French government services; the University of Geneva; the BBC; online shops** FR, CH, UK | Listed by the BBC as affected or taken offline | 2026-10-22 | BBC News | reported | BBC News |\n| **Government sites in the Netherlands, France, Germany and Belgium** EU | Listed by Reuters' factbox as having taken sites offline | 2026-10-21 | Reuters, via Global Banking and Finance | reported | Reuters factbox, via Global Bankin |\n\n## Compromised\n\n| Claim | Basis | Status | Sources |\n|---|---|---|---|\n| Amazon: 'PHP2Shell is now being broadly exploited in the wild' | MadPot honeypot telemetry: an attempt on 17 October, proof-of-concept attempts from 02:00 UTC on 21 October, use against sensors 'almost immediately' after release. 'It's unclear if any of these attempts would have succeeded in real-world systems.' | reported (primary party); attempts against sensors, not victims | Amazon |\n| Cloudflare: thousands of attempts in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, 'millions now' | Matthew Prince on X, 22 October 01:25 UTC; attempts seen at the edge, not compromises; no blocked count published | reported (primary party) | Matthew Prince , Cloudflare CEO on Cloudflare |\n| Imperva: no traffic matching the exploit patterns during pre-disclosure monitoring | Imperva had the details under embargo and monitored customer traffic before the announcement | reported (primary party); a negative finding | Imperva Threat Research |\n| Huntress: no exploitation observed on partner systems as of 20:30 UTC on 21 October; no public exploit code known | Huntress's own rapid-response post | reported (primary party); a negative finding | Huntress |\n| watchTowr: active exploitation attempts seen; the flaws 'exploited in the wild' | watchTowr's pages, which block automated capture (HTTP 403); known through search summaries only | unverified: the source could not be read | watchTowr watchTowr |\n| Chainguard's honeypots trapped IPs from China and Russia; 'several other security vendors' reported exploits in the wild | Dan Lorenc, as reported by The Register; vendors not named, no evidence published | reported, second-hand | The Register |\n| NCSC New Zealand: 'aware of reports of active exploitation' | Unattributed | reported | NCSC New Zealand |\n| Weird Gloop: 'extremely likely that a bunch of old PHP fansites and forums have had their databases compromised' | The author's expectation; no case named | unverified: an expectation, not a finding | Weird Gloop |\n| A named organisation confirms it was compromised through php2shell | No captured source carries one | none found | CISA Huntress Imperva Threat Research |\n\n## What the two ledgers say together\n\n- **Precaution was the dominant response**, and it was institutional: national CERTs, state IT providers and councils pulled sites on advice, often before the patch existed, and said so. The one operator who measured it served 94% of its traffic from cache for 13 hours.\n\n- **Attempts are not compromises.** Cloudflare's millions and Amazon's honeypot hits are requests matching a shape at the edge or against a sensor. Nobody has published a count of successful exploitations, and the parties best placed to see one (CISA, Huntress, Imperva) report none.\n\n- **Absence of evidence is weak here.** The detection authors are explicit that default web logs cannot show the attack shape and that no standard log carries the worker id the cross-request bug needs. A quiet log is not a clean host.\n\n- **The question that would settle it** is one that no captured source answers: of the 1.57 million unpatched hosts Censys counted, how many were mod_php on x86_64 with default limits, reachable without a WAF, and how many of those show a worker spawning a shell. That number is what 'blast radius' means at internet scale, and it does not exist yet.\n\nWhat a compromise of one system would reach is on the blast-radius section; how to tell is on detection and defence."
    },
    {
     "v": 2,
     "hash": "b5001f1dd43c",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Impact: taken offline versus compromised\n\nTwo 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.\n\n# Impact: what was taken offline, and what was compromised\n\nIn plain English Two lists: who took websites offline (many, as a precaution), and who was actually broken into (nobody confirmed).\n\nTwo ledgers, because they measure different things. Taking a system offline is a decision an operator makes and can confirm, and the first table is full. Being compromised is a fact only evidence establishes, and the second table has, as of the latest capture, no confirmed entry. That gap is the most important finding on this site: the reported cost of php2shell so far is the cost of precaution.\n\nTwo ledgers. The first is systems taken offline, which is a decision an operator makes and can confirm; the second is systems compromised, which only evidence can establish. The columns say whether the entry comes from the organisation itself or from the press, because the difference is the whole point.\n\n## Taken offline\n\n| Who | What happened | When | Who says so | Status | Sources |\n|---|---|---|---|---|---|\n| **NCSC.nl (the Dutch national cyber security centre's own site)** NL | Taken offline 'uit voorzorg' (as a precaution); DigiD, MijnOverheid and Overheid.nl also offline; no signs of active exploitation of those services at the time | 2026-10-21 | the Dutch government (Rijksoverheid news) | confirmed | Rijksoverheid / NCSC-NL Dutch IT Leaders TPO.nl |\n| **Finland's government public web services (Valtori)** FI | Incoming public traffic restricted from 12:45 local (09:45 UTC); described as preventive, not a response to a breach; internal networks unaffected | 2026-10-21 09:45 UTC | Yle and Helsinki Times quoting Valtori and the National Cyber Security Centre Finland | reported | Yle Helsinki Times |\n| **Latvia: several state digital resources, lsm.lv, 112.lv** LV | Access restricted from abroad; state website platform patched by 20:00 UTC; lsm.lv and 112.lv restored; restrictions on others possibly until 26 October | 2026-10-21 15:25 UTC | CERT.LV itself | confirmed | CERT.LV |\n| **Wikimedia Foundation: 'a number of other systems'** US | 'taken down a number of other systems as a precautionary measure until they can be safely patched'; parts of Wikipedia affected | 2026-10-21 | the Foundation, as quoted by CNN and The Cyber Express; the BBC | reported | CNN The Cyber Express BBC News |\n| **Weird Gloop (RuneScape and other game wikis, about 500 million page views a month)** UK | Web servers off for 13 hours, 'the longest outage we've ever had'; about 94% of page views still served from cache | 2026-10-21 | Weird Gloop itself | confirmed | Weird Gloop |\n| **City of Edinburgh Council** UK | Website offline from late Wednesday afternoon; the council says 'essential maintenance' and is 'waiting on an update from our provider'; it has not confirmed a link | 2026-10-21 | The Scotsman quoting a council spokesperson | reported | The Scotsman |\n| **Oxford City Council and Oxfordshire County Council** UK | Sites removed from service; the city council's post: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | 2026-10-21 | Oxford Chronicle quoting the councils' social posts | reported | Oxford Chronicle |\n| **Metropolitan Police, Office for Budget Responsibility; errors on Bristol, Lambeth and Barnet council sites** UK | Reported unavailable; a minister said there was no breach of Budget security | 2026-10-21 | LBC, Insurance Business, East Anglian Daily Times | reported | LBC Insurance Business East Anglian Daily Times |\n| **French government services; the University of Geneva; the BBC; online shops** FR, CH, UK | Listed by the BBC as affected or taken offline | 2026-10-22 | BBC News | reported | BBC News |\n| **Government sites in the Netherlands, France, Germany and Belgium** EU | Listed by Reuters' factbox as having taken sites offline | 2026-10-21 | Reuters, via Global Banking and Finance | reported | Reuters factbox, via Global Bankin |\n\n## Compromised\n\n| Claim | Basis | Status | Sources |\n|---|---|---|---|\n| Amazon: 'PHP2Shell is now being broadly exploited in the wild' | MadPot honeypot telemetry: an attempt on 17 October, proof-of-concept attempts from 02:00 UTC on 21 October, use against sensors 'almost immediately' after release. 'It's unclear if any of these attempts would have succeeded in real-world systems.' | reported (primary party); attempts against sensors, not victims | Amazon |\n| Cloudflare: thousands of attempts in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, 'millions now' | Matthew Prince on X, 22 October 01:25 UTC; attempts seen at the edge, not compromises; no blocked count published | reported (primary party) | Matthew Prince , Cloudflare CEO on Cloudflare |\n| Imperva: no traffic matching the exploit patterns during pre-disclosure monitoring | Imperva had the details under embargo and monitored customer traffic before the announcement | reported (primary party); a negative finding | Imperva Threat Research |\n| Huntress: no exploitation observed on partner systems as of 20:30 UTC on 21 October; no public exploit code known | Huntress's own rapid-response post | reported (primary party); a negative finding | Huntress |\n| watchTowr: active exploitation attempts seen; the flaws 'exploited in the wild' | watchTowr's pages, which block automated capture (HTTP 403); known through search summaries only | unverified: the source could not be read | watchTowr watchTowr |\n| Chainguard's honeypots trapped IPs from China and Russia; 'several other security vendors' reported exploits in the wild | Dan Lorenc, as reported by The Register; vendors not named, no evidence published | reported, second-hand | The Register |\n| NCSC New Zealand: 'aware of reports of active exploitation' | Unattributed | reported | NCSC New Zealand |\n| Weird Gloop: 'extremely likely that a bunch of old PHP fansites and forums have had their databases compromised' | The author's expectation; no case named | unverified: an expectation, not a finding | Weird Gloop |\n| A named organisation confirms it was compromised through php2shell | No captured source carries one | none found | CISA Huntress Imperva Threat Research |\n\n## What the two ledgers say together\n\n- **Precaution was the dominant response**, and it was institutional: national CERTs, state IT providers and councils pulled sites on advice, often before the patch existed, and said so. The one operator who measured it served 94% of its traffic from cache for 13 hours.\n\n- **Attempts are not compromises.** Cloudflare's millions and Amazon's honeypot hits are requests matching a shape at the edge or against a sensor. Nobody has published a count of successful exploitations, and the parties best placed to see one (CISA, Huntress, Imperva) report none.\n\n- **Absence of evidence is weak here.** The detection authors are explicit that default web logs cannot show the attack shape and that no standard log carries the worker id the cross-request bug needs. A quiet log is not a clean host.\n\n- **The question that would settle it** is one that no captured source answers: of the 1.57 million unpatched hosts Censys counted, how many were mod_php on x86_64 with default limits, reachable without a WAF, and how many of those show a worker spawning a shell. That number is what 'blast radius' means at internet scale, and it does not exist yet.\n\nWhat a compromise of one system would reach is on the blast-radius section; how to tell is on detection and defence."
    },
    {
     "v": 3,
     "hash": "3d48155cc919",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Impact: taken offline versus compromised\n\nTwo 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.\n\n# Impact: what was taken offline, and what was compromised\n\nIn plain English Two lists: who took websites offline (many, as a precaution), and who was actually broken into (nobody confirmed).\n\nTwo ledgers, because they measure different things. Taking a system offline is a decision an operator makes and can confirm, and the first table is full. Being compromised is a fact only evidence establishes, and the second table has, as of the latest capture, no confirmed entry. That gap is the most important finding on this site: the reported cost of php2shell so far is the cost of precaution.\n\nTwo ledgers. The first is systems taken offline, which is a decision an operator makes and can confirm; the second is systems compromised, which only evidence can establish. The columns say whether the entry comes from the organisation itself or from the press, because the difference is the whole point.\n\n## Taken offline\n\n| Who | What happened | When | Who says so | Status | Sources |\n|---|---|---|---|---|---|\n| **NCSC.nl (the Dutch national cyber security centre's own site)** NL | Taken offline 'uit voorzorg' (as a precaution); DigiD, MijnOverheid and Overheid.nl also offline; no signs of active exploitation of those services at the time | 2026-10-21 | the Dutch government (Rijksoverheid news) | confirmed | Rijksoverheid / NCSC-NL Dutch IT Leaders TPO.nl |\n| **Finland's government public web services (Valtori)** FI | Incoming public traffic restricted from 12:45 local (09:45 UTC); described as preventive, not a response to a breach; internal networks unaffected | 2026-10-21 09:45 UTC | Yle and Helsinki Times quoting Valtori and the National Cyber Security Centre Finland | reported | Yle Helsinki Times |\n| **Latvia: several state digital resources, lsm.lv, 112.lv** LV | Access restricted from abroad; state website platform patched by 20:00 UTC; lsm.lv and 112.lv restored; restrictions on others possibly until 26 October | 2026-10-21 15:25 UTC | CERT.LV itself | confirmed | CERT.LV |\n| **Wikimedia Foundation: 'a number of other systems'** US | 'taken down a number of other systems as a precautionary measure until they can be safely patched'; parts of Wikipedia affected | 2026-10-21 | the Foundation, as quoted by CNN and The Cyber Express; the BBC | reported | CNN The Cyber Express BBC News |\n| **Weird Gloop (RuneScape and other game wikis, about 500 million page views a month)** UK | Web servers off for 13 hours, 'the longest outage we've ever had'; about 94% of page views still served from cache | 2026-10-21 | Weird Gloop itself | confirmed | Weird Gloop |\n| **City of Edinburgh Council** UK | Website offline from late Wednesday afternoon; the council says 'essential maintenance' and is 'waiting on an update from our provider'; it has not confirmed a link | 2026-10-21 | The Scotsman quoting a council spokesperson | reported | The Scotsman |\n| **Oxford City Council and Oxfordshire County Council** UK | Sites removed from service; the city council's post: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | 2026-10-21 | Oxford Chronicle quoting the councils' social posts | reported | Oxford Chronicle |\n| **Metropolitan Police, Office for Budget Responsibility; errors on Bristol, Lambeth and Barnet council sites** UK | Reported unavailable; a minister said there was no breach of Budget security | 2026-10-21 | LBC, Insurance Business, East Anglian Daily Times | reported | LBC Insurance Business East Anglian Daily Times |\n| **French government services; the University of Geneva; the BBC; online shops** FR, CH, UK | Listed by the BBC as affected or taken offline | 2026-10-22 | BBC News | reported | BBC News |\n| **Government sites in the Netherlands, France, Germany and Belgium** EU | Listed by Reuters' factbox as having taken sites offline | 2026-10-21 | Reuters, via Global Banking and Finance | reported | Reuters factbox, via Global… |\n\n## Compromised\n\n| Claim | Basis | Status | Sources |\n|---|---|---|---|\n| Amazon: 'PHP2Shell is now being broadly exploited in the wild' | MadPot honeypot telemetry: an attempt on 17 October, proof-of-concept attempts from 02:00 UTC on 21 October, use against sensors 'almost immediately' after release. 'It's unclear if any of these attempts would have succeeded in real-world systems.' | reported (primary party); attempts against sensors, not victims | Amazon |\n| Cloudflare: thousands of attempts in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, 'millions now' | Matthew Prince on X, 22 October 01:25 UTC; attempts seen at the edge, not compromises; no blocked count published | reported (primary party) | Matthew Prince, Cloudflare CEO on… Cloudflare |\n| Imperva: no traffic matching the exploit patterns during pre-disclosure monitoring | Imperva had the details under embargo and monitored customer traffic before the announcement | reported (primary party); a negative finding | Imperva Threat Research |\n| Huntress: no exploitation observed on partner systems as of 20:30 UTC on 21 October; no public exploit code known | Huntress's own rapid-response post | reported (primary party); a negative finding | Huntress |\n| watchTowr: active exploitation attempts seen; the flaws 'exploited in the wild' | watchTowr's pages, which block automated capture (HTTP 403); known through search summaries only | unverified: the source could not be read | watchTowr watchTowr |\n| Chainguard's honeypots trapped IPs from China and Russia; 'several other security vendors' reported exploits in the wild | Dan Lorenc, as reported by The Register; vendors not named, no evidence published | reported, second-hand | The Register |\n| NCSC New Zealand: 'aware of reports of active exploitation' | Unattributed | reported | NCSC New Zealand |\n| Weird Gloop: 'extremely likely that a bunch of old PHP fansites and forums have had their databases compromised' | The author's expectation; no case named | unverified: an expectation, not a finding | Weird Gloop |\n| A named organisation confirms it was compromised through php2shell | No captured source carries one | none found | CISA Huntress Imperva Threat Research |\n\n## What the two ledgers say together\n\n- **Precaution was the dominant response**, and it was institutional: national CERTs, state IT providers and councils pulled sites on advice, often before the patch existed, and said so. The one operator who measured it served 94% of its traffic from cache for 13 hours.\n\n- **Attempts are not compromises.** Cloudflare's millions and Amazon's honeypot hits are requests matching a shape at the edge or against a sensor. Nobody has published a count of successful exploitations, and the parties best placed to see one (CISA, Huntress, Imperva) report none.\n\n- **Absence of evidence is weak here.** The detection authors are explicit that default web logs cannot show the attack shape and that no standard log carries the worker id the cross-request bug needs. A quiet log is not a clean host.\n\n- **The question that would settle it** is one that no captured source answers: of the 1.57 million unpatched hosts Censys counted, how many were mod_php on x86_64 with default limits, reachable without a WAF, and how many of those show a worker spawning a shell. That number is what 'blast radius' means at internet scale, and it does not exist yet.\n\nWhat a compromise of one system would reach is on the blast-radius section; how to tell is on detection and defence."
    },
    {
     "v": 4,
     "hash": "341b6939f1b0",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Impact: taken offline versus compromised\n\nTwo 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.\n\n# Impact: what was taken offline, and what was compromised\n\nIn plain English Two lists: who took websites offline (many, as a precaution), and who was actually broken into (nobody confirmed).\n\nTwo ledgers, because they measure different things. Taking a system offline is a decision an operator makes and can confirm, and the first table is full. Being compromised is a fact only evidence establishes, and the second table has, as of the latest capture, no confirmed entry. That gap is the most important finding on this site: the reported cost of php2shell so far is the cost of precaution.\n\nTwo ledgers. The first is systems taken offline, which is a decision an operator makes and can confirm; the second is systems compromised, which only evidence can establish. The columns say whether the entry comes from the organisation itself or from the press, because the difference is the whole point.\n\n## Taken offline\n\n| Who | What happened | When | Who says so | Status | Sources |\n|---|---|---|---|---|---|\n| **NCSC.nl (the Dutch national cyber security centre's own site)** NL | Taken offline 'uit voorzorg' (as a precaution); DigiD, MijnOverheid and Overheid.nl also offline; no signs of active exploitation of those services at the time | 2026-10-21 | the Dutch government (Rijksoverheid news) | confirmed | Rijksoverheid / NCSC-NL Dutch IT Leaders TPO.nl |\n| **Finland's government public web services (Valtori)** FI | Incoming public traffic restricted from 12:45 local (09:45 UTC); described as preventive, not a response to a breach; internal networks unaffected | 2026-10-21 09:45 UTC | Yle and Helsinki Times quoting Valtori and the National Cyber Security Centre Finland | reported | Yle Helsinki Times |\n| **Latvia: several state digital resources, lsm.lv, 112.lv** LV | Access restricted from abroad; state website platform patched by 20:00 UTC; lsm.lv and 112.lv restored; restrictions on others possibly until 26 October | 2026-10-21 15:25 UTC | CERT.LV itself | confirmed | CERT.LV |\n| **Wikimedia Foundation: 'a number of other systems'** US | 'taken down a number of other systems as a precautionary measure until they can be safely patched'; parts of Wikipedia affected | 2026-10-21 | the Foundation, as quoted by CNN and The Cyber Express; the BBC | reported | CNN The Cyber Express BBC News |\n| **Weird Gloop (RuneScape and other game wikis, about 500 million page views a month)** UK | Web servers off for 13 hours, 'the longest outage we've ever had'; about 94% of page views still served from cache | 2026-10-21 | Weird Gloop itself | confirmed | Weird Gloop |\n| **City of Edinburgh Council** UK | Website offline from late Wednesday afternoon; the council says 'essential maintenance' and is 'waiting on an update from our provider'; it has not confirmed a link | 2026-10-21 | The Scotsman quoting a council spokesperson | reported | The Scotsman |\n| **Oxford City Council and Oxfordshire County Council** UK | Sites removed from service; the city council's post: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | 2026-10-21 | Oxford Chronicle quoting the councils' social posts | reported | Oxford Chronicle |\n| **Metropolitan Police, Office for Budget Responsibility; errors on Bristol, Lambeth and Barnet council sites** UK | Reported unavailable; a minister said there was no breach of Budget security | 2026-10-21 | LBC, Insurance Business, East Anglian Daily Times | reported | LBC Insurance Business East Anglian Daily Times |\n| **French government services; the University of Geneva; the BBC; online shops** FR, CH, UK | Listed by the BBC as affected or taken offline | 2026-10-22 | BBC News | reported | BBC News |\n| **Government sites in the Netherlands, France, Germany and Belgium** EU | Listed by Reuters' factbox as having taken sites offline | 2026-10-21 | Reuters, via Global Banking and Finance | reported | Reuters factbox, via Global… |\n\n## Compromised\n\n| Claim | Basis | Status | Sources |\n|---|---|---|---|\n| Amazon: 'PHP2Shell is now being broadly exploited in the wild' | MadPot honeypot telemetry: an attempt on 17 October, proof-of-concept attempts from 02:00 UTC on 21 October, use against sensors 'almost immediately' after release. 'It's unclear if any of these attempts would have succeeded in real-world systems.' | reported (primary party); attempts against sensors, not victims | Amazon |\n| Cloudflare: thousands of attempts in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, 'millions now' | Matthew Prince on X, 22 October 01:25 UTC; attempts seen at the edge, not compromises; no blocked count published | reported (primary party) | Matthew Prince, Cloudflare CEO on… Cloudflare |\n| Imperva: no traffic matching the exploit patterns during pre-disclosure monitoring | Imperva had the details under embargo and monitored customer traffic before the announcement | reported (primary party); a negative finding | Imperva Threat Research |\n| Huntress: no exploitation observed on partner systems as of 20:30 UTC on 21 October; no public exploit code known | Huntress's own rapid-response post | reported (primary party); a negative finding | Huntress |\n| watchTowr: active exploitation attempts seen; the flaws 'exploited in the wild' | watchTowr's pages, which block automated capture (HTTP 403); known through search summaries only | unverified the source could not be read | watchTowr watchTowr |\n| Chainguard's honeypots trapped IPs from China and Russia; 'several other security vendors' reported exploits in the wild | Dan Lorenc, as reported by The Register; vendors not named, no evidence published | reported, second-hand | The Register |\n| NCSC New Zealand: 'aware of reports of active exploitation' | Unattributed | reported | NCSC New Zealand |\n| Weird Gloop: 'extremely likely that a bunch of old PHP fansites and forums have had their databases compromised' | The author's expectation; no case named | unverified an expectation, not a finding | Weird Gloop |\n| A named organisation confirms it was compromised through php2shell | No captured source carries one | none found | CISA Huntress Imperva Threat Research |\n\n## What the two ledgers say together\n\n- **Precaution was the dominant response**, and it was institutional: national CERTs, state IT providers and councils pulled sites on advice, often before the patch existed, and said so. The one operator who measured it served 94% of its traffic from cache for 13 hours.\n\n- **Attempts are not compromises.** Cloudflare's millions and Amazon's honeypot hits are requests matching a shape at the edge or against a sensor. Nobody has published a count of successful exploitations, and the parties best placed to see one (CISA, Huntress, Imperva) report none.\n\n- **Absence of evidence is weak here.** The detection authors are explicit that default web logs cannot show the attack shape and that no standard log carries the worker id the cross-request bug needs. A quiet log is not a clean host.\n\n- **The question that would settle it** is one that no captured source answers: of the 1.57 million unpatched hosts Censys counted, how many were mod_php on x86_64 with default limits, reachable without a WAF, and how many of those show a worker spawning a shell. That number is what 'blast radius' means at internet scale, and it does not exist yet.\n\nWhat a compromise of one system would reach is on the blast-radius section; how to tell is on detection and defence."
    },
    {
     "v": 5,
     "hash": "5e801719c280",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Impact: taken offline versus compromised\n\nTwo 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.\n\n# Impact: what was taken offline, and what was compromised\n\nIn plain English Two lists: who took websites offline (many, as a precaution), and who was actually broken into (no named organisation through this flaw, as of 22 October).\n\nTwo ledgers, because they measure different things. Taking a system offline is a decision an operator makes and can confirm, and the first table is full. Being compromised is a fact only evidence establishes, and the second table has, as of the latest capture, no confirmed entry. That gap is the most important finding on this site: the reported cost of php2shell so far is the cost of precaution.\n\nTwo ledgers. The first is systems taken offline, which is a decision an operator makes and can confirm; the second is systems compromised, which only evidence can establish. The columns say whether the entry comes from the organisation itself or from the press, because the difference is the whole point.\n\n## Taken offline\n\n| Who | What happened | When | Who says so | Status | Sources |\n|---|---|---|---|---|---|\n| **NCSC.nl (the Dutch national cyber security centre's own site)** NL | Taken offline 'uit voorzorg' (as a precaution); DigiD, MijnOverheid and Overheid.nl also offline; no signs of active exploitation of those services at the time | 2026-10-21 | the Dutch government (Rijksoverheid news) | confirmed | Rijksoverheid / NCSC-NL Dutch IT Leaders TPO.nl |\n| **Finland's government public web services (Valtori)** FI | Incoming public traffic restricted from 12:45 local (09:45 UTC); described as preventive, not a response to a breach; internal networks unaffected | 2026-10-21 09:45 UTC | Yle and Helsinki Times quoting Valtori and the National Cyber Security Centre Finland | reported | Yle Helsinki Times |\n| **Latvia: several state digital resources, lsm.lv, 112.lv** LV | Access restricted from abroad; state website platform patched by 20:00 UTC; lsm.lv and 112.lv restored; restrictions on others possibly until 26 October | 2026-10-21 15:25 UTC | CERT.LV itself | confirmed | CERT.LV |\n| **Wikimedia Foundation: 'a number of other systems'** US | 'taken down a number of other systems as a precautionary measure until they can be safely patched'; parts of Wikipedia affected | 2026-10-21 | the Foundation, as quoted by CNN and The Cyber Express; the BBC | reported | CNN The Cyber Express BBC News |\n| **Weird Gloop (RuneScape and other game wikis, about 500 million page views a month)** UK | Web servers off for 13 hours, 'the longest outage we've ever had'; about 94% of page views still served from cache | 2026-10-21 | Weird Gloop itself | confirmed | Weird Gloop |\n| **City of Edinburgh Council** UK | Website offline from late Wednesday afternoon; the council says 'essential maintenance' and is 'waiting on an update from our provider'; it has not confirmed a link | 2026-10-21 | The Scotsman quoting a council spokesperson | reported | The Scotsman |\n| **Oxford City Council and Oxfordshire County Council** UK | Sites removed from service; the city council's post: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | 2026-10-21 | Oxford Chronicle quoting the councils' social posts | reported | Oxford Chronicle |\n| **Metropolitan Police, Office for Budget Responsibility; errors on Bristol, Lambeth and Barnet council sites** UK | Reported unavailable; a minister said there was no breach of Budget security | 2026-10-21 | LBC, Insurance Business, East Anglian Daily Times | reported | LBC Insurance Business East Anglian Daily Times |\n| **French government services; the University of Geneva; the BBC; online shops** FR, CH, UK | Listed by the BBC as affected or taken offline | 2026-10-22 | BBC News | reported | BBC News |\n| **Government sites in the Netherlands, France, Germany and Belgium** EU | Listed by Reuters' factbox as having taken sites offline | 2026-10-21 | Reuters, via Global Banking and Finance | reported | Reuters factbox, via Global… |\n\n## Compromised\n\n| Claim | Basis | Status | Sources |\n|---|---|---|---|\n| Amazon: 'PHP2Shell is now being broadly exploited in the wild' | MadPot honeypot telemetry: an attempt on 17 October, proof-of-concept attempts from 02:00 UTC on 21 October, use against sensors 'almost immediately' after release. 'It's unclear if any of these attempts would have succeeded in real-world systems.' | reported (primary party); attempts against sensors, not victims | Amazon |\n| Cloudflare: thousands of attempts in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, 'millions now' | Matthew Prince on X, 22 October 01:25 UTC; attempts seen at the edge, not compromises; no blocked count published | reported (primary party) | Matthew Prince, Cloudflare CEO on… Cloudflare |\n| Imperva: no traffic matching the exploit patterns during pre-disclosure monitoring | Imperva had the details under embargo and monitored customer traffic before the announcement | reported (primary party); a negative finding | Imperva Threat Research |\n| Huntress: no exploitation observed on partner systems as of 20:30 UTC on 21 October; no public exploit code known | Huntress's own rapid-response post | reported (primary party); a negative finding | Huntress |\n| watchTowr: active exploitation attempts seen; the flaws 'exploited in the wild' | watchTowr's pages, which block automated capture (HTTP 403); known through search summaries only | unverified the source could not be read | watchTowr watchTowr |\n| Chainguard's honeypots trapped IPs from China and Russia; 'several other security vendors' reported exploits in the wild | Dan Lorenc, as reported by The Register; vendors not named, no evidence published | reported, second-hand | The Register |\n| NCSC New Zealand: 'aware of reports of active exploitation' | Unattributed | reported | NCSC New Zealand |\n| Weird Gloop: 'extremely likely that a bunch of old PHP fansites and forums have had their databases compromised' | The author's expectation; no case named | unverified an expectation, not a finding | Weird Gloop |\n| A named organisation confirms it was compromised through php2shell | No captured source carries one | none found | CISA Huntress Imperva Threat Research |\n\n## What the two ledgers say together\n\n- **Precaution was the dominant response**, and it was institutional: national CERTs, state IT providers and councils pulled sites on advice, often before the patch existed, and said so. The one operator who measured it served 94% of its traffic from cache for 13 hours.\n\n- **Attempts are not compromises.** Cloudflare's millions and Amazon's honeypot hits are requests matching a shape at the edge or against a sensor. Nobody has published a count of successful exploitations, and the parties best placed to see one (CISA, Huntress, Imperva) report none.\n\n- **Absence of evidence is weak here.** The detection authors are explicit that default web logs cannot show the attack shape and that no standard log carries the worker id the cross-request bug needs. A quiet log is not a clean host.\n\n- **The question that would settle it** is one that no captured source answers: of the 1.57 million unpatched hosts Censys counted, how many were mod_php on x86_64 with default limits, reachable without a WAF, and how many of those show a worker spawning a shell. That number is what 'blast radius' means at internet scale, and it does not exist yet.\n\nWhat a compromise of one system would reach is on the blast-radius section; how to tell is on detection and defence."
    }
   ]
  },
  "page-defence": {
   "title": "Detection and defence",
   "kind": "page",
   "path": "defence/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "045caf2cc7cc",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Detection and defence: what blocks php2shell and what shows it\n\nWhat 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.\n\n# Detection and defence: can it be blocked, can it be seen\n\nThe editor's premise is that a zero-day is not an invisibility cloak: an exploit that runs code on a web server leaves a request in the log, a crash in the kernel, a child process in the tree. The captured sources agree, and they also say where the logs go blind. This page is what six edge vendors, three community rule sets and one detection guide say about blocking the request, and what the host shows once the request got through.\n\n## At the edge: what the WAF vendors deployed\n\n| Vendor | What | When | Their own caveat | Sources |\n|---|---|---|---|---|\n| **Cloudflare** | Seven WAF rules per ruleset plus a response-side rule, live for every plan including Free | 2026-10-21T03:02Z, about nine hours before disclosure | 'This is a STOPGAP only' (CTO Dane Knecht); attackers mutated payloads; rules only cover traffic routed through Cloudflare; patch anyway | Cloudflare Safeguard Insurance Business |\n| **Akamai** | Adaptive Security Engine rule 3000991 v1, 'PHP Remote Code Execution Attack Detected', both CVEs; existing command-injection rules also catching weaponised payloads | 2026-10-21 | 'The most effective defense continues to be the prompt application of vendor patches' | Akamai Security Research Safeguard |\n| **Fastly** | A CVE-specific templated rule in the Next-Gen WAF that customers must enable; looks for 'bodies and parameters shaped in ways that differ from legitimate traffic' | 2026-10-21 | 'assume active mitigation will only serve as partial protection and may require blocking a substantial portion of legitimate traffic' | Fastly |\n| **Imperva** | Cloud WAF protected 'out of the box'; Elastic WAF and WAF Gateway after updates; inspects anomalous multipart payloads, repeated session fields, abnormal response headers, upload-progress activity | 2026-10-21 | Had the details under embargo; saw no matching traffic before disclosure | Imperva Threat Research |\n| **AWS** | No managed rule found; guidance to consider blocking multipart file uploads on PHP deployments that cannot be patched, after checking the application impact | 2026-10-21 | AWS's own PHP builds for managed distributions reportedly lagged the release (a reader's comment under the post, unverified) | Amazon Safeguard |\n| **Fortinet FortiWeb** | Three FortiGuard signatures (090502648, 090502651, 09052654) in database 0.00438, plus four custom-rule templates | 2026-10-22T07:55 (article time) | Signatures ship in alert-only mode by default; must be switched to block | Fortinet Community |\n\nEvery one of them says the same two things: it is a stopgap, and patch anyway. The flaw fires during request set-up, so any URL that reaches PHP is a candidate and a rule can only match shape; a rule that blocks every multipart body also blocks every upload. And a WAF sees only the traffic routed through it: the detection guide's first step is a direct curl to the origin IP to prove there is no way round.\n\n## Signatures\n- **Community Suricata and Snort rules** (darkfibr/php2shell-detect, rjmendez/phpup-2026, Lexsah/php2shell-detection). Three independent repositories, all keying on request shape rather than payload bytes: the PHP_SESSION_UPLOAD_PROGRESS field plus many array-form parts; duplicate or excessive multipart headers; a PHP worker spawning a shell. rjmendez retired its own earlier rules after finding the leaked proof-of-concept's mechanism did not match the fix. No rule from the Emerging Threats or Snort projects themselves was found. darkfibr , GitHub rjmendez, GitHub Lexsah, GitHub\n- **ModSecurity, Sigma, Falco, YARA, auditd** (Blevene's detection guide; Lexsah). A ModSecurity rule on the upload-progress field name (verified on 2.9.14, 'zero false positives by construction' once the feature is off), Sigma rules for the arm-phase fatal error ('in Unknown on line 0' means the bailout happened outside any script, in the multipart parse) and for FPM segfaults, Falco rules for a PHP worker exec or memfd, auditd for execve by the pool user. The guide notes ModSecurity's REQUEST_BODY is empty for multipart requests, so an earlier tripwire that matched it never fired. Blevene Lexsah, GitHub\n- **The Hacker News, on what protects before the patch** (The Hacker News). Captured for the record; the newsroom's reading of it is on the exploitation page. THN\n\n## On the host: what exploitation looks like\n\n| Where | Signal | Sources |\n|---|---|---|\n| **Access log** | Multipart POSTs to endpoints that do not take uploads; bodies larger than memory_limit ending in 500 or 502; a burst of 500s from one IP followed by a slow 200 | Blevene Fastly |\n| **PHP error log** | 'Allowed memory size exhausted ... in Unknown on line 0' (an OOM outside any script, during request parsing); 'Failed to decode session object' | Blevene |\n| **Web server and kernel** | Clusters of Apache 'exit signal Segmentation fault (11)' or php-fpm segfaults in dmesg within minutes; nginx 'upstream prematurely closed connection' correlated with a prior fatal from the same IP | Fastly Blevene |\n| **Process tree** | A mod_php or php-fpm worker spawning /bin/sh, curl, wget, or executing from memfd; with the known exploits no application code runs, so a shell from a worker is the exploit | CISA Fastly Blevene |\n| **Network** | New outbound connections from php-fpm or httpd workers to non-database endpoints | Blevene Imperva Threat Research |\n| **What the log cannot show** | nginx's default log format records neither Content-Type nor bodies, so shape-based attempts are invisible there; no standard log carries the worker id the cross-request bug needs; a clean log proves little | darkfibr , GitHub rjmendez, GitHub JPCERT/CC |\n\n## How hard it is to exploit\n\nThe sources that temper the headline, and the one that says expect more.\n- **The CVE vector.** Attack complexity high (AC:H) and attack requirements present (AT:P): the attacker must defeat a built-in protection and needs conditions beyond the request. CVE record\n- **Fastly.** 'the existing PoCs require knowledge of the specific, running PHP binary and address space layout on the server for an attack to yield code execution on x86_64, so most deployments may be safe from RCE. Do not assume this holds true for you. If you operate a 32-bit PHP application, you should likely assume compromise.' Fastly\n- **Imperva.** 'Triggering the bug is much easier than turning it into code execution.' A later request must reach the same worker and place carefully shaped data. Five demonstrated techniques, three via upload progress; a memory disclosure of about 67 KB. Imperva Threat Research\n- **rjmendez (detection author).** A lab reproduction of the leaked proof-of-concept's precondition produced a clean 200; 'VulnCheck independently reports that none of the public PoCs they reviewed have the correct mechanism'. rjmendez, GitHub\n- **Huntress.** Had not built or reproduced a proof of concept and was not aware of public exploit code as of 20:30 UTC on 21 October. Huntress\n- **Fastly, on the fix.** 'The PHP source tree calls the zend_bailout mechanism many places'; patching the demonstrated paths 'does not make the mechanism safe'. Expect more paths. Fastly\n\n## So: can it be detected?\n\nYes, at two layers, and no at a third. **At the edge**, the known request shapes are distinctive and the vendors say their rules match them; the limit is variants and traffic that bypasses the edge. **On the host**, the strongest signal is the one that needs no signature: a PHP worker spawning a shell or a downloader when no application code ran. That is a process-tree rule, cheap to deploy, and the one the detection authors and CISA converge on. **In the default web log**, no: nginx's standard format records neither the content type nor the body, and the cross-request bug leaves no worker id anywhere a log would carry it. An organisation whose only telemetry is the access log cannot answer \"were we hit\" from it, which is the fact behind the agencies' advice to assess for backdoors rather than to look for a log line."
    },
    {
     "v": 2,
     "hash": "acab69b1a10b",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Detection and defence: what blocks php2shell and what shows it\n\nWhat 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.\n\n# Detection and defence: can it be blocked, can it be seen\n\nIn plain English Can these attacks be blocked or spotted? Yes at the edge and on the server, mostly; no from ordinary web logs alone.\n\nThe editor's premise is that a zero-day is not an invisibility cloak: an exploit that runs code on a web server leaves a request in the log, a crash in the kernel, a child process in the tree. The captured sources agree, and they also say where the logs go blind. This page is what six edge vendors, three community rule sets and one detection guide say about blocking the request, and what the host shows once the request got through.\n\n## At the edge: what the WAF vendors deployed\n\n| Vendor | What | When | Their own caveat | Sources |\n|---|---|---|---|---|\n| **Cloudflare** | Seven WAF rules per ruleset plus a response-side rule, live for every plan including Free | 2026-10-21T03:02Z, about nine hours before disclosure | 'This is a STOPGAP only' (CTO Dane Knecht); attackers mutated payloads; rules only cover traffic routed through Cloudflare; patch anyway | Cloudflare Safeguard Insurance Business |\n| **Akamai** | Adaptive Security Engine rule 3000991 v1, 'PHP Remote Code Execution Attack Detected', both CVEs; existing command-injection rules also catching weaponised payloads | 2026-10-21 | 'The most effective defense continues to be the prompt application of vendor patches' | Akamai Security Research Safeguard |\n| **Fastly** | A CVE-specific templated rule in the Next-Gen WAF that customers must enable; looks for 'bodies and parameters shaped in ways that differ from legitimate traffic' | 2026-10-21 | 'assume active mitigation will only serve as partial protection and may require blocking a substantial portion of legitimate traffic' | Fastly |\n| **Imperva** | Cloud WAF protected 'out of the box'; Elastic WAF and WAF Gateway after updates; inspects anomalous multipart payloads, repeated session fields, abnormal response headers, upload-progress activity | 2026-10-21 | Had the details under embargo; saw no matching traffic before disclosure | Imperva Threat Research |\n| **AWS** | No managed rule found; guidance to consider blocking multipart file uploads on PHP deployments that cannot be patched, after checking the application impact | 2026-10-21 | AWS's own PHP builds for managed distributions reportedly lagged the release (a reader's comment under the post, unverified) | Amazon Safeguard |\n| **Fortinet FortiWeb** | Three FortiGuard signatures (090502648, 090502651, 09052654) in database 0.00438, plus four custom-rule templates | 2026-10-22T07:55 (article time) | Signatures ship in alert-only mode by default; must be switched to block | Fortinet Community |\n\nEvery one of them says the same two things: it is a stopgap, and patch anyway. The flaw fires during request set-up, so any URL that reaches PHP is a candidate and a rule can only match shape; a rule that blocks every multipart body also blocks every upload. And a WAF sees only the traffic routed through it: the detection guide's first step is a direct curl to the origin IP to prove there is no way round.\n\n## Signatures\n- **Community Suricata and Snort rules** (darkfibr/php2shell-detect, rjmendez/phpup-2026, Lexsah/php2shell-detection). Three independent repositories, all keying on request shape rather than payload bytes: the PHP_SESSION_UPLOAD_PROGRESS field plus many array-form parts; duplicate or excessive multipart headers; a PHP worker spawning a shell. rjmendez retired its own earlier rules after finding the leaked proof-of-concept's mechanism did not match the fix. No rule from the Emerging Threats or Snort projects themselves was found. darkfibr , GitHub rjmendez, GitHub Lexsah, GitHub\n- **ModSecurity, Sigma, Falco, YARA, auditd** (Blevene's detection guide; Lexsah). A ModSecurity rule on the upload-progress field name (verified on 2.9.14, 'zero false positives by construction' once the feature is off), Sigma rules for the arm-phase fatal error ('in Unknown on line 0' means the bailout happened outside any script, in the multipart parse) and for FPM segfaults, Falco rules for a PHP worker exec or memfd, auditd for execve by the pool user. The guide notes ModSecurity's REQUEST_BODY is empty for multipart requests, so an earlier tripwire that matched it never fired. Blevene Lexsah, GitHub\n- **The Hacker News, on what protects before the patch** (The Hacker News). Captured for the record; the newsroom's reading of it is on the exploitation page. THN\n\n## On the host: what exploitation looks like\n\n| Where | Signal | Sources |\n|---|---|---|\n| **Access log** | Multipart POSTs to endpoints that do not take uploads; bodies larger than memory_limit ending in 500 or 502; a burst of 500s from one IP followed by a slow 200 | Blevene Fastly |\n| **PHP error log** | 'Allowed memory size exhausted ... in Unknown on line 0' (an OOM outside any script, during request parsing); 'Failed to decode session object' | Blevene |\n| **Web server and kernel** | Clusters of Apache 'exit signal Segmentation fault (11)' or php-fpm segfaults in dmesg within minutes; nginx 'upstream prematurely closed connection' correlated with a prior fatal from the same IP | Fastly Blevene |\n| **Process tree** | A mod_php or php-fpm worker spawning /bin/sh, curl, wget, or executing from memfd; with the known exploits no application code runs, so a shell from a worker is the exploit | CISA Fastly Blevene |\n| **Network** | New outbound connections from php-fpm or httpd workers to non-database endpoints | Blevene Imperva Threat Research |\n| **What the log cannot show** | nginx's default log format records neither Content-Type nor bodies, so shape-based attempts are invisible there; no standard log carries the worker id the cross-request bug needs; a clean log proves little | darkfibr , GitHub rjmendez, GitHub JPCERT/CC |\n\n## How hard it is to exploit\n\nThe sources that temper the headline, and the one that says expect more.\n- **The CVE vector.** Attack complexity high (AC:H) and attack requirements present (AT:P): the attacker must defeat a built-in protection and needs conditions beyond the request. CVE record\n- **Fastly.** 'the existing PoCs require knowledge of the specific, running PHP binary and address space layout on the server for an attack to yield code execution on x86_64, so most deployments may be safe from RCE. Do not assume this holds true for you. If you operate a 32-bit PHP application, you should likely assume compromise.' Fastly\n- **Imperva.** 'Triggering the bug is much easier than turning it into code execution.' A later request must reach the same worker and place carefully shaped data. Five demonstrated techniques, three via upload progress; a memory disclosure of about 67 KB. Imperva Threat Research\n- **rjmendez (detection author).** A lab reproduction of the leaked proof-of-concept's precondition produced a clean 200; 'VulnCheck independently reports that none of the public PoCs they reviewed have the correct mechanism'. rjmendez, GitHub\n- **Huntress.** Had not built or reproduced a proof of concept and was not aware of public exploit code as of 20:30 UTC on 21 October. Huntress\n- **Fastly, on the fix.** 'The PHP source tree calls the zend_bailout mechanism many places'; patching the demonstrated paths 'does not make the mechanism safe'. Expect more paths. Fastly\n\n## So: can it be detected?\n\nYes, at two layers, and no at a third. **At the edge**, the known request shapes are distinctive and the vendors say their rules match them; the limit is variants and traffic that bypasses the edge. **On the host**, the strongest signal is the one that needs no signature: a PHP worker spawning a shell or a downloader when no application code ran. That is a process-tree rule, cheap to deploy, and the one the detection authors and CISA converge on. **In the default web log**, no: nginx's standard format records neither the content type nor the body, and the cross-request bug leaves no worker id anywhere a log would carry it. An organisation whose only telemetry is the access log cannot answer \"were we hit\" from it, which is the fact behind the agencies' advice to assess for backdoors rather than to look for a log line."
    },
    {
     "v": 3,
     "hash": "a4414e4f895b",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Detection and defence: what blocks php2shell and what shows it\n\nWhat 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.\n\n# Detection and defence: can it be blocked, can it be seen\n\nIn plain English Can these attacks be blocked or spotted? Yes at the edge and on the server, mostly; no from ordinary web logs alone.\n\nThe editor's premise is that a zero-day is not an invisibility cloak: an exploit that runs code on a web server leaves a request in the log, a crash in the kernel, a child process in the tree. The captured sources agree, and they also say where the logs go blind. This page is what six edge vendors, three community rule sets and one detection guide say about blocking the request, and what the host shows once the request got through.\n\n## At the edge: what the WAF vendors deployed\n\n| Vendor | What | When | Their own caveat | Sources |\n|---|---|---|---|---|\n| **Cloudflare** | Seven WAF rules per ruleset plus a response-side rule, live for every plan including Free | 2026-10-21T03:02Z, about nine hours before disclosure | 'This is a STOPGAP only' (CTO Dane Knecht); attackers mutated payloads; rules only cover traffic routed through Cloudflare; patch anyway | Cloudflare Safeguard Insurance Business |\n| **Akamai** | Adaptive Security Engine rule 3000991 v1, 'PHP Remote Code Execution Attack Detected', both CVEs; existing command-injection rules also catching weaponised payloads | 2026-10-21 | 'The most effective defense continues to be the prompt application of vendor patches' | Akamai Security Research Safeguard |\n| **Fastly** | A CVE-specific templated rule in the Next-Gen WAF that customers must enable; looks for 'bodies and parameters shaped in ways that differ from legitimate traffic' | 2026-10-21 | 'assume active mitigation will only serve as partial protection and may require blocking a substantial portion of legitimate traffic' | Fastly |\n| **Imperva** | Cloud WAF protected 'out of the box'; Elastic WAF and WAF Gateway after updates; inspects anomalous multipart payloads, repeated session fields, abnormal response headers, upload-progress activity | 2026-10-21 | Had the details under embargo; saw no matching traffic before disclosure | Imperva Threat Research |\n| **AWS** | No managed rule found; guidance to consider blocking multipart file uploads on PHP deployments that cannot be patched, after checking the application impact | 2026-10-21 | AWS's own PHP builds for managed distributions reportedly lagged the release (a reader's comment under the post, unverified) | Amazon Safeguard |\n| **Fortinet FortiWeb** | Three FortiGuard signatures (090502648, 090502651, 09052654) in database 0.00438, plus four custom-rule templates | 2026-10-22T07:55 (article time) | Signatures ship in alert-only mode by default; must be switched to block | Fortinet Community |\n\nEvery one of them says the same two things: it is a stopgap, and patch anyway. The flaw fires during request set-up, so any URL that reaches PHP is a candidate and a rule can only match shape; a rule that blocks every multipart body also blocks every upload. And a WAF sees only the traffic routed through it: the detection guide's first step is a direct curl to the origin IP to prove there is no way round.\n\n## Signatures\n- **Community Suricata and Snort rules** (darkfibr/php2shell-detect, rjmendez/phpup-2026, Lexsah/php2shell-detection). Three independent repositories, all keying on request shape rather than payload bytes: the PHP_SESSION_UPLOAD_PROGRESS field plus many array-form parts; duplicate or excessive multipart headers; a PHP worker spawning a shell. rjmendez retired its own earlier rules after finding the leaked proof-of-concept's mechanism did not match the fix. No rule from the Emerging Threats or Snort projects themselves was found. darkfibr, GitHub rjmendez, GitHub Lexsah, GitHub\n- **ModSecurity, Sigma, Falco, YARA, auditd** (Blevene's detection guide; Lexsah). A ModSecurity rule on the upload-progress field name (verified on 2.9.14, 'zero false positives by construction' once the feature is off), Sigma rules for the arm-phase fatal error ('in Unknown on line 0' means the bailout happened outside any script, in the multipart parse) and for FPM segfaults, Falco rules for a PHP worker exec or memfd, auditd for execve by the pool user. The guide notes ModSecurity's REQUEST_BODY is empty for multipart requests, so an earlier tripwire that matched it never fired. Blevene Lexsah, GitHub\n- **The Hacker News, on what protects before the patch** (The Hacker News). Captured for the record; the newsroom's reading of it is on the exploitation page. THN\n\n## On the host: what exploitation looks like\n\n| Where | Signal | Sources |\n|---|---|---|\n| **Access log** | Multipart POSTs to endpoints that do not take uploads; bodies larger than memory_limit ending in 500 or 502; a burst of 500s from one IP followed by a slow 200 | Blevene Fastly |\n| **PHP error log** | 'Allowed memory size exhausted ... in Unknown on line 0' (an OOM outside any script, during request parsing); 'Failed to decode session object' | Blevene |\n| **Web server and kernel** | Clusters of Apache 'exit signal Segmentation fault (11)' or php-fpm segfaults in dmesg within minutes; nginx 'upstream prematurely closed connection' correlated with a prior fatal from the same IP | Fastly Blevene |\n| **Process tree** | A mod_php or php-fpm worker spawning /bin/sh, curl, wget, or executing from memfd; with the known exploits no application code runs, so a shell from a worker is the exploit | CISA Fastly Blevene |\n| **Network** | New outbound connections from php-fpm or httpd workers to non-database endpoints | Blevene Imperva Threat Research |\n| **What the log cannot show** | nginx's default log format records neither Content-Type nor bodies, so shape-based attempts are invisible there; no standard log carries the worker id the cross-request bug needs; a clean log proves little | darkfibr, GitHub rjmendez, GitHub JPCERT/CC |\n\n## How hard it is to exploit\n\nThe sources that temper the headline, and the one that says expect more.\n- **The CVE vector.** Attack complexity high (AC:H) and attack requirements present (AT:P): the attacker must defeat a built-in protection and needs conditions beyond the request. CVE record\n- **Fastly.** 'the existing PoCs require knowledge of the specific, running PHP binary and address space layout on the server for an attack to yield code execution on x86_64, so most deployments may be safe from RCE. Do not assume this holds true for you. If you operate a 32-bit PHP application, you should likely assume compromise.' Fastly\n- **Imperva.** 'Triggering the bug is much easier than turning it into code execution.' A later request must reach the same worker and place carefully shaped data. Five demonstrated techniques, three via upload progress; a memory disclosure of about 67 KB. Imperva Threat Research\n- **rjmendez (detection author).** A lab reproduction of the leaked proof-of-concept's precondition produced a clean 200; 'VulnCheck independently reports that none of the public PoCs they reviewed have the correct mechanism'. rjmendez, GitHub\n- **Huntress.** Had not built or reproduced a proof of concept and was not aware of public exploit code as of 20:30 UTC on 21 October. Huntress\n- **Fastly, on the fix.** 'The PHP source tree calls the zend_bailout mechanism many places'; patching the demonstrated paths 'does not make the mechanism safe'. Expect more paths. Fastly\n\n## So: can it be detected?\n\nYes, at two layers, and no at a third. **At the edge**, the known request shapes are distinctive and the vendors say their rules match them; the limit is variants and traffic that bypasses the edge. **On the host**, the strongest signal is the one that needs no signature: a PHP worker spawning a shell or a downloader when no application code ran. That is a process-tree rule, cheap to deploy, and the one the detection authors and CISA converge on. **In the default web log**, no: nginx's standard format records neither the content type nor the body, and the cross-request bug leaves no worker id anywhere a log would carry it. An organisation whose only telemetry is the access log cannot answer \"were we hit\" from it, which is the fact behind the agencies' advice to assess for backdoors rather than to look for a log line."
    }
   ]
  },
  "page-context": {
   "title": "In context: 2008 to 2026",
   "kind": "page",
   "path": "context/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "377cde59769d",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# In context: php2shell against Kaminsky, Heartbleed, Shellshock, Log4Shell and the last PHP RCE\n\nTen 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.\n\n# In context: php2shell against the flaws that came before\n\nThe editor has worked in security long enough to remember Kaminsky's DNS flaw and Heartbleed, and asked whether this one is as big as the morning's coverage made it. The honest way to answer is a table: ten landmark flaws, each with its CVE record fetched into the vault and its row in CISA's Known Exploited Vulnerabilities catalog, captured on 22 October. The catalog is the one public, dated, machine-readable record of 'this was exploited', and php2shell is not in it yet.\n\nComparators chosen by the editor's memory and the KEV catalog, not by any ranking. Dates are from the CVE records fetched by this site into the vault and from the CISA KEV catalog captured on 22 October; the 'exploited by ransomware' column is CISA's field.\n\n| CVE | Where it was | Published | Added to KEV | Ransomware use | What happened | Why it is here | Record |\n|---|---|---|---|---|---|---|---|\n| **CVE-2008-1447** DNS cache poisoning (Kaminsky) | the DNS protocol as implemented in BIND and others | 2008-07-08 | not in KEV | … | Coordinated multi-vendor patch day on 8 July 2008; details withheld for 30 days and leaked after 13; the patch was source-port randomisation, not a code fix. | Predates KEV (2021). The disclosure model it set, a synchronised patch day with an embargo, is the one php2shell tried and lost two days of. | CVE record |\n| **CVE-2012-1823** PHP-CGI query string (php-cgi) | PHP, sapi/cgi | 2012-05-11 | 2022-03-25 | Unknown | Disclosed by accident at a CTF; exploited within days; still in KEV a decade later. | The first time a PHP core bug put every php-cgi site at risk. Only php-cgi, not mod_php or FPM. | CVE record |\n| **CVE-2014-0160** Heartbleed | OpenSSL TLS heartbeat | 2014-04-07 | 2022-05-04 | Unknown | Memory disclosure, not code execution; named, branded and logoed; patched in days by big sites, over years by the long tail. | The reference point for 'everyone is affected'. Added to KEV eight years after disclosure. | CVE record |\n| **CVE-2014-6271** Shellshock | GNU Bash | 2014-09-24 | 2022-01-28 | Unknown | RCE through environment variables; mass scanning within hours; the first fix was incomplete and followed by more CVEs. | The precedent for 'the first patch was not the last'. | CVE record |\n| **CVE-2017-5638** Apache Struts (Equifax) | Struts Jakarta multipart parser | 2017-03-11 | 2021-11-03 | Known | Exploited within a day; the Equifax breach followed two months later from an unpatched system. | Also a multipart parser. The lesson was about patch latency, not about the bug. | CVE record |\n| **CVE-2019-11043** PHP-FPM buffer underflow | PHP-FPM with specific nginx configs | 2019-10-28 | 2022-03-25 | Known | Public PoC on disclosure; exploitable only with a particular nginx fastcgi_split_path_info pattern. | A PHP core RCE whose real exposure was a fraction of the headline because it needed a specific configuration. | CVE record |\n| **CVE-2021-44228** Log4Shell | Apache Log4j 2 | 2021-12-10 | 2021-12-10 | Known | In KEV the day it was published; exploited at scale within hours; CISA emergency directive; months of follow-up CVEs. | The closest precedent in shape: a flaw in a runtime library below the application, trivially triggered, reachable through any input path. Same-day KEV listing is the marker php2shell has not yet earned. | CVE record |\n| **CVE-2022-22965** Spring4Shell | Spring Framework on JDK 9+ | 2022-04-01 | 2022-04-04 | Unknown | Leaked before the patch; named after Log4Shell; real exposure needed a specific deployment shape (WAR on Tomcat). | The precedent for a leak forcing the release, and for a '-Shell' name outrunning the actual exposure. | CVE record |\n| **CVE-2023-34362** MOVEit Transfer | Progress MOVEit | 2023-06-02 | 2023-06-02 | Known | Exploited before disclosure by one group (Cl0p); thousands of organisations' data taken; same-day KEV. | The precedent for exploitation preceding disclosure, which Amazon's 17 October honeypot hit suggests here. | CVE record |\n| **CVE-2024-4577** PHP-CGI argument injection (Windows) | PHP on Windows in CGI mode | 2024-06-09 | 2024-06-12 | Known | Exploits in the wild one day after disclosure (Akamai); KEV three days after; ransomware use recorded. | The most recent PHP core RCE before this one: in KEV within three days. php2shell, broader in scope, is not in KEV after one day. | CVE record |\n| **CVE-2026-109618 and CVE-2026-109619** php2shell | PHP engine (Zend allocator, request lifecycle) | 2026-10-21 | not in KEV as of 2026-10-22T08:15Z | … | Leaked two days early; patched a day early; five agencies say take systems offline or isolate; governments and councils pulled sites; millions of attempts seen at one CDN; no confirmed compromise of a named system in any captured source. | The row this site exists for. What it shares with Log4Shell is shape; what it has not yet shown is Log4Shell's exploitation. | CISA |\n\n## The catalog itself, counted\n\nCatalog version 2026.10.21: 1,754 entries, 361 with known ransomware use, 13 with PHP in the vendor, product or name, of which three are PHP core: CVE-2012-1823 (added 2022-03-25); CVE-2019-11043 (added 2022-03-25, ransomware known); CVE-2024-4577 (added 2024-06-12, ransomware known). Counted from the captured file. CISA\n\n| Year | CVEs added to KEV |\n|---|---|\n| 2021 | 311 |\n| 2022 | 555 |\n| 2023 | 187 |\n| 2024 | 186 |\n| 2025 | 245 |\n| 2026 | 270 |\n\n| 2026 | Added |\n|---|---|\n| 2026-01 | 17 |\n| 2026-02 | 28 |\n| 2026-03 | 26 |\n| 2026-04 | 31 |\n| 2026-05 | 21 |\n| 2026-06 | 23 |\n| 2026-07 | 26 |\n| 2026-08 | 31 |\n| 2026-09 | 43 |\n| 2026-10 | 24 |\n\n## What the comparison says\n\nThe site's reading of the table above. Positions, with the evidence attached.\n- Severity is not exposure. php2shell's 9.2 is a property of the bug; Heartbleed's 'everyone' and Log4Shell's 'everywhere' were properties of deployment. The comparators show both kinds of big: a bug in a runtime that everything sits on (Log4Shell, Shellshock, php2shell) and a bug whose real exposure was a narrow configuration (CVE-2019-11043, Spring4Shell, CVE-2024-4577 on Windows CGI). Which kind php2shell is depends on how many of the 1.57 million unpatched hosts Censys counted are mod_php on x86_64 with the default settings, a number nobody has published.\n- Urgency before disclosure was institutional, not public. The PHP project had the fix on 18 October and sat on it for a coordinated release; Cloudflare had rules live nine hours early; Amazon had honeypot hits four days early; agencies published within the hour. That is the Kaminsky model working as designed, right up to the point it leaked. The public alarm came with the agencies' offline advice on the morning of 22 October, which is why the editor's question, 'why was the alarm only raised when it went public', has a factual answer: because the embargo held for everyone who was inside it.\n- The KEV test. CISA lists a CVE when it has reliable evidence of exploitation in the wild. Log4Shell and MOVEit were listed the day they were published; CVE-2024-4577 in three days. php2shell was not listed after one day, with Amazon saying it is 'broadly exploited' against honeypots and NCSC NZ 'aware of reports'. Either the evidence has not reached CISA's bar, or attempts against sensors are not the same as exploitation of victims. This site will record the day it is added, if it is.\n- What is new is not the bug class but the discovery pipeline. The OOM-bailout pattern was seen in 2024 and shelved because nobody could prove exploitation. Three teams with model assistance proved it inside three weeks of each other. The historical comparison that matters is therefore not Heartbleed but the gap between 'theoretically exploitable' and 'proven', which used to be months of expert work and may now be days.\n\nThe signals that would move php2shell into the catalog are on the exploitation page; what was taken offline, and by whom, is on impact."
    },
    {
     "v": 2,
     "hash": "008f9e3f7ad1",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# In context: php2shell against Kaminsky, Heartbleed, Shellshock, Log4Shell and the last PHP RCE\n\nTen 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.\n\n# In context: php2shell against the flaws that came before\n\nIn plain English How php2shell compares with famous past flaws such as Heartbleed and Log4Shell, using the official record of which ones were exploited.\n\nThe editor has worked in security long enough to remember Kaminsky's DNS flaw and Heartbleed, and asked whether this one is as big as the morning's coverage made it. The honest way to answer is a table: ten landmark flaws, each with its CVE record fetched into the vault and its row in CISA's Known Exploited Vulnerabilities catalog, captured on 22 October. The catalog is the one public, dated, machine-readable record of 'this was exploited', and php2shell is not in it yet.\n\nComparators chosen by the editor's memory and the KEV catalog, not by any ranking. Dates are from the CVE records fetched by this site into the vault and from the CISA KEV catalog captured on 22 October; the 'exploited by ransomware' column is CISA's field.\n\n| CVE | Where it was | Published | Added to KEV | Ransomware use | What happened | Why it is here | Record |\n|---|---|---|---|---|---|---|---|\n| **CVE-2008-1447** DNS cache poisoning (Kaminsky) | the DNS protocol as implemented in BIND and others | 2008-07-08 | not in KEV | … | Coordinated multi-vendor patch day on 8 July 2008; details withheld for 30 days and leaked after 13; the patch was source-port randomisation, not a code fix. | Predates KEV (2021). The disclosure model it set, a synchronised patch day with an embargo, is the one php2shell tried and lost two days of. | CVE record |\n| **CVE-2012-1823** PHP-CGI query string (php-cgi) | PHP, sapi/cgi | 2012-05-11 | 2022-03-25 | Unknown | Disclosed by accident at a CTF; exploited within days; still in KEV a decade later. | The first time a PHP core bug put every php-cgi site at risk. Only php-cgi, not mod_php or FPM. | CVE record |\n| **CVE-2014-0160** Heartbleed | OpenSSL TLS heartbeat | 2014-04-07 | 2022-05-04 | Unknown | Memory disclosure, not code execution; named, branded and logoed; patched in days by big sites, over years by the long tail. | The reference point for 'everyone is affected'. Added to KEV eight years after disclosure. | CVE record |\n| **CVE-2014-6271** Shellshock | GNU Bash | 2014-09-24 | 2022-01-28 | Unknown | RCE through environment variables; mass scanning within hours; the first fix was incomplete and followed by more CVEs. | The precedent for 'the first patch was not the last'. | CVE record |\n| **CVE-2017-5638** Apache Struts (Equifax) | Struts Jakarta multipart parser | 2017-03-11 | 2021-11-03 | Known | Exploited within a day; the Equifax breach followed two months later from an unpatched system. | Also a multipart parser. The lesson was about patch latency, not about the bug. | CVE record |\n| **CVE-2019-11043** PHP-FPM buffer underflow | PHP-FPM with specific nginx configs | 2019-10-28 | 2022-03-25 | Known | Public PoC on disclosure; exploitable only with a particular nginx fastcgi_split_path_info pattern. | A PHP core RCE whose real exposure was a fraction of the headline because it needed a specific configuration. | CVE record |\n| **CVE-2021-44228** Log4Shell | Apache Log4j 2 | 2021-12-10 | 2021-12-10 | Known | In KEV the day it was published; exploited at scale within hours; CISA emergency directive; months of follow-up CVEs. | The closest precedent in shape: a flaw in a runtime library below the application, trivially triggered, reachable through any input path. Same-day KEV listing is the marker php2shell has not yet earned. | CVE record |\n| **CVE-2022-22965** Spring4Shell | Spring Framework on JDK 9+ | 2022-04-01 | 2022-04-04 | Unknown | Leaked before the patch; named after Log4Shell; real exposure needed a specific deployment shape (WAR on Tomcat). | The precedent for a leak forcing the release, and for a '-Shell' name outrunning the actual exposure. | CVE record |\n| **CVE-2023-34362** MOVEit Transfer | Progress MOVEit | 2023-06-02 | 2023-06-02 | Known | Exploited before disclosure by one group (Cl0p); thousands of organisations' data taken; same-day KEV. | The precedent for exploitation preceding disclosure, which Amazon's 17 October honeypot hit suggests here. | CVE record |\n| **CVE-2024-4577** PHP-CGI argument injection (Windows) | PHP on Windows in CGI mode | 2024-06-09 | 2024-06-12 | Known | Exploits in the wild one day after disclosure (Akamai); KEV three days after; ransomware use recorded. | The most recent PHP core RCE before this one: in KEV within three days. php2shell, broader in scope, is not in KEV after one day. | CVE record |\n| **CVE-2026-109618 and CVE-2026-109619** php2shell | PHP engine (Zend allocator, request lifecycle) | 2026-10-21 | not in KEV as of 2026-10-22T08:15Z | … | Leaked two days early; patched a day early; five agencies say take systems offline or isolate; governments and councils pulled sites; millions of attempts seen at one CDN; no confirmed compromise of a named system in any captured source. | The row this site exists for. What it shares with Log4Shell is shape; what it has not yet shown is Log4Shell's exploitation. | CISA |\n\n## The catalog itself, counted\n\nCatalog version 2026.10.21: 1,754 entries, 361 with known ransomware use, 13 with PHP in the vendor, product or name, of which three are PHP core: CVE-2012-1823 (added 2022-03-25); CVE-2019-11043 (added 2022-03-25, ransomware known); CVE-2024-4577 (added 2024-06-12, ransomware known). Counted from the captured file. CISA\n\n| Year | CVEs added to KEV |\n|---|---|\n| 2021 | 311 |\n| 2022 | 555 |\n| 2023 | 187 |\n| 2024 | 186 |\n| 2025 | 245 |\n| 2026 | 270 |\n\n| 2026 | Added |\n|---|---|\n| 2026-01 | 17 |\n| 2026-02 | 28 |\n| 2026-03 | 26 |\n| 2026-04 | 31 |\n| 2026-05 | 21 |\n| 2026-06 | 23 |\n| 2026-07 | 26 |\n| 2026-08 | 31 |\n| 2026-09 | 43 |\n| 2026-10 | 24 |\n\n## What the comparison says\n\nThe site's reading of the table above. Positions, with the evidence attached.\n- Severity is not exposure. php2shell's 9.2 is a property of the bug; Heartbleed's 'everyone' and Log4Shell's 'everywhere' were properties of deployment. The comparators show both kinds of big: a bug in a runtime that everything sits on (Log4Shell, Shellshock, php2shell) and a bug whose real exposure was a narrow configuration (CVE-2019-11043, Spring4Shell, CVE-2024-4577 on Windows CGI). Which kind php2shell is depends on how many of the 1.57 million unpatched hosts Censys counted are mod_php on x86_64 with the default settings, a number nobody has published.\n- Urgency before disclosure was institutional, not public. The PHP project had the fix on 18 October and sat on it for a coordinated release; Cloudflare had rules live nine hours early; Amazon had honeypot hits four days early; agencies published within the hour. That is the Kaminsky model working as designed, right up to the point it leaked. The public alarm came with the agencies' offline advice on the morning of 22 October, which is why the editor's question, 'why was the alarm only raised when it went public', has a factual answer: because the embargo held for everyone who was inside it.\n- The KEV test. CISA lists a CVE when it has reliable evidence of exploitation in the wild. Log4Shell and MOVEit were listed the day they were published; CVE-2024-4577 in three days. php2shell was not listed after one day, with Amazon saying it is 'broadly exploited' against honeypots and NCSC NZ 'aware of reports'. Either the evidence has not reached CISA's bar, or attempts against sensors are not the same as exploitation of victims. This site will record the day it is added, if it is.\n- What is new is not the bug class but the discovery pipeline. The OOM-bailout pattern was seen in 2024 and shelved because nobody could prove exploitation. Three teams with model assistance proved it inside three weeks of each other. The historical comparison that matters is therefore not Heartbleed but the gap between 'theoretically exploitable' and 'proven', which used to be months of expert work and may now be days.\n\nThe signals that would move php2shell into the catalog are on the exploitation page; what was taken offline, and by whom, is on impact."
    },
    {
     "v": 3,
     "hash": "686c9e3ce8ec",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# In context: php2shell against Kaminsky, Heartbleed, Shellshock, Log4Shell and the last PHP RCE\n\nTen 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.\n\n# In context: php2shell against the flaws that came before\n\nIn plain English How php2shell compares with famous past flaws such as Heartbleed and Log4Shell, using the official record of which ones were exploited.\n\nThe editor has worked in security long enough to remember Kaminsky's DNS flaw and Heartbleed, and asked whether this one is as big as the morning's coverage made it. The honest way to answer is a table: ten landmark flaws, each with its CVE record fetched into the vault and its row in CISA's Known Exploited Vulnerabilities catalog, captured on 22 October. The catalog is the one public, dated, machine-readable record of 'this was exploited', and php2shell is not in it yet.\n\nComparators chosen by the editor's memory and the KEV catalog, not by any ranking. Dates are from the CVE records fetched by this site into the vault and from the CISA KEV catalog captured on 22 October; the 'exploited by ransomware' column is CISA's field.\n\n| CVE | Where it was | Published | Added to KEV | Ransomware use | What happened | Why it is here | Record |\n|---|---|---|---|---|---|---|---|\n| **CVE-2008-1447** DNS cache poisoning (Kaminsky) | the DNS protocol as implemented in BIND and others | 2008-07-08 | not in KEV | … | Coordinated multi-vendor patch day on 8 July 2008; details withheld for 30 days and leaked after 13; the patch was source-port randomisation, not a code fix. | Predates KEV (2021). The disclosure model it set, a synchronised patch day with an embargo, is the one php2shell tried and lost two days of. | CVE record |\n| **CVE-2012-1823** PHP-CGI query string (php-cgi) | PHP, sapi/cgi | 2012-05-11 | 2022-03-25 | Unknown | Disclosed by accident at a CTF; exploited within days; still in KEV a decade later. | The first time a PHP core bug put every php-cgi site at risk. Only php-cgi, not mod_php or FPM. | CVE record |\n| **CVE-2014-0160** Heartbleed | OpenSSL TLS heartbeat | 2014-04-07 | 2022-05-04 | Unknown | Memory disclosure, not code execution; named, branded and logoed; patched in days by big sites, over years by the long tail. | The reference point for 'everyone is affected'. Added to KEV eight years after disclosure. | CVE record |\n| **CVE-2014-6271** Shellshock | GNU Bash | 2014-09-24 | 2022-01-28 | Unknown | RCE through environment variables; mass scanning within hours; the first fix was incomplete and followed by more CVEs. | The precedent for 'the first patch was not the last'. | CVE record |\n| **CVE-2017-5638** Apache Struts (Equifax) | Struts Jakarta multipart parser | 2017-03-11 | 2021-11-03 | Known | Exploited within a day; the Equifax breach followed two months later from an unpatched system. | Also a multipart parser. The lesson was about patch latency, not about the bug. | CVE record |\n| **CVE-2019-11043** PHP-FPM buffer underflow | PHP-FPM with specific nginx configs | 2019-10-28 | 2022-03-25 | Known | Public PoC on disclosure; exploitable only with a particular nginx fastcgi_split_path_info pattern. | A PHP core RCE whose real exposure was a fraction of the headline because it needed a specific configuration. | CVE record |\n| **CVE-2021-44228** Log4Shell | Apache Log4j 2 | 2021-12-10 | 2021-12-10 | Known | In KEV the day it was published; exploited at scale within hours; CISA emergency directive; months of follow-up CVEs. | The closest precedent in shape: a flaw in a runtime library below the application, trivially triggered, reachable through any input path. Same-day KEV listing is the marker php2shell has not yet earned. | CVE record |\n| **CVE-2022-22965** Spring4Shell | Spring Framework on JDK 9+ | 2022-04-01 | 2022-04-04 | Unknown | Leaked before the patch; named after Log4Shell; real exposure needed a specific deployment shape (WAR on Tomcat). | The precedent for a leak forcing the release, and for a '-Shell' name outrunning the actual exposure. | CVE record |\n| **CVE-2023-34362** MOVEit Transfer | Progress MOVEit | 2023-06-02 | 2023-06-02 | Known | Exploited before disclosure by one group (Cl0p); thousands of organisations' data taken; same-day KEV. | The precedent for exploitation preceding disclosure, which Amazon's 17 October honeypot hit suggests here. | CVE record |\n| **CVE-2024-4577** PHP-CGI argument injection (Windows) | PHP on Windows in CGI mode | 2024-06-09 | 2024-06-12 | Known | Exploits in the wild one day after disclosure (Akamai); KEV three days after; ransomware use recorded. | The most recent PHP core RCE before this one: in KEV within three days. php2shell, broader in scope, is not in KEV after one day. | CVE record |\n| **CVE-2026-109618 and CVE-2026-109619** php2shell | PHP engine (Zend allocator, request lifecycle) | 2026-10-21 | not in KEV as of 2026-10-22T08:15Z | … | Leaked two days early; patched a day early; five agencies say take systems offline or isolate; governments and councils pulled sites; millions of attempts seen at one CDN; no named organisation saying it was compromised through php2shell in any captured source as of 20:50 UTC on 22 October. | The row this site exists for. What it shares with Log4Shell is shape; what it has not yet shown is Log4Shell's exploitation. | CISA |\n\n## The catalog itself, counted\n\nCatalog version 2026.10.21: 1,754 entries, 361 with known ransomware use, 13 with PHP in the vendor, product or name, of which three are PHP core: CVE-2012-1823 (added 2022-03-25); CVE-2019-11043 (added 2022-03-25, ransomware known); CVE-2024-4577 (added 2024-06-12, ransomware known). Counted from the captured file. CISA\n\n| Year | CVEs added to KEV |\n|---|---|\n| 2021 | 311 |\n| 2022 | 555 |\n| 2023 | 187 |\n| 2024 | 186 |\n| 2025 | 245 |\n| 2026 | 270 |\n\n| 2026 | Added |\n|---|---|\n| 2026-01 | 17 |\n| 2026-02 | 28 |\n| 2026-03 | 26 |\n| 2026-04 | 31 |\n| 2026-05 | 21 |\n| 2026-06 | 23 |\n| 2026-07 | 26 |\n| 2026-08 | 31 |\n| 2026-09 | 43 |\n| 2026-10 | 24 |\n\n## What the comparison says\n\nThe site's reading of the table above. Positions, with the evidence attached.\n- Severity is not exposure. php2shell's 9.2 is a property of the bug; Heartbleed's 'everyone' and Log4Shell's 'everywhere' were properties of deployment. The comparators show both kinds of big: a bug in a runtime that everything sits on (Log4Shell, Shellshock, php2shell) and a bug whose real exposure was a narrow configuration (CVE-2019-11043, Spring4Shell, CVE-2024-4577 on Windows CGI). Which kind php2shell is depends on how many of the 1.57 million unpatched hosts Censys counted are mod_php on x86_64 with the default settings, a number nobody has published.\n- Urgency before disclosure was institutional, not public. The PHP project had the fix on 18 October and sat on it for a coordinated release; Cloudflare had rules live nine hours early; Amazon had honeypot hits four days early; agencies published within the hour. That is the Kaminsky model working as designed, right up to the point it leaked. The public alarm came with the agencies' offline advice on the morning of 22 October, which is why the editor's question, 'why was the alarm only raised when it went public', has a factual answer: because the embargo held for everyone who was inside it.\n- The KEV test. CISA lists a CVE when it has reliable evidence of exploitation in the wild. Log4Shell and MOVEit were listed the day they were published; CVE-2024-4577 in three days. php2shell was not listed after one day, with Amazon saying it is 'broadly exploited' against honeypots and NCSC NZ 'aware of reports'. Either the evidence has not reached CISA's bar, or attempts against sensors are not the same as exploitation of victims. This site will record the day it is added, if it is.\n- What is new is not the bug class but the discovery pipeline. The OOM-bailout pattern was seen in 2024 and shelved because nobody could prove exploitation. Three teams with model assistance proved it inside three weeks of each other. The historical comparison that matters is therefore not Heartbleed but the gap between 'theoretically exploitable' and 'proven', which used to be months of expert work and may now be days.\n\nThe signals that would move php2shell into the catalog are on the exploitation page; what was taken offline, and by whom, is on impact."
    }
   ]
  },
  "page-actors": {
   "title": "Who says what",
   "kind": "page",
   "path": "actors/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "2249cbbdb7a8",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Who says what: every party and its claims\n\n27 parties in the php2shell story, each with the claims this site attributes to it and the sources behind them.\n\n# Who says what\n\n27 parties whose words this site quotes: maintainers, researchers, agencies, vendors, operators and reporters. Each has a page with the claims it makes, the sources those claims come from, and its own small graph. The count is of claims this site attributes to the party; a party with many claims and few primary sources is one whose word is being taken.\n\n| Party | Role in the story | Claims | Sources |\n|---|---|---|---|\n| The PHP Group / php.net | maintainer, CVE numbering authority | 5 | php.net php.net php-src |\n| The PHP Foundation | funds core developers; published the account of discovery and the leak | 0 | PHP Foundation |\n| Jakub Zelenka (bukka), PHP security team | published both GitHub advisories and the oss-security announcements | 4 | PHP oss-security |\n| Alexandre Daubois, PHP security team (personal blog) | inside account of the rumours and the leak | 4 | Daubois |\n| Calif (Ryan Austin, @lcfr_hax; Michal Zalewski) | first reporter; published the write-up with demo videos | 5 | Calif Ryan Austin , Calif on X |\n| OpenAI (Patch the Planet, Codex Security, Amy Burnett) | reported the same root cause on 11 August; ran the coordination coalition | 3 | OpenAI on X OpenAI OpenAI forum |\n| Wiz Research | independent discovery 19 August; the '70% of the Internet' headline | 0 | Wiz Wiz on X |\n| Quarkslab, OSTIF | 2024 audit that first surfaced the OOM issue | 1 | PHP Foundation Calif |\n| Cloudflare | WAF rules live 9 hours early; saw attack traffic | 3 | Cloudflare |\n| Amazon (CJ Moses) | honeypot evidence of a pre-disclosure attempt | 1 | THN |\n| Chainguard | published patched images before the embargo lifted, per the Foundation | 1 | PHP Foundation Techzine |\n| watchTowr | confirmed the CVE numbers in public on 20 October, per Daubois | 2 | Daubois CERT-EU |\n| National agencies (NSA, CISA, NCSC UK, CERT-EU, CERT-FR, CCCS, ACSC, NCSC NZ, NCSC-NL, ACN, BACS, CERT.LV, JPCERT) | advisories; see the agency table | 11 | NSA CISA NCSC UK |\n| BBC News (live page; Kieran Kelly, Imogen James) | the coverage most readers saw on the morning of 22 October | 0 | BBC News |\n| Alan Woodward, Surrey Centre for Cyber Security | commentator quoted by the BBC: 30 million websites; probing seen by Amazon and Cloudflare | 2 | BBC News |\n| The Hacker News (Ravie Lakshmanan) | carried Amazon's honeypot account and VulnCheck's host count | 1 | THN |\n| Dan Lorenc, Chainguard | shipped patched images early; says exploits were in the wild and denies leaking | 2 | The Register Feross Aboukhadijeh on X on X |\n| Matthew Prince, Cloudflare CEO | the attempt counts | 1 | Matthew Prince , Cloudflare CEO on |\n| Imperva Threat Research | had the details under embargo; saw nothing before disclosure | 1 | Imperva Threat Research |\n| Fastly | the most candid vendor on exploitability and on what a WAF cannot do | 2 | Fastly |\n| Akamai | rule 3000991; the 2024 precedent | 1 | Akamai Security Research Akamai Security Research |\n| Huntress | no exploitation seen on partner systems | 2 | Huntress |\n| Weird Gloop (cookmeplox) | the one operator with a measured outage | 1 | Weird Gloop |\n| The Dutch government and NCSC-NL | took its own site offline | 3 | Rijksoverheid / NCSC-NL NCSC-NL |\n| Valtori and NCSC-FI | Finland's precautionary shutdown | 1 | Yle Helsinki Times |\n| Community detection authors (darkfibr, rjmendez, Lexsah, Blevene) | the rules, and the correction of the leaked PoC's mechanism | 1 | darkfibr , GitHub rjmendez, GitHub Lexsah, GitHub Blevene |\n| Arnaud Le Blanc and the PHP fix authors | wrote the fix | 0 | php/php-src , read from a clone |"
    },
    {
     "v": 2,
     "hash": "5edb162a6f52",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Who says what: every party and its claims\n\n27 parties in the php2shell story, each with the claims this site attributes to it and the sources behind them.\n\n# Who says what\n\nIn plain English Every organisation and person quoted, and what each one says.\n\n27 parties whose words this site quotes: maintainers, researchers, agencies, vendors, operators and reporters. Each has a page with the claims it makes, the sources those claims come from, and its own small graph. The count is of claims this site attributes to the party; a party with many claims and few primary sources is one whose word is being taken.\n\n| Party | Role in the story | Claims | Sources |\n|---|---|---|---|\n| The PHP Group / php.net | maintainer, CVE numbering authority | 5 | php.net php.net php-src |\n| The PHP Foundation | funds core developers; published the account of discovery and the leak | 0 | PHP Foundation |\n| Jakub Zelenka (bukka), PHP security team | published both GitHub advisories and the oss-security announcements | 4 | PHP oss-security |\n| Alexandre Daubois, PHP security team (personal blog) | inside account of the rumours and the leak | 4 | Daubois |\n| Calif (Ryan Austin, @lcfr_hax; Michal Zalewski) | first reporter; published the write-up with demo videos | 5 | Calif Ryan Austin , Calif on X |\n| OpenAI (Patch the Planet, Codex Security, Amy Burnett) | reported the same root cause on 11 August; ran the coordination coalition | 3 | OpenAI on X OpenAI OpenAI forum |\n| Wiz Research | independent discovery 19 August; the '70% of the Internet' headline | 0 | Wiz Wiz on X |\n| Quarkslab, OSTIF | 2024 audit that first surfaced the OOM issue | 1 | PHP Foundation Calif |\n| Cloudflare | WAF rules live 9 hours early; saw attack traffic | 3 | Cloudflare |\n| Amazon (CJ Moses) | honeypot evidence of a pre-disclosure attempt | 1 | THN |\n| Chainguard | published patched images before the embargo lifted, per the Foundation | 1 | PHP Foundation Techzine |\n| watchTowr | confirmed the CVE numbers in public on 20 October, per Daubois | 2 | Daubois CERT-EU |\n| National agencies (NSA, CISA, NCSC UK, CERT-EU, CERT-FR, CCCS, ACSC, NCSC NZ, NCSC-NL, ACN, BACS, CERT.LV, JPCERT) | advisories; see the agency table | 11 | NSA CISA NCSC UK |\n| BBC News (live page; Kieran Kelly, Imogen James) | the coverage most readers saw on the morning of 22 October | 0 | BBC News |\n| Alan Woodward, Surrey Centre for Cyber Security | commentator quoted by the BBC: 30 million websites; probing seen by Amazon and Cloudflare | 2 | BBC News |\n| The Hacker News (Ravie Lakshmanan) | carried Amazon's honeypot account and VulnCheck's host count | 1 | THN |\n| Dan Lorenc, Chainguard | shipped patched images early; says exploits were in the wild and denies leaking | 2 | The Register Feross Aboukhadijeh on X on X |\n| Matthew Prince, Cloudflare CEO | the attempt counts | 1 | Matthew Prince , Cloudflare CEO on |\n| Imperva Threat Research | had the details under embargo; saw nothing before disclosure | 1 | Imperva Threat Research |\n| Fastly | the most candid vendor on exploitability and on what a WAF cannot do | 2 | Fastly |\n| Akamai | rule 3000991; the 2024 precedent | 1 | Akamai Security Research Akamai Security Research |\n| Huntress | no exploitation seen on partner systems | 2 | Huntress |\n| Weird Gloop (cookmeplox) | the one operator with a measured outage | 1 | Weird Gloop |\n| The Dutch government and NCSC-NL | took its own site offline | 3 | Rijksoverheid / NCSC-NL NCSC-NL |\n| Valtori and NCSC-FI | Finland's precautionary shutdown | 1 | Yle Helsinki Times |\n| Community detection authors (darkfibr, rjmendez, Lexsah, Blevene) | the rules, and the correction of the leaked PoC's mechanism | 1 | darkfibr , GitHub rjmendez, GitHub Lexsah, GitHub Blevene |\n| Arnaud Le Blanc and the PHP fix authors | wrote the fix | 0 | php/php-src , read from a clone |"
    },
    {
     "v": 3,
     "hash": "4cdd0dfcdd83",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Who says what: every party and its claims\n\n27 parties in the php2shell story, each with the claims this site attributes to it and the sources behind them.\n\n# Who says what\n\nIn plain English Every organisation and person quoted, and what each one says.\n\n27 parties whose words this site quotes: maintainers, researchers, agencies, vendors, operators and reporters. Each has a page with the claims it makes, the sources those claims come from, and its own small graph. The count is of claims this site attributes to the party; a party with many claims and few primary sources is one whose word is being taken.\n\n| Party | Role in the story | Claims | Sources |\n|---|---|---|---|\n| The PHP Group / php.net | maintainer, CVE numbering authority | 5 | php.net php.net php-src |\n| The PHP Foundation | funds core developers; published the account of discovery and the leak | 0 | PHP Foundation |\n| Jakub Zelenka (bukka), PHP security team | published both GitHub advisories and the oss-security announcements | 4 | PHP oss-security |\n| Alexandre Daubois, PHP security team (personal blog) | inside account of the rumours and the leak | 4 | Daubois |\n| Calif (Ryan Austin, @lcfr_hax; Michal Zalewski) | first reporter; published the write-up with demo videos | 5 | Calif Ryan Austin, Calif on X |\n| OpenAI (Patch the Planet, Codex Security, Amy Burnett) | reported the same root cause on 11 August; ran the coordination coalition | 3 | OpenAI on X OpenAI OpenAI forum |\n| Wiz Research | independent discovery 19 August; the '70% of the Internet' headline | 0 | Wiz Wiz on X |\n| Quarkslab, OSTIF | 2024 audit that first surfaced the OOM issue | 1 | PHP Foundation Calif |\n| Cloudflare | WAF rules live 9 hours early; saw attack traffic | 3 | Cloudflare |\n| Amazon (CJ Moses) | honeypot evidence of a pre-disclosure attempt | 1 | THN |\n| Chainguard | published patched images before the embargo lifted, per the Foundation | 1 | PHP Foundation Techzine |\n| watchTowr | confirmed the CVE numbers in public on 20 October, per Daubois | 2 | Daubois CERT-EU |\n| National agencies (NSA, CISA, NCSC UK, CERT-EU, CERT-FR, CCCS, ACSC, NCSC NZ, NCSC-NL, ACN, BACS, CERT.LV, JPCERT) | advisories; see the agency table | 11 | NSA CISA NCSC UK |\n| BBC News (live page; Kieran Kelly, Imogen James) | the coverage most readers saw on the morning of 22 October | 0 | BBC News |\n| Alan Woodward, Surrey Centre for Cyber Security | commentator quoted by the BBC: 30 million websites; probing seen by Amazon and Cloudflare | 2 | BBC News |\n| The Hacker News (Ravie Lakshmanan) | carried Amazon's honeypot account and VulnCheck's host count | 1 | THN |\n| Dan Lorenc, Chainguard | shipped patched images early; says exploits were in the wild and denies leaking | 2 | The Register Feross Aboukhadijeh on X on X |\n| Matthew Prince, Cloudflare CEO | the attempt counts | 1 | Matthew Prince, Cloudflare CEO on… |\n| Imperva Threat Research | had the details under embargo; saw nothing before disclosure | 1 | Imperva Threat Research |\n| Fastly | the most candid vendor on exploitability and on what a WAF cannot do | 2 | Fastly |\n| Akamai | rule 3000991; the 2024 precedent | 1 | Akamai Security Research Akamai Security Research |\n| Huntress | no exploitation seen on partner systems | 2 | Huntress |\n| Weird Gloop (cookmeplox) | the one operator with a measured outage | 1 | Weird Gloop |\n| The Dutch government and NCSC-NL | took its own site offline | 3 | Rijksoverheid / NCSC-NL NCSC-NL |\n| Valtori and NCSC-FI | Finland's precautionary shutdown | 1 | Yle Helsinki Times |\n| Community detection authors (darkfibr, rjmendez, Lexsah, Blevene) | the rules, and the correction of the leaked PoC's mechanism | 1 | darkfibr, GitHub rjmendez, GitHub Lexsah, GitHub Blevene |\n| Arnaud Le Blanc and the PHP fix authors | wrote the fix | 0 | php/php-src, read from a clone |"
    }
   ]
  },
  "briefing-ciso": {
   "title": "Briefing: CISO",
   "kind": "briefing",
   "path": "briefings/ciso/index.html",
   "scope": "ciso",
   "versions": [
    {
     "v": 1,
     "hash": "32aa97d7508c",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a ciso: What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nThe php2shell story for a ciso: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · CISO\n\n# What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nExposure, evidence of non-compromise, and the board message. Three facts carry this briefing: the bug is in the runtime so your application code is not the question; attempts are in the millions at one CDN but no named victim is confirmed anywhere; and every agency says patch first, with offline as the fallback not the reflex.\n\n## What to decide or do\n- Exposure is a list, not a percentage: every internet-facing system serving PHP, with SAPI, version and what sits behind it. Vendor appliances and hosting panels count.\n- Evidence of non-compromise means log review from 17 October (Amazon's earliest attempt), not from the 21st, and host checks for shells spawned by PHP workers, not just WAF hits.\n- The board line: a critical runtime flaw, patched on day one where we could, isolated where we could not, no evidence of compromise as of today, review continuing. Do not quote 70%.\n- Edge rules were live hours before disclosure; if you are behind a major CDN you had a stopgap you did not have to ask for. It is not a control you can rely on.\n- Expect a follow-up release: a report that the first fix is incomplete reached the security list within two hours.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or advisor · CTO · CFO · Head of AppSec · Developer · Media and communications team."
    },
    {
     "v": 2,
     "hash": "335e0788e9fd",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a ciso: What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nThe 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.\n\nBriefing for Robin, ciso · ******Some technical\n\n# What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nR\nThe answer in thirty seconds\n\nThe flaw is in the PHP runtime, so exposure is every internet-facing system running PHP, including vendor appliances. Review logs from 17 October (the earliest reported attempt), not from the fix. Attempts are reported at scale; no named victim is confirmed. Patch first, isolate where you cannot.\n\nRead the site as Robin →\n\nExposure, evidence of non-compromise, and the board message. Three facts carry this briefing: the bug is in the runtime so your application code is not the question; attempts are in the millions at one CDN but no named victim is confirmed anywhere; and every agency says patch first, with offline as the fallback not the reflex.\n\n## What to decide or do\n- Exposure is a list, not a percentage: every internet-facing system serving PHP, with SAPI, version and what sits behind it. Vendor appliances and hosting panels count.\n- Evidence of non-compromise means log review from 17 October (Amazon's earliest attempt), not from the 21st, and host checks for shells spawned by PHP workers, not just WAF hits.\n- The board line: a critical runtime flaw, patched on day one where we could, isolated where we could not, no evidence of compromise as of today, review continuing. Do not quote 70%.\n- Edge rules were live hours before disclosure; if you are behind a major CDN you had a stopgap you did not have to ask for. It is not a control you can rely on.\n- Expect a follow-up release: a report that the first fix is incomplete reached the security list within two hours.\n\n## Your reading path\n- Your briefing\n- Impact: offline vs compromised\n- Exploitation signals\n- Detection and defence\n- The agencies\n- If you run PHP\n\nChoose *read as Robin* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- exposure as a list\n- evidence we were not hit, from which date\n- the board line\n- where agencies disagree\n\n### What you can skip\n- the C code\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 3,
     "hash": "4f8aa9e709f4",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a ciso: What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nThe 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.\n\nBriefing for Robin, ciso · ******Some technical\n\n# What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nR\nThe answer in thirty seconds\n\nThe flaw is in the PHP runtime, so exposure is every internet-facing system running PHP, including vendor appliances. Review logs from 17 October (the earliest reported attempt), not from the fix. Attempts are reported at scale; no named victim is confirmed. Patch first, isolate where you cannot.\n\nRead the site as Robin →\n\nExposure, evidence of non-compromise, and the board message. Three facts carry this briefing: the bug is in the runtime so your application code is not the question; attempts are in the millions at one CDN but no named victim is confirmed anywhere; and every agency says patch first, with offline as the fallback not the reflex.\n\n## What to decide or do\n- Exposure is a list, not a percentage: every internet-facing system serving PHP, with SAPI, version and what sits behind it. Vendor appliances and hosting panels count.\n- Evidence of non-compromise means log review from 17 October (Amazon's earliest attempt), not from the 21st, and host checks for shells spawned by PHP workers, not just WAF hits.\n- The board line: a critical runtime flaw, patched on day one where we could, isolated where we could not, no evidence of compromise as of today, review continuing. Do not quote 70%.\n- Edge rules were live hours before disclosure; if you are behind a major CDN you had a stopgap you did not have to ask for. It is not a control you can rely on.\n- Expect a follow-up release: a report that the first fix is incomplete reached the security list within two hours.\n\n## Your reading path\n- Your briefing\n- Impact: offline vs compromised\n- Exploitation signals\n- Detection and defence\n- The agencies\n- If you run PHP\n\nChoose *read as Robin* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- exposure as a list\n- evidence we were not hit, from which date\n- the board line\n- where agencies disagree\n\n### What you can skip\n- the C code\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "d4c026737d5d",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a CISO: What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nThe 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.\n\nBriefing for Robin, ciso · ******Some technical\n\n# What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nR\nThe answer in thirty seconds\n\nThe flaw is in the PHP runtime, so exposure is every internet-facing system running PHP, including vendor appliances. Review logs from 17 October (the earliest reported attempt), not from the fix. Attempts are reported at scale; no named victim is confirmed. Patch first, isolate where you cannot.\n\nRead the site as Robin →\n\nExposure, evidence of non-compromise, and the board message. Three facts carry this briefing: the bug is in the runtime so your application code is not the question; attempts are in the millions at one CDN but no named victim is confirmed anywhere; and every agency says patch first, with offline as the fallback not the reflex.\n\n## What to decide or do\n- Exposure is a list, not a percentage: every internet-facing system serving PHP, with SAPI, version and what sits behind it. Vendor appliances and hosting panels count.\n- Evidence of non-compromise means log review from 17 October (Amazon's earliest attempt), not from the 21st, and host checks for shells spawned by PHP workers, not just WAF hits.\n- The board line: a critical runtime flaw, patched on day one where we could, isolated where we could not, no evidence of compromise as of today, review continuing. Do not quote 70%.\n- Edge rules were live hours before disclosure; if you are behind a major CDN you had a stopgap you did not have to ask for. It is not a control you can rely on.\n- Expect a follow-up release: a report that the first fix is incomplete reached the security list within two hours.\n\n## Your reading path\n- Your briefing\n- Impact: offline vs compromised\n- Exploitation signals\n- Detection and defence\n- The agencies\n- If you run PHP\n\nChoose *read as Robin* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- exposure as a list\n- evidence we were not hit, from which date\n- the board line\n- where agencies disagree\n\n### What you can skip\n- the C code\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 5,
     "hash": "d9d2354c026f",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a CISO: What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nThe 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.\n\nBriefing for Robin, ciso · ******Some technical\n\n# What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nR\nThe answer in thirty seconds\n\nThe flaw is in the PHP runtime, so exposure is every internet-facing system running PHP, including vendor appliances. Review logs from 17 October (the earliest reported attempt), not from the fix. Attempts are reported at scale; no named victim is confirmed. Patch first, isolate where you cannot.\n\nRead the site as Robin →\n\nExposure, evidence of non-compromise, and the board message. Three facts carry this briefing: the bug is in the runtime so your application code is not the question; attempts are in the millions at one CDN but no named victim is confirmed anywhere; and every agency says patch first, with offline as the fallback not the reflex.\n\n## What to decide or do\n- Exposure is a list, not a percentage: every internet-facing system serving PHP, with SAPI, version and what sits behind it. Vendor appliances and hosting panels count.\n- Evidence of non-compromise means log review from 17 October (Amazon's earliest attempt), not from the 21st, and host checks for shells spawned by PHP workers, not just WAF hits.\n- The board line: a critical runtime flaw, patched on day one where we could, isolated where we could not, no evidence of compromise as of today, review continuing. Do not quote 70%.\n- Edge rules were live hours before disclosure; if you are behind a major CDN you had a stopgap you did not have to ask for. It is not a control you can rely on.\n- Expect a follow-up release: a report that the first fix is incomplete reached the security list within two hours.\n\n## Your reading path\n- Your briefing\n- Impact: offline vs compromised\n- Exploitation signals\n- Detection and defence\n- The agencies\n- If you run PHP\n\nChoose *read as Robin* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- exposure as a list\n- evidence we were not hit, from which date\n- the board line\n- where agencies disagree\n\n### What you can skip\n- the C code\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | **A4** Corroborated●●●●○○ status overstated | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 6,
     "hash": "faecdc3c8eb1",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a CISO: What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nThe 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.\n\nBriefing for Robin, ciso · ******Some technical\n\n# What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nR\nThe answer in thirty seconds\n\nThe flaw is in the PHP runtime, so exposure is every internet-facing system running PHP, including vendor appliances. Review logs from 17 October (the earliest reported attempt), not from the fix. Attempts are reported at scale; no named victim is confirmed. Patch first, isolate where you cannot.\n\nRead the site as Robin →\n\nExposure, evidence of non-compromise, and the board message. Three facts carry this briefing: the bug is in the runtime so your application code is not the question; attempts are in the millions at one CDN but no named victim is confirmed anywhere; and every agency says patch first, with offline as the fallback not the reflex.\n\n## What to decide or do\n- Exposure is a list, not a percentage: every internet-facing system serving PHP, with SAPI, version and what sits behind it. Vendor appliances and hosting panels count.\n- Evidence of non-compromise means log review from 17 October (Amazon's earliest attempt), not from the 21st, and host checks for shells spawned by PHP workers, not just WAF hits.\n- The board line: a critical runtime flaw, patched on day one where we could, isolated where we could not, no evidence of compromise as of today, review continuing. Do not quote 70%.\n- Edge rules were live hours before disclosure; if you are behind a major CDN you had a stopgap you did not have to ask for. It is not a control you can rely on.\n- Expect a follow-up release: a report that the first fix is incomplete reached the security list within two hours.\n\n## Your reading path\n- Your briefing\n- Impact: offline vs compromised\n- Exploitation signals\n- Detection and defence\n- The agencies\n- If you run PHP\n\nChoose *read as Robin* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- exposure as a list\n- evidence we were not hit, from which date\n- the board line\n- where agencies disagree\n\n### What you can skip\n- the C code\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 7,
     "hash": "c61fdc607cf2",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a CISO: What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nThe 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.\n\nBriefing for Robin, ciso · ******Some technical\n\n# What is our exposure, what is our evidence we were not hit, and what do I tell the board?\n\nR\nThe answer in thirty seconds\n\nThe flaw is in the PHP runtime, so exposure is every internet-facing system running PHP, including vendor appliances. Review logs from 17 October (the earliest reported attempt), not from the fix. Attempts are reported at scale; no named victim is confirmed. Patch first, isolate where you cannot.\n\nRead the site as Robin →\n\nExposure, evidence of non-compromise, and the board message. Three facts carry this briefing: the bug is in the runtime so your application code is not the question; attempts are in the millions at one CDN but no named victim is confirmed anywhere; and every agency says patch first, with offline as the fallback not the reflex.\n\n## What to decide or do\n- Exposure is a list, not a percentage: every internet-facing system serving PHP, with SAPI, version and what sits behind it. Vendor appliances and hosting panels count.\n- Evidence of non-compromise means log review from 17 October (Amazon's earliest attempt), not from the 21st, and host checks for shells spawned by PHP workers, not just WAF hits.\n- The board line: a critical runtime flaw, patched on day one where we could, isolated where we could not, no evidence of compromise as of today, review continuing. Do not quote 70%.\n- Edge rules were live hours before disclosure; if you are behind a major CDN you had a stopgap you did not have to ask for. It is not a control you can rely on.\n- Expect a follow-up release: a report that the first fix is incomplete reached the security list within two hours.\n\n## Your reading path\n- Your briefing\n- Impact: offline vs compromised\n- Exploitation signals\n- Detection and defence\n- The agencies\n- If you run PHP\n\nChoose *read as Robin* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- exposure as a list\n- evidence we were not hit, from which date\n- the board line\n- where agencies disagree\n\n### What you can skip\n- the C code\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CTO · CFO · Data protection officer · Head of AppSec · Developer · Communications team."
    }
   ]
  },
  "briefing-cto": {
   "title": "Briefing: CTO",
   "kind": "briefing",
   "path": "briefings/cto/index.html",
   "scope": "cto",
   "versions": [
    {
     "v": 1,
     "hash": "cd35495726cc",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# 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?\n\nThe php2shell story for a cto: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · CTO\n\n# 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?\n\nWhat the patch changes, what it breaks, and what to change afterwards. The fix is a redesign of how PHP handles running out of memory, so behaviour under memory pressure changes, and it touched 389 files.\n\n## What to decide or do\n- Patch order: mod_php on the internet first; FPM next; everything else after. Restart every worker, rebuild every image, then verify the running version inside the container.\n- The new memory_hard_limit_percent and max_multipart_body_parts settings exist now; the defaults are conservative, and a system that used to survive on the edge of memory_limit may now _exit instead.\n- 7.4, 8.0 and 8.1 have a source backport and no release: that is a migration you are now doing, not a patch.\n- The engineering lesson is time-to-pull-the-plug: how long it takes to take one system off the internet cleanly, with a holding page and a way back, is a property of your platform and it was measured this week whether you wanted it or not.\n- What to change: an inventory that answers \"where is PHP\" in minutes; worker-process monitoring (a PHP worker spawning a shell is the signal); a rehearsed isolate runbook with a named owner.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src , read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or advisor · CISO · CFO · Head of AppSec · Developer · Media and communications team."
    },
    {
     "v": 2,
     "hash": "4cbb5518e10e",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# 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?\n\nThe 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.\n\nBriefing for Avery, cto · ******Some technical\n\n# 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?\n\nA\nThe answer in thirty seconds\n\nPatch internet-facing mod_php first, then FPM, then the rest; restart every worker and rebuild every image. The fix changes how PHP behaves when memory runs out, so test under load. 7.4 to 8.1 have no release. Afterwards, invest in an inventory that answers 'where is PHP' in minutes.\n\nRead the site as Avery →\n\nWhat the patch changes, what it breaks, and what to change afterwards. The fix is a redesign of how PHP handles running out of memory, so behaviour under memory pressure changes, and it touched 389 files.\n\n## What to decide or do\n- Patch order: mod_php on the internet first; FPM next; everything else after. Restart every worker, rebuild every image, then verify the running version inside the container.\n- The new memory_hard_limit_percent and max_multipart_body_parts settings exist now; the defaults are conservative, and a system that used to survive on the edge of memory_limit may now _exit instead.\n- 7.4, 8.0 and 8.1 have a source backport and no release: that is a migration you are now doing, not a patch.\n- The engineering lesson is time-to-pull-the-plug: how long it takes to take one system off the internet cleanly, with a holding page and a way back, is a property of your platform and it was measured this week whether you wanted it or not.\n- What to change: an inventory that answers \"where is PHP\" in minutes; worker-process monitoring (a PHP worker spawning a shell is the signal); a rehearsed isolate runbook with a named owner.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- The code\n- If you run PHP\n- Detection and defence\n\nChoose *read as Avery* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- patch order\n- what the fix changes in behaviour\n- the end-of-life versions\n- time-to-pull-the-plug as a platform property\n\n### What you can skip\n- the disclosure politics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src , read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 3,
     "hash": "74e6f423eaab",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# 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?\n\nThe 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.\n\nBriefing for Avery, cto · ******Some technical\n\n# 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?\n\nA\nThe answer in thirty seconds\n\nPatch internet-facing mod_php first, then FPM, then the rest; restart every worker and rebuild every image. The fix changes how PHP behaves when memory runs out, so test under load. 7.4 to 8.1 have no release. Afterwards, invest in an inventory that answers 'where is PHP' in minutes.\n\nRead the site as Avery →\n\nWhat the patch changes, what it breaks, and what to change afterwards. The fix is a redesign of how PHP handles running out of memory, so behaviour under memory pressure changes, and it touched 389 files.\n\n## What to decide or do\n- Patch order: mod_php on the internet first; FPM next; everything else after. Restart every worker, rebuild every image, then verify the running version inside the container.\n- The new memory_hard_limit_percent and max_multipart_body_parts settings exist now; the defaults are conservative, and a system that used to survive on the edge of memory_limit may now _exit instead.\n- 7.4, 8.0 and 8.1 have a source backport and no release: that is a migration you are now doing, not a patch.\n- The engineering lesson is time-to-pull-the-plug: how long it takes to take one system off the internet cleanly, with a holding page and a way back, is a property of your platform and it was measured this week whether you wanted it or not.\n- What to change: an inventory that answers \"where is PHP\" in minutes; worker-process monitoring (a PHP worker spawning a shell is the signal); a rehearsed isolate runbook with a named owner.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- The code\n- If you run PHP\n- Detection and defence\n\nChoose *read as Avery* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- patch order\n- what the fix changes in behaviour\n- the end-of-life versions\n- time-to-pull-the-plug as a platform property\n\n### What you can skip\n- the disclosure politics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "88d8cdb1740f",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# 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?\n\nThe 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.\n\nBriefing for Avery, cto · ******Some technical\n\n# 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?\n\nA\nThe answer in thirty seconds\n\nPatch internet-facing mod_php first, then FPM, then the rest; restart every worker and rebuild every image. The fix changes how PHP behaves when memory runs out, so test under load. 7.4 to 8.1 have no release. Afterwards, invest in an inventory that answers 'where is PHP' in minutes.\n\nRead the site as Avery →\n\nWhat the patch changes, what it breaks, and what to change afterwards. The fix is a redesign of how PHP handles running out of memory, so behaviour under memory pressure changes, and it touched 389 files.\n\n## What to decide or do\n- Patch order: mod_php on the internet first; FPM next; everything else after. Restart every worker, rebuild every image, then verify the running version inside the container.\n- The new memory_hard_limit_percent and max_multipart_body_parts settings exist now; the defaults are conservative, and a system that used to survive on the edge of memory_limit may now _exit instead.\n- 7.4, 8.0 and 8.1 have a source backport and no release: that is a migration you are now doing, not a patch.\n- The engineering lesson is time-to-pull-the-plug: how long it takes to take one system off the internet cleanly, with a holding page and a way back, is a property of your platform and it was measured this week whether you wanted it or not.\n- What to change: an inventory that answers \"where is PHP\" in minutes; worker-process monitoring (a PHP worker spawning a shell is the signal); a rehearsed isolate runbook with a named owner.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- The code\n- If you run PHP\n- Detection and defence\n\nChoose *read as Avery* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- patch order\n- what the fix changes in behaviour\n- the end-of-life versions\n- time-to-pull-the-plug as a platform property\n\n### What you can skip\n- the disclosure politics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 5,
     "hash": "f9bb2995b7cd",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# 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?\n\nThe 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.\n\nBriefing for Avery, cto · ******Some technical\n\n# 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?\n\nA\nThe answer in thirty seconds\n\nPatch internet-facing mod_php first, then FPM, then the rest; restart every worker and rebuild every image. The fix changes how PHP behaves when memory runs out, so test under load. 7.4 to 8.1 have no release. Afterwards, invest in an inventory that answers 'where is PHP' in minutes.\n\nRead the site as Avery →\n\nWhat the patch changes, what it breaks, and what to change afterwards. The fix is a redesign of how PHP handles running out of memory, so behaviour under memory pressure changes, and it touched 389 files.\n\n## What to decide or do\n- Patch order: mod_php on the internet first; FPM next; everything else after. Restart every worker, rebuild every image, then verify the running version inside the container.\n- The new memory_hard_limit_percent and max_multipart_body_parts settings exist now; the defaults are conservative, and a system that used to survive on the edge of memory_limit may now _exit instead.\n- 7.4, 8.0 and 8.1 have a source backport and no release: that is a migration you are now doing, not a patch.\n- The engineering lesson is time-to-pull-the-plug: how long it takes to take one system off the internet cleanly, with a holding page and a way back, is a property of your platform and it was measured this week whether you wanted it or not.\n- What to change: an inventory that answers \"where is PHP\" in minutes; worker-process monitoring (a PHP worker spawning a shell is the signal); a rehearsed isolate runbook with a named owner.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- The code\n- If you run PHP\n- Detection and defence\n\nChoose *read as Avery* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- patch order\n- what the fix changes in behaviour\n- the end-of-life versions\n- time-to-pull-the-plug as a platform property\n\n### What you can skip\n- the disclosure politics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | **A6** Established●●●●●● | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | **A2** Reported●●○○○○ disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | **A2** Reported●●○○○○ disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | refuted measures differently | 2/3 | BBC News php.net php-src |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 6,
     "hash": "6a63ff77905d",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# 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?\n\nThe 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.\n\nBriefing for Avery, cto · ******Some technical\n\n# 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?\n\nA\nThe answer in thirty seconds\n\nPatch internet-facing mod_php first, then FPM, then the rest; restart every worker and rebuild every image. The fix changes how PHP behaves when memory runs out, so test under load. 7.4 to 8.1 have no release. Afterwards, invest in an inventory that answers 'where is PHP' in minutes.\n\nRead the site as Avery →\n\nWhat the patch changes, what it breaks, and what to change afterwards. The fix is a redesign of how PHP handles running out of memory, so behaviour under memory pressure changes, and it touched 389 files.\n\n## What to decide or do\n- Patch order: mod_php on the internet first; FPM next; everything else after. Restart every worker, rebuild every image, then verify the running version inside the container.\n- The new memory_hard_limit_percent and max_multipart_body_parts settings exist now; the defaults are conservative, and a system that used to survive on the edge of memory_limit may now _exit instead.\n- 7.4, 8.0 and 8.1 have a source backport and no release: that is a migration you are now doing, not a patch.\n- The engineering lesson is time-to-pull-the-plug: how long it takes to take one system off the internet cleanly, with a holding page and a way back, is a property of your platform and it was measured this week whether you wanted it or not.\n- What to change: an inventory that answers \"where is PHP\" in minutes; worker-process monitoring (a PHP worker spawning a shell is the signal); a rehearsed isolate runbook with a named owner.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- The code\n- If you run PHP\n- Detection and defence\n\nChoose *read as Avery* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- patch order\n- what the fix changes in behaviour\n- the end-of-life versions\n- time-to-pull-the-plug as a platform property\n\n### What you can skip\n- the disclosure politics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | **A6** Established●●●●●● | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | **A2** Reported●●○○○○ disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | **A2** Reported●●○○○○ disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | refuted measures differently | 2/3 | BBC News php.net php-src |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CFO · Data protection officer · Head of AppSec · Developer · Communications team."
    }
   ]
  },
  "briefing-cfo": {
   "title": "Briefing: CFO",
   "kind": "briefing",
   "path": "briefings/cfo/index.html",
   "scope": "cfo",
   "versions": [
    {
     "v": 1,
     "hash": "bc7a7ea29a26",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a cfo: What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nThe php2shell story for a cfo: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · CFO\n\n# What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nThe financial question has two sides and the evidence is lopsided: downtime is documented and measurable; breach is claimed and unconfirmed. Insurers are already treating this as an aggregation event.\n\n## What to decide or do\n- Cost of acting: operators that pulled sites report hours to a day offline; one operator served 94% of its page views from cache through a 13-hour shutdown. Engineering time to patch, restart and verify is the main cost for most.\n- Cost of not acting: an unauthenticated code-execution flaw in the web tier; what it reaches is whatever that tier can reach, which is a question for the CISO's inventory, not for a percentage.\n- Insurance: Insurance Business reports underwriters watching for an aggregation event and asks whether business-interruption cover responds to a precautionary shutdown with no breach; that depends on wording and waiting periods. Ask the broker now, in writing.\n- Figures you will hear and should not use in a forecast: 70% of the Internet (a share of websites restated), 30 million websites (no basis), 22.6 million systems (method not given). Use your own inventory count.\n- No named organisation has confirmed a compromise as of the latest capture. That is a statement about evidence, not about safety.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or advisor · CISO · CTO · Head of AppSec · Developer · Media and communications team."
    },
    {
     "v": 2,
     "hash": "28d6f3cc7f23",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a cfo: What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nThe 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.\n\nBriefing for Quinn, cfo · ******Plain English\n\n# What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nQ\nThe answer in thirty seconds\n\nThe documented cost so far is precaution, not breach: hours to a day of downtime for organisations that pulled sites, and engineering time to update. No named organisation has confirmed a compromise. Ask your broker now, in writing, whether a precautionary shutdown with no breach is covered. Do not use 70% of the Internet in any forecast.\n\nRead the site as Quinn →\n\nThe financial question has two sides and the evidence is lopsided: downtime is documented and measurable; breach is claimed and unconfirmed. Insurers are already treating this as an aggregation event.\n\n## What to decide or do\n- Cost of acting: operators that pulled sites report hours to a day offline; one operator served 94% of its page views from cache through a 13-hour shutdown. Engineering time to patch, restart and verify is the main cost for most.\n- Cost of not acting: an unauthenticated code-execution flaw in the web tier; what it reaches is whatever that tier can reach, which is a question for the CISO's inventory, not for a percentage.\n- Insurance: Insurance Business reports underwriters watching for an aggregation event and asks whether business-interruption cover responds to a precautionary shutdown with no breach; that depends on wording and waiting periods. Ask the broker now, in writing.\n- Figures you will hear and should not use in a forecast: 70% of the Internet (a share of websites restated), 30 million websites (no basis), 22.6 million systems (method not given). Use your own inventory count.\n- No named organisation has confirmed a compromise as of the latest capture. That is a statement about evidence, not about safety.\n\n## Your reading path\n- Your briefing\n- Explained from scratch\n- Impact: offline vs compromised\n- The numbers\n- In context: 2008 to 2026\n\nChoose *read as Quinn* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- cost of acting against cost of not acting\n- whether a precautionary shutdown is covered\n- which figures are safe in a forecast\n\n### What you can skip\n- versions and settings\n- the code\n\n\n## The facts this rests on\nShow the 29 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 3,
     "hash": "5842cb10300b",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a cfo: What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nThe 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.\n\nBriefing for Quinn, cfo · ******Plain English\n\n# What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nQ\nThe answer in thirty seconds\n\nThe documented cost so far is precaution, not breach: hours to a day of downtime for organisations that pulled sites, and engineering time to update. No named organisation has confirmed a compromise. Ask your broker now, in writing, whether a precautionary shutdown with no breach is covered. Do not use 70% of the Internet in any forecast.\n\nRead the site as Quinn →\n\nThe financial question has two sides and the evidence is lopsided: downtime is documented and measurable; breach is claimed and unconfirmed. Insurers are already treating this as an aggregation event.\n\n## What to decide or do\n- Cost of acting: operators that pulled sites report hours to a day offline; one operator served 94% of its page views from cache through a 13-hour shutdown. Engineering time to patch, restart and verify is the main cost for most.\n- Cost of not acting: an unauthenticated code-execution flaw in the web tier; what it reaches is whatever that tier can reach, which is a question for the CISO's inventory, not for a percentage.\n- Insurance: Insurance Business reports underwriters watching for an aggregation event and asks whether business-interruption cover responds to a precautionary shutdown with no breach; that depends on wording and waiting periods. Ask the broker now, in writing.\n- Figures you will hear and should not use in a forecast: 70% of the Internet (a share of websites restated), 30 million websites (no basis), 22.6 million systems (method not given). Use your own inventory count.\n- No named organisation has confirmed a compromise as of the latest capture. That is a statement about evidence, not about safety.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The numbers\n- In context: 2008 to 2026\n\nChoose *read as Quinn* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- cost of acting against cost of not acting\n- whether a precautionary shutdown is covered\n- which figures are safe in a forecast\n\n### What you can skip\n- versions and settings\n- the code\n\n\n## The facts this rests on\nShow the 29 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "7914b3ed6d53",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a CFO: What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nThe 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.\n\nBriefing for Quinn, cfo · ******Plain English\n\n# What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nQ\nThe answer in thirty seconds\n\nThe documented cost so far is precaution, not breach: hours to a day of downtime for organisations that pulled sites, and engineering time to update. No named organisation has confirmed a compromise. Ask your broker now, in writing, whether a precautionary shutdown with no breach is covered. Do not use 70% of the Internet in any forecast.\n\nRead the site as Quinn →\n\nThe financial question has two sides and the evidence is lopsided: downtime is documented and measurable; breach is claimed and unconfirmed. Insurers are already treating this as an aggregation event.\n\n## What to decide or do\n- Cost of acting: operators that pulled sites report hours to a day offline; one operator served 94% of its page views from cache through a 13-hour shutdown. Engineering time to patch, restart and verify is the main cost for most.\n- Cost of not acting: an unauthenticated code-execution flaw in the web tier; what it reaches is whatever that tier can reach, which is a question for the CISO's inventory, not for a percentage.\n- Insurance: Insurance Business reports underwriters watching for an aggregation event and asks whether business-interruption cover responds to a precautionary shutdown with no breach; that depends on wording and waiting periods. Ask the broker now, in writing.\n- Figures you will hear and should not use in a forecast: 70% of the Internet (a share of websites restated), 30 million websites (no basis), 22.6 million systems (method not given). Use your own inventory count.\n- No named organisation has confirmed a compromise as of the latest capture. That is a statement about evidence, not about safety.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The numbers\n- In context: 2008 to 2026\n\nChoose *read as Quinn* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- cost of acting against cost of not acting\n- whether a precautionary shutdown is covered\n- which figures are safe in a forecast\n\n### What you can skip\n- versions and settings\n- the code\n\n\n## The facts this rests on\nShow the 29 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 5,
     "hash": "4f8909fe4b4e",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a CFO: What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nThe 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.\n\nBriefing for Quinn, cfo · ******Plain English\n\n# What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nQ\nThe answer in thirty seconds\n\nThe documented cost so far is precaution, not breach: hours to a day of downtime for organisations that pulled sites, and engineering time to update. No named organisation has confirmed a compromise. Ask your broker now, in writing, whether a precautionary shutdown with no breach is covered. Do not use 70% of the Internet in any forecast.\n\nRead the site as Quinn →\n\nThe financial question has two sides and the evidence is lopsided: downtime is documented and measurable; breach is claimed and unconfirmed. Insurers are already treating this as an aggregation event.\n\n## What to decide or do\n- Cost of acting: operators that pulled sites report hours to a day offline; one operator served 94% of its page views from cache through a 13-hour shutdown. Engineering time to patch, restart and verify is the main cost for most.\n- Cost of not acting: an unauthenticated code-execution flaw in the web tier; what it reaches is whatever that tier can reach, which is a question for the CISO's inventory, not for a percentage.\n- Insurance: Insurance Business reports underwriters watching for an aggregation event and asks whether business-interruption cover responds to a precautionary shutdown with no breach; that depends on wording and waiting periods. Ask the broker now, in writing.\n- Figures you will hear and should not use in a forecast: 70% of the Internet (a share of websites restated), 30 million websites (no basis), 22.6 million systems (method not given). Use your own inventory count.\n- No named organisation has confirmed a compromise as of the latest capture. That is a statement about evidence, not about safety.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The numbers\n- In context: 2008 to 2026\n\nChoose *read as Quinn* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- cost of acting against cost of not acting\n- whether a precautionary shutdown is covered\n- which figures are safe in a forecast\n\n### What you can skip\n- versions and settings\n- the code\n\n\n## The facts this rests on\nShow the 29 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | **A4** Corroborated●●●●○○ status overstated | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 6,
     "hash": "2dd1d01a9763",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a CFO: What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nThe 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.\n\nBriefing for Quinn, cfo · ******Plain English\n\n# What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nQ\nThe answer in thirty seconds\n\nThe documented cost so far is precaution, not breach: hours to a day of downtime for organisations that pulled sites, and engineering time to update. As of the evening of 22 October, no named organisation has said it was compromised through this flaw. Ask your broker now, in writing, whether a precautionary shutdown with no breach is covered. Do not use 70% of the Internet in any forecast.\n\nRead the site as Quinn →\n\nThe financial question has two sides and the evidence is lopsided: downtime is documented and measurable; breach is claimed and unconfirmed. Insurers are already treating this as an aggregation event.\n\n## What to decide or do\n- Cost of acting: operators that pulled sites report hours to a day offline; one operator served 94% of its page views from cache through a 13-hour shutdown. Engineering time to patch, restart and verify is the main cost for most.\n- Cost of not acting: an unauthenticated code-execution flaw in the web tier; what it reaches is whatever that tier can reach, which is a question for the CISO's inventory, not for a percentage.\n- Insurance: Insurance Business reports underwriters watching for an aggregation event and asks whether business-interruption cover responds to a precautionary shutdown with no breach; that depends on wording and waiting periods. Ask the broker now, in writing.\n- Figures you will hear and should not use in a forecast: 70% of the Internet (a share of websites restated), 30 million websites (no basis), 22.6 million systems (method not given). Use your own inventory count.\n- No named organisation has confirmed a compromise as of the latest capture. That is a statement about evidence, not about safety.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The numbers\n- In context: 2008 to 2026\n\nChoose *read as Quinn* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- cost of acting against cost of not acting\n- whether a precautionary shutdown is covered\n- which figures are safe in a forecast\n\n### What you can skip\n- versions and settings\n- the code\n\n\n## The facts this rests on\nShow the 29 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 7,
     "hash": "ef8574bfc27b",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a CFO: What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nThe 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.\n\nBriefing for Quinn, cfo · ******Plain English\n\n# What is the financial exposure, what does downtime cost against breach cost, and will insurance respond?\n\nQ\nThe answer in thirty seconds\n\nThe documented cost so far is precaution, not breach: hours to a day of downtime for organisations that pulled sites, and engineering time to update. As of the evening of 22 October, no named organisation has said it was compromised through this flaw. Ask your broker now, in writing, whether a precautionary shutdown with no breach is covered. Do not use 70% of the Internet in any forecast.\n\nRead the site as Quinn →\n\nThe financial question has two sides and the evidence is lopsided: downtime is documented and measurable; breach is claimed and unconfirmed. Insurers are already treating this as an aggregation event.\n\n## What to decide or do\n- Cost of acting: operators that pulled sites report hours to a day offline; one operator served 94% of its page views from cache through a 13-hour shutdown. Engineering time to patch, restart and verify is the main cost for most.\n- Cost of not acting: an unauthenticated code-execution flaw in the web tier; what it reaches is whatever that tier can reach, which is a question for the CISO's inventory, not for a percentage.\n- Insurance: Insurance Business reports underwriters watching for an aggregation event and asks whether business-interruption cover responds to a precautionary shutdown with no breach; that depends on wording and waiting periods. Ask the broker now, in writing.\n- Figures you will hear and should not use in a forecast: 70% of the Internet (a share of websites restated), 30 million websites (no basis), 22.6 million systems (method not given). Use your own inventory count.\n- No named organisation has confirmed a compromise as of the latest capture. That is a statement about evidence, not about safety.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The numbers\n- In context: 2008 to 2026\n\nChoose *read as Quinn* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- cost of acting against cost of not acting\n- whether a precautionary shutdown is covered\n- which figures are safe in a forecast\n\n### What you can skip\n- versions and settings\n- the code\n\n\n## The facts this rests on\nShow the 29 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · Data protection officer · Head of AppSec · Developer · Communications team."
    }
   ]
  },
  "briefing-appsec": {
   "title": "Briefing: Head of AppSec",
   "kind": "briefing",
   "path": "briefings/appsec/index.html",
   "scope": "appsec",
   "versions": [
    {
     "v": 1,
     "hash": "11116ae4d082",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a head of appsec: Which of our applications are in scope, which settings matter, and what do we add to the pipeline?\n\nThe php2shell story for a head of appsec: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Head of AppSec\n\n# Which of our applications are in scope, which settings matter, and what do we add to the pipeline?\n\nScope, settings and the pipeline change. The bug is below your applications: any PHP endpoint that reaches the runtime is a candidate, and the demonstrated paths run before application code.\n\n## What to decide or do\n- In scope: every application on an affected runtime, including the ones with no uploads and no sessions; the session upload-progress path is on by default and needs no session_start().\n- Settings that bound the known paths, in the order of least breakage: session.upload_progress.enabled=0 (server-level, not ini_set); post_max_size low; max_input_nesting_level low; max_multipart_body_parts on patched builds; fatal_error_backtraces=0 on 8.5; pm.max_requests on FPM. None is a fix.\n- The runtime version in production is now an application-security finding: add it to the SBOM, fail the pipeline on an unfixed PHP, and check the running version after deploy, not the package version before.\n- Detection belongs at the edge and on the host, not in the app: the request shape (upload-progress field plus many array parts, oversized multipart bodies) and the process tree (a worker spawning a shell).\n- The public proof-of-concept code does not work as published, per VulnCheck and a lab reproduction; a scanner that fires on it is testing the wrong thing.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or advisor · CISO · CTO · CFO · Developer · Media and communications team."
    },
    {
     "v": 2,
     "hash": "6dd1cc033d1a",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a head of appsec: Which of our applications are in scope, which settings matter, and what do we add to the pipeline?\n\nThe 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.\n\nBriefing for Jamie, head of appsec · ******Deeply technical\n\n# Which of our applications are in scope, which settings matter, and what do we add to the pipeline?\n\nJ\nThe answer in thirty seconds\n\nEvery application on an affected runtime is in scope, including ones with no uploads or sessions: the demonstrated paths run before application code. Add the running PHP version to the SBOM and fail the pipeline on an unfixed one. Detection belongs at the edge and on the host, not in the app.\n\nRead the site as Jamie →\n\nScope, settings and the pipeline change. The bug is below your applications: any PHP endpoint that reaches the runtime is a candidate, and the demonstrated paths run before application code.\n\n## What to decide or do\n- In scope: every application on an affected runtime, including the ones with no uploads and no sessions; the session upload-progress path is on by default and needs no session_start().\n- Settings that bound the known paths, in the order of least breakage: session.upload_progress.enabled=0 (server-level, not ini_set); post_max_size low; max_input_nesting_level low; max_multipart_body_parts on patched builds; fatal_error_backtraces=0 on 8.5; pm.max_requests on FPM. None is a fix.\n- The runtime version in production is now an application-security finding: add it to the SBOM, fail the pipeline on an unfixed PHP, and check the running version after deploy, not the package version before.\n- Detection belongs at the edge and on the host, not in the app: the request shape (upload-progress field plus many array parts, oversized multipart bodies) and the process tree (a worker spawning a shell).\n- The public proof-of-concept code does not work as published, per VulnCheck and a lab reproduction; a scanner that fires on it is testing the wrong thing.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- Affected systems\n- Detection and defence\n- If you run PHP\n\nChoose *read as Jamie* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- which applications are in scope\n- settings in order of least breakage\n- what to add to the pipeline\n- where detection belongs\n\n### What you can skip\n- the disclosure politics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Developer · Communications team."
    },
    {
     "v": 3,
     "hash": "65ad936f216b",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a head of appsec: Which of our applications are in scope, which settings matter, and what do we add to the pipeline?\n\nThe 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.\n\nBriefing for Jamie, head of appsec · ******Deeply technical\n\n# Which of our applications are in scope, which settings matter, and what do we add to the pipeline?\n\nJ\nThe answer in thirty seconds\n\nEvery application on an affected runtime is in scope, including ones with no uploads or sessions: the demonstrated paths run before application code. Add the running PHP version to the SBOM and fail the pipeline on an unfixed one. Detection belongs at the edge and on the host, not in the app.\n\nRead the site as Jamie →\n\nScope, settings and the pipeline change. The bug is below your applications: any PHP endpoint that reaches the runtime is a candidate, and the demonstrated paths run before application code.\n\n## What to decide or do\n- In scope: every application on an affected runtime, including the ones with no uploads and no sessions; the session upload-progress path is on by default and needs no session_start().\n- Settings that bound the known paths, in the order of least breakage: session.upload_progress.enabled=0 (server-level, not ini_set); post_max_size low; max_input_nesting_level low; max_multipart_body_parts on patched builds; fatal_error_backtraces=0 on 8.5; pm.max_requests on FPM. None is a fix.\n- The runtime version in production is now an application-security finding: add it to the SBOM, fail the pipeline on an unfixed PHP, and check the running version after deploy, not the package version before.\n- Detection belongs at the edge and on the host, not in the app: the request shape (upload-progress field plus many array parts, oversized multipart bodies) and the process tree (a worker spawning a shell).\n- The public proof-of-concept code does not work as published, per VulnCheck and a lab reproduction; a scanner that fires on it is testing the wrong thing.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- Affected systems\n- Detection and defence\n- If you run PHP\n\nChoose *read as Jamie* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- which applications are in scope\n- settings in order of least breakage\n- what to add to the pipeline\n- where detection belongs\n\n### What you can skip\n- the disclosure politics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "bbd84faae5e3",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a head of AppSec: Which of our applications are in scope, which settings matter, and what do we add to the pipeline?\n\nThe 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.\n\nBriefing for Jamie, head of appsec · ******Deeply technical\n\n# Which of our applications are in scope, which settings matter, and what do we add to the pipeline?\n\nJ\nThe answer in thirty seconds\n\nEvery application on an affected runtime is in scope, including ones with no uploads or sessions: the demonstrated paths run before application code. Add the running PHP version to the SBOM and fail the pipeline on an unfixed one. Detection belongs at the edge and on the host, not in the app.\n\nRead the site as Jamie →\n\nScope, settings and the pipeline change. The bug is below your applications: any PHP endpoint that reaches the runtime is a candidate, and the demonstrated paths run before application code.\n\n## What to decide or do\n- In scope: every application on an affected runtime, including the ones with no uploads and no sessions; the session upload-progress path is on by default and needs no session_start().\n- Settings that bound the known paths, in the order of least breakage: session.upload_progress.enabled=0 (server-level, not ini_set); post_max_size low; max_input_nesting_level low; max_multipart_body_parts on patched builds; fatal_error_backtraces=0 on 8.5; pm.max_requests on FPM. None is a fix.\n- The runtime version in production is now an application-security finding: add it to the SBOM, fail the pipeline on an unfixed PHP, and check the running version after deploy, not the package version before.\n- Detection belongs at the edge and on the host, not in the app: the request shape (upload-progress field plus many array parts, oversized multipart bodies) and the process tree (a worker spawning a shell).\n- The public proof-of-concept code does not work as published, per VulnCheck and a lab reproduction; a scanner that fires on it is testing the wrong thing.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- Affected systems\n- Detection and defence\n- If you run PHP\n\nChoose *read as Jamie* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- which applications are in scope\n- settings in order of least breakage\n- what to add to the pipeline\n- where detection belongs\n\n### What you can skip\n- the disclosure politics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Developer · Communications team."
    },
    {
     "v": 5,
     "hash": "f440e9a9acfa",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a head of AppSec: Which of our applications are in scope, which settings matter, and what do we add to the pipeline?\n\nThe 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.\n\nBriefing for Jamie, head of appsec · ******Deeply technical\n\n# Which of our applications are in scope, which settings matter, and what do we add to the pipeline?\n\nJ\nThe answer in thirty seconds\n\nEvery application on an affected runtime is in scope, including ones with no uploads or sessions: the demonstrated paths run before application code. Add the running PHP version to the SBOM and fail the pipeline on an unfixed one. Detection belongs at the edge and on the host, not in the app.\n\nRead the site as Jamie →\n\nScope, settings and the pipeline change. The bug is below your applications: any PHP endpoint that reaches the runtime is a candidate, and the demonstrated paths run before application code.\n\n## What to decide or do\n- In scope: every application on an affected runtime, including the ones with no uploads and no sessions; the session upload-progress path is on by default and needs no session_start().\n- Settings that bound the known paths, in the order of least breakage: session.upload_progress.enabled=0 (server-level, not ini_set); post_max_size low; max_input_nesting_level low; max_multipart_body_parts on patched builds; fatal_error_backtraces=0 on 8.5; pm.max_requests on FPM. None is a fix.\n- The runtime version in production is now an application-security finding: add it to the SBOM, fail the pipeline on an unfixed PHP, and check the running version after deploy, not the package version before.\n- Detection belongs at the edge and on the host, not in the app: the request shape (upload-progress field plus many array parts, oversized multipart bodies) and the process tree (a worker spawning a shell).\n- The public proof-of-concept code does not work as published, per VulnCheck and a lab reproduction; a scanner that fires on it is testing the wrong thing.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- Affected systems\n- Detection and defence\n- If you run PHP\n\nChoose *read as Jamie* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- which applications are in scope\n- settings in order of least breakage\n- what to add to the pipeline\n- where detection belongs\n\n### What you can skip\n- the disclosure politics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Developer · Communications team."
    },
    {
     "v": 6,
     "hash": "034245274e0f",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a head of AppSec: Which of our applications are in scope, which settings matter, and what do we add to the pipeline?\n\nThe 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.\n\nBriefing for Jamie, head of appsec · ******Deeply technical\n\n# Which of our applications are in scope, which settings matter, and what do we add to the pipeline?\n\nJ\nThe answer in thirty seconds\n\nEvery application on an affected runtime is in scope, including ones with no uploads or sessions: the demonstrated paths run before application code. Add the running PHP version to the SBOM and fail the pipeline on an unfixed one. Detection belongs at the edge and on the host, not in the app.\n\nRead the site as Jamie →\n\nScope, settings and the pipeline change. The bug is below your applications: any PHP endpoint that reaches the runtime is a candidate, and the demonstrated paths run before application code.\n\n## What to decide or do\n- In scope: every application on an affected runtime, including the ones with no uploads and no sessions; the session upload-progress path is on by default and needs no session_start().\n- Settings that bound the known paths, in the order of least breakage: session.upload_progress.enabled=0 (server-level, not ini_set); post_max_size low; max_input_nesting_level low; max_multipart_body_parts on patched builds; fatal_error_backtraces=0 on 8.5; pm.max_requests on FPM. None is a fix.\n- The runtime version in production is now an application-security finding: add it to the SBOM, fail the pipeline on an unfixed PHP, and check the running version after deploy, not the package version before.\n- Detection belongs at the edge and on the host, not in the app: the request shape (upload-progress field plus many array parts, oversized multipart bodies) and the process tree (a worker spawning a shell).\n- The public proof-of-concept code does not work as published, per VulnCheck and a lab reproduction; a scanner that fires on it is testing the wrong thing.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- Affected systems\n- Detection and defence\n- If you run PHP\n\nChoose *read as Jamie* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- which applications are in scope\n- settings in order of least breakage\n- what to add to the pipeline\n- where detection belongs\n\n### What you can skip\n- the disclosure politics\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Data protection officer · Developer · Communications team."
    }
   ]
  },
  "briefing-developer": {
   "title": "Briefing: Developer",
   "kind": "briefing",
   "path": "briefings/developer/index.html",
   "scope": "developer",
   "versions": [
    {
     "v": 1,
     "hash": "e302086bce6c",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a developer: Is my code the problem, what do I change, and how do I check the box I deployed to?\n\nThe php2shell story for a developer: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Developer\n\n# Is my code the problem, what do I change, and how do I check the box I deployed to?\n\nYour code is not the problem and cannot be the fix. The flaw is in the C engine that runs it. What you can do is check the box you deploy to and avoid making the engine's job harder.\n\n## What to decide or do\n- Check the running version where the code runs: php -v inside the container or phpinfo() on the box, after the restart. The package list is not the answer.\n- Fixed: 8.5.12, 8.4.27, 8.3.36, 8.2.35. If your target is 8.1 or older there is no release; tell whoever owns the platform today.\n- Nothing in userland blocks the demonstrated paths: ini_set() runs too late, .user.ini runs too late, auto_prepend_file runs too late. The settings have to be in php.ini, the pool or the server config.\n- Fix attacker-reachable fatal errors and timeouts in your own code anyway: the advisory lists them as one of the paths for the stale-state bug.\n- After the patch, out-of-memory behaves differently: a delayed fatal at the next safe point instead of an abort, and a hard limit that ends the process. Code that caught the old behaviour in tests will see a change.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or advisor · CISO · CTO · CFO · Head of AppSec · Media and communications team."
    },
    {
     "v": 2,
     "hash": "57c189245ee9",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a developer: Is my code the problem, what do I change, and how do I check the box I deployed to?\n\nThe 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.\n\nBriefing for Lee, developer · ******Some technical\n\n# Is my code the problem, what do I change, and how do I check the box I deployed to?\n\nL\nThe answer in thirty seconds\n\nYour code is not the problem and cannot be the fix: the flaw is in the engine beneath it. ini_set, .user.ini and auto_prepend_file all run too late. Check the running version where the code runs, after the restart, and tell the platform owner today if your target is 8.1 or older.\n\nRead the site as Lee →\n\nYour code is not the problem and cannot be the fix. The flaw is in the C engine that runs it. What you can do is check the box you deploy to and avoid making the engine's job harder.\n\n## What to decide or do\n- Check the running version where the code runs: php -v inside the container or phpinfo() on the box, after the restart. The package list is not the answer.\n- Fixed: 8.5.12, 8.4.27, 8.3.36, 8.2.35. If your target is 8.1 or older there is no release; tell whoever owns the platform today.\n- Nothing in userland blocks the demonstrated paths: ini_set() runs too late, .user.ini runs too late, auto_prepend_file runs too late. The settings have to be in php.ini, the pool or the server config.\n- Fix attacker-reachable fatal errors and timeouts in your own code anyway: the advisory lists them as one of the paths for the stale-state bug.\n- After the patch, out-of-memory behaves differently: a delayed fatal at the next safe point instead of an abort, and a hard limit that ends the process. Code that caught the old behaviour in tests will see a change.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- The code\n- If you run PHP\n\nChoose *read as Lee* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- is my code the problem\n- what I can and cannot do in userland\n- how to check the box I deploy to\n\n### What you can skip\n- the agency comparison\n- the money\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Communications team."
    },
    {
     "v": 3,
     "hash": "bff537fa3559",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a developer: Is my code the problem, what do I change, and how do I check the box I deployed to?\n\nThe 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.\n\nBriefing for Lee, developer · ******Some technical\n\n# Is my code the problem, what do I change, and how do I check the box I deployed to?\n\nL\nThe answer in thirty seconds\n\nYour code is not the problem and cannot be the fix: the flaw is in the engine beneath it. ini_set, .user.ini and auto_prepend_file all run too late. Check the running version where the code runs, after the restart, and tell the platform owner today if your target is 8.1 or older.\n\nRead the site as Lee →\n\nYour code is not the problem and cannot be the fix. The flaw is in the C engine that runs it. What you can do is check the box you deploy to and avoid making the engine's job harder.\n\n## What to decide or do\n- Check the running version where the code runs: php -v inside the container or phpinfo() on the box, after the restart. The package list is not the answer.\n- Fixed: 8.5.12, 8.4.27, 8.3.36, 8.2.35. If your target is 8.1 or older there is no release; tell whoever owns the platform today.\n- Nothing in userland blocks the demonstrated paths: ini_set() runs too late, .user.ini runs too late, auto_prepend_file runs too late. The settings have to be in php.ini, the pool or the server config.\n- Fix attacker-reachable fatal errors and timeouts in your own code anyway: the advisory lists them as one of the paths for the stale-state bug.\n- After the patch, out-of-memory behaves differently: a delayed fatal at the next safe point instead of an abort, and a hard limit that ends the process. Code that caught the old behaviour in tests will see a change.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- The code\n- If you run PHP\n\nChoose *read as Lee* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- is my code the problem\n- what I can and cannot do in userland\n- how to check the box I deploy to\n\n### What you can skip\n- the agency comparison\n- the money\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Communications team."
    },
    {
     "v": 4,
     "hash": "43811433977f",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a developer: Is my code the problem, what do I change, and how do I check the box I deployed to?\n\nThe 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.\n\nBriefing for Lee, developer · ******Some technical\n\n# Is my code the problem, what do I change, and how do I check the box I deployed to?\n\nL\nThe answer in thirty seconds\n\nYour code is not the problem and cannot be the fix: the flaw is in the engine beneath it. ini_set, .user.ini and auto_prepend_file all run too late. Check the running version where the code runs, after the restart, and tell the platform owner today if your target is 8.1 or older.\n\nRead the site as Lee →\n\nYour code is not the problem and cannot be the fix. The flaw is in the C engine that runs it. What you can do is check the box you deploy to and avoid making the engine's job harder.\n\n## What to decide or do\n- Check the running version where the code runs: php -v inside the container or phpinfo() on the box, after the restart. The package list is not the answer.\n- Fixed: 8.5.12, 8.4.27, 8.3.36, 8.2.35. If your target is 8.1 or older there is no release; tell whoever owns the platform today.\n- Nothing in userland blocks the demonstrated paths: ini_set() runs too late, .user.ini runs too late, auto_prepend_file runs too late. The settings have to be in php.ini, the pool or the server config.\n- Fix attacker-reachable fatal errors and timeouts in your own code anyway: the advisory lists them as one of the paths for the stale-state bug.\n- After the patch, out-of-memory behaves differently: a delayed fatal at the next safe point instead of an abort, and a hard limit that ends the process. Code that caught the old behaviour in tests will see a change.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- The code\n- If you run PHP\n\nChoose *read as Lee* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- is my code the problem\n- what I can and cannot do in userland\n- how to check the box I deploy to\n\n### What you can skip\n- the agency comparison\n- the money\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Communications team."
    },
    {
     "v": 5,
     "hash": "e7c688bb9810",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a developer: Is my code the problem, what do I change, and how do I check the box I deployed to?\n\nThe 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.\n\nBriefing for Lee, developer · ******Some technical\n\n# Is my code the problem, what do I change, and how do I check the box I deployed to?\n\nL\nThe answer in thirty seconds\n\nYour code is not the problem and cannot be the fix: the flaw is in the engine beneath it. ini_set, .user.ini and auto_prepend_file all run too late. Check the running version where the code runs, after the restart, and tell the platform owner today if your target is 8.1 or older.\n\nRead the site as Lee →\n\nYour code is not the problem and cannot be the fix. The flaw is in the C engine that runs it. What you can do is check the box you deploy to and avoid making the engine's job harder.\n\n## What to decide or do\n- Check the running version where the code runs: php -v inside the container or phpinfo() on the box, after the restart. The package list is not the answer.\n- Fixed: 8.5.12, 8.4.27, 8.3.36, 8.2.35. If your target is 8.1 or older there is no release; tell whoever owns the platform today.\n- Nothing in userland blocks the demonstrated paths: ini_set() runs too late, .user.ini runs too late, auto_prepend_file runs too late. The settings have to be in php.ini, the pool or the server config.\n- Fix attacker-reachable fatal errors and timeouts in your own code anyway: the advisory lists them as one of the paths for the stale-state bug.\n- After the patch, out-of-memory behaves differently: a delayed fatal at the next safe point instead of an abort, and a hard limit that ends the process. Code that caught the old behaviour in tests will see a change.\n\n## Your reading path\n- Your briefing\n- The two flaws\n- The code\n- If you run PHP\n\nChoose *read as Lee* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- is my code the problem\n- what I can and cannot do in userland\n- how to check the box I deploy to\n\n### What you can skip\n- the agency comparison\n- the money\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Data protection officer · Head of AppSec · Communications team."
    }
   ]
  },
  "briefing-comms": {
   "title": "Briefing: Media and communications team",
   "kind": "briefing",
   "path": "briefings/comms/index.html",
   "scope": "comms",
   "versions": [
    {
     "v": 1,
     "hash": "a636a0c61feb",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# 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?\n\nThe php2shell story for a media and communications team: what to decide, the claims it rests on with their status and sources, and what is still open.\n\nBriefing · Media and communications team\n\n# What can we say that is true, what should we not say, and what will we be asked?\n\nWhat is true, what is not, and what you will be asked. The story most readers saw on the morning of 22 October carried three things this site could not confirm, and the questions will come from that story.\n\n## What to decide or do\n- True and safe to say: two critical flaws in PHP itself, patched on 21 October; the organisation patched or isolated its systems; no evidence of compromise as of today, review continuing.\n- Not safe to say: \"70% of the Internet\" (a headline restating a share of websites), \"the most severe ever\" (a vendor's phrase), \"exploited everywhere\" (attempts against honeypots and CDNs, no named victim), \"found by AI\" without \"by researchers using\".\n- The questions: Were you hit? (answer with the evidence window: logs reviewed from 17 October.) Did you take sites down? (precaution, not incident, as Oxford City Council put it.) Why did it take so long? (the fix was authored on 18 October and released under a coordinated plan that leaked.)\n- Attribution: three research teams and the PHP Foundation each tell the discovery story differently; do not pick one. The flaw was seen in 2024 and not fixed because exploitation could not be shown.\n- Point at primary sources: php.net's advisory and your national agency. Do not link a vendor blog as the authority.\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin , Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other briefings: Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or advisor · CISO · CTO · CFO · Head of AppSec · Developer."
    },
    {
     "v": 2,
     "hash": "0f9a4321e428",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# 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?\n\nThe 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.\n\nBriefing for Riley, communications team · ******Plain English\n\n# What can we say that is true, what should we not say, and what will we be asked?\n\nR\nThe answer in thirty seconds\n\nSafe to say: two critical flaws in PHP were fixed on 21 October; we updated or isolated our systems; we have no evidence of compromise and review continues. Do not say '70% of the Internet', 'the most severe ever' or 'exploited everywhere'. Point people to php.net and your national agency.\n\nRead the site as Riley →\n\nWhat is true, what is not, and what you will be asked. The story most readers saw on the morning of 22 October carried three things this site could not confirm, and the questions will come from that story.\n\n## What to decide or do\n- True and safe to say: two critical flaws in PHP itself, patched on 21 October; the organisation patched or isolated its systems; no evidence of compromise as of today, review continuing.\n- Not safe to say: \"70% of the Internet\" (a headline restating a share of websites), \"the most severe ever\" (a vendor's phrase), \"exploited everywhere\" (attempts against honeypots and CDNs, no named victim), \"found by AI\" without \"by researchers using\".\n- The questions: Were you hit? (answer with the evidence window: logs reviewed from 17 October.) Did you take sites down? (precaution, not incident, as Oxford City Council put it.) Why did it take so long? (the fix was authored on 18 October and released under a coordinated plan that leaked.)\n- Attribution: three research teams and the PHP Foundation each tell the discovery story differently; do not pick one. The flaw was seen in 2024 and not fixed because exploitation could not be shown.\n- Point at primary sources: php.net's advisory and your national agency. Do not link a vendor blog as the authority.\n\n## Your reading path\n- Your briefing\n- Explained from scratch\n- The numbers\n- Impact: offline vs compromised\n- The agencies\n\nChoose *read as Riley* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- the safe statement\n- the phrases to avoid\n- the questions coming\n- where to point people\n\n### What you can skip\n- the code\n- the settings\n\n\n## The facts this rests on\nShow the 32 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin , Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer."
    },
    {
     "v": 3,
     "hash": "fcfe5d3d40ff",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# 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?\n\nThe 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.\n\nBriefing for Riley, communications team · ******Plain English\n\n# What can we say that is true, what should we not say, and what will we be asked?\n\nR\nThe answer in thirty seconds\n\nSafe to say: two critical flaws in PHP were fixed on 21 October; we updated or isolated our systems; we have no evidence of compromise and review continues. Do not say '70% of the Internet', 'the most severe ever' or 'exploited everywhere'. Point people to php.net and your national agency.\n\nRead the site as Riley →\n\nWhat is true, what is not, and what you will be asked. The story most readers saw on the morning of 22 October carried three things this site could not confirm, and the questions will come from that story.\n\n## What to decide or do\n- True and safe to say: two critical flaws in PHP itself, patched on 21 October; the organisation patched or isolated its systems; no evidence of compromise as of today, review continuing.\n- Not safe to say: \"70% of the Internet\" (a headline restating a share of websites), \"the most severe ever\" (a vendor's phrase), \"exploited everywhere\" (attempts against honeypots and CDNs, no named victim), \"found by AI\" without \"by researchers using\".\n- The questions: Were you hit? (answer with the evidence window: logs reviewed from 17 October.) Did you take sites down? (precaution, not incident, as Oxford City Council put it.) Why did it take so long? (the fix was authored on 18 October and released under a coordinated plan that leaked.)\n- Attribution: three research teams and the PHP Foundation each tell the discovery story differently; do not pick one. The flaw was seen in 2024 and not fixed because exploitation could not be shown.\n- Point at primary sources: php.net's advisory and your national agency. Do not link a vendor blog as the authority.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- The numbers\n- Impact: offline vs compromised\n- The agencies\n\nChoose *read as Riley* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- the safe statement\n- the phrases to avoid\n- the questions coming\n- where to point people\n\n### What you can skip\n- the code\n- the settings\n\n\n## The facts this rests on\nShow the 32 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | 1/2 | OpenAI on X THN |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer."
    },
    {
     "v": 4,
     "hash": "66ed399a14c0",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# 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?\n\nThe 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.\n\nBriefing for Riley, communications team · ******Plain English\n\n# What can we say that is true, what should we not say, and what will we be asked?\n\nR\nThe answer in thirty seconds\n\nSafe to say: two critical flaws in PHP were fixed on 21 October; we updated or isolated our systems; we have no evidence of compromise and review continues. Do not say '70% of the Internet', 'the most severe ever' or 'exploited everywhere'. Point people to php.net and your national agency.\n\nRead the site as Riley →\n\nWhat is true, what is not, and what you will be asked. The story most readers saw on the morning of 22 October carried three things this site could not confirm, and the questions will come from that story.\n\n## What to decide or do\n- True and safe to say: two critical flaws in PHP itself, patched on 21 October; the organisation patched or isolated its systems; no evidence of compromise as of today, review continuing.\n- Not safe to say: \"70% of the Internet\" (a headline restating a share of websites), \"the most severe ever\" (a vendor's phrase), \"exploited everywhere\" (attempts against honeypots and CDNs, no named victim), \"found by AI\" without \"by researchers using\".\n- The questions: Were you hit? (answer with the evidence window: logs reviewed from 17 October.) Did you take sites down? (precaution, not incident, as Oxford City Council put it.) Why did it take so long? (the fix was authored on 18 October and released under a coordinated plan that leaked.)\n- Attribution: three research teams and the PHP Foundation each tell the discovery story differently; do not pick one. The flaw was seen in 2024 and not fixed because exploitation could not be shown.\n- Point at primary sources: php.net's advisory and your national agency. Do not link a vendor blog as the authority.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- The numbers\n- Impact: offline vs compromised\n- The agencies\n\nChoose *read as Riley* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- the safe statement\n- the phrases to avoid\n- the questions coming\n- where to point people\n\n### What you can skip\n- the code\n- the settings\n\n\n## The facts this rests on\nShow the 32 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | **A4** Corroborated●●●●○○ status overstated | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | **A3** Echoed●●●○○○ opinion measures differently status overstated | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | **A6** Established●●●●●● | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | **A2** Reported●●○○○○ disputed status overstated | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | **A3** Echoed●●●○○○ opinion measures differently | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | **A2** Reported●●○○○○ | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | **A2** Reported●●○○○○ opinion measures differently | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | **A6** Established●●●●●● | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | **A2** Reported●●○○○○ | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | **A2** Reported●●○○○○ opinion disputed | 1/2 | OpenAI on X THN |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer."
    },
    {
     "v": 5,
     "hash": "53fd082c0aac",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# 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?\n\nThe 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.\n\nBriefing for Riley, communications team · ******Plain English\n\n# What can we say that is true, what should we not say, and what will we be asked?\n\nR\nThe answer in thirty seconds\n\nSafe to say: two critical flaws in PHP were fixed on 21 October; we updated or isolated our systems; we have no evidence of compromise and review continues. Do not say '70% of the Internet', 'the most severe ever' or 'exploited everywhere'. Point people to php.net and your national agency.\n\nRead the site as Riley →\n\nWhat is true, what is not, and what you will be asked. The story most readers saw on the morning of 22 October carried three things this site could not confirm, and the questions will come from that story.\n\n## What to decide or do\n- True and safe to say: two critical flaws in PHP itself, patched on 21 October; the organisation patched or isolated its systems; no evidence of compromise as of today, review continuing.\n- Not safe to say: \"70% of the Internet\" (a headline restating a share of websites), \"the most severe ever\" (a vendor's phrase), \"exploited everywhere\" (attempts against honeypots and CDNs, no named victim), \"found by AI\" without \"by researchers using\".\n- The questions: Were you hit? (answer with the evidence window: logs reviewed from 17 October.) Did you take sites down? (precaution, not incident, as Oxford City Council put it.) Why did it take so long? (the fix was authored on 18 October and released under a coordinated plan that leaked.)\n- Attribution: three research teams and the PHP Foundation each tell the discovery story differently; do not pick one. The flaw was seen in 2024 and not fixed because exploitation could not be shown.\n- Point at primary sources: php.net's advisory and your national agency. Do not link a vendor blog as the authority.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- The numbers\n- Impact: offline vs compromised\n- The agencies\n\nChoose *read as Riley* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- the safe statement\n- the phrases to avoid\n- the questions coming\n- where to point people\n\n### What you can skip\n- the code\n- the settings\n\n\n## The facts this rests on\nShow the 32 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | **A3** Echoed●●●○○○ opinion measures differently status overstated | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | **A6** Established●●●●●● | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | **A2** Reported●●○○○○ disputed status overstated | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | **A3** Echoed●●●○○○ opinion measures differently | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | **A2** Reported●●○○○○ | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | **A2** Reported●●○○○○ opinion measures differently | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | **A6** Established●●●●●● | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | **A2** Reported●●○○○○ | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | **A2** Reported●●○○○○ opinion disputed | 1/2 | OpenAI on X THN |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer."
    },
    {
     "v": 6,
     "hash": "b92dc2d65156",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# 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?\n\nThe 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.\n\nBriefing for Riley, communications team · ******Plain English\n\n# What can we say that is true, what should we not say, and what will we be asked?\n\nR\nThe answer in thirty seconds\n\nSafe to say: two critical flaws in PHP were fixed on 21 October; we updated or isolated our systems; we have no evidence of compromise and review continues. Do not say '70% of the Internet', 'the most severe ever' or 'exploited everywhere'. Point people to php.net and your national agency.\n\nRead the site as Riley →\n\nWhat is true, what is not, and what you will be asked. The story most readers saw on the morning of 22 October carried three things this site could not confirm, and the questions will come from that story.\n\n## What to decide or do\n- True and safe to say: two critical flaws in PHP itself, patched on 21 October; the organisation patched or isolated its systems; no evidence of compromise as of today, review continuing.\n- Not safe to say: \"70% of the Internet\" (a headline restating a share of websites), \"the most severe ever\" (a vendor's phrase), \"exploited everywhere\" (attempts against honeypots and CDNs, no named victim), \"found by AI\" without \"by researchers using\".\n- The questions: Were you hit? (answer with the evidence window: logs reviewed from 17 October.) Did you take sites down? (precaution, not incident, as Oxford City Council put it.) Why did it take so long? (the fix was authored on 18 October and released under a coordinated plan that leaked.)\n- Attribution: three research teams and the PHP Foundation each tell the discovery story differently; do not pick one. The flaw was seen in 2024 and not fixed because exploitation could not be shown.\n- Point at primary sources: php.net's advisory and your national agency. Do not link a vendor blog as the authority.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- The numbers\n- Impact: offline vs compromised\n- The agencies\n\nChoose *read as Riley* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- the safe statement\n- the phrases to avoid\n- the questions coming\n- where to point people\n\n### What you can skip\n- the code\n- the settings\n\n\n## The facts this rests on\nShow the 32 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| Calif found the flaws first: discovery 1 August, hash commitment 5 August, report to PHP 11 AugustThe hash tweet is dated 5 August 2026 on X; its pre-image has not been published, so what it commits to cannot be checked. | Calif; PHP Foundation (report date) | confirmed | **A3** Echoed●●●○○○ opinion measures differently status overstated | 3/3 | Calif Ryan Austin, Calif on X PHP Foundation |\n| The GitHub advisories credit four reporters: lcfr-hax (Calif), sagitzadik-wiz (Wiz), amyb-oai (OpenAI) and tomash-areiontomash-areion is not named in the PHP Foundation's thanks and appears nowhere else on this beat. | GitHub security advisories | confirmed | **A6** Established●●●●●● | 2/3 | PHP PHP Daubois |\n| The out-of-memory issue was found in a 2024 audit by Quarkslab (funded through OSTIF and the Sovereign Tech Agency) but exploitation was not proven, so it was not fixedTwo parties agree. The Foundation calls the delay 'a structural failure'. Cloudflare lists Quarkslab among the 2026 disclosers; nobody else does. | PHP Foundation; Calif | confirmed | **A2** Reported●●○○○○ disputed status overstated | 2/2 | PHP Foundation Calif |\n| The flaws were found by researchers using frontier AI under OpenAI's Patch the Planet initiativeAll three research parties say AI was used. Calif: 'No special harness, or access to models that weren't generally available to everyone were used'. Calif does not name a model; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas; OpenAI's blog reportedly names GPT-5.6 Sol but is blocked. | BBC; OpenAI; Calif; Wiz | reported | **A3** Echoed●●●○○○ opinion measures differently | 3/4 | BBC News OpenAI on X Calif Wiz |\n| OpenAI independently reported the same root cause on 11 August, with further vectors on 18 SeptemberThe GitHub advisories credit amyb-oai among four reporters. OpenAI's own post credits Calif's discovery 'using GPT-5.6 Sol' and Wiz; an X Community Note disputes OpenAI's role. | PHP Foundation | reported | **A2** Reported●●○○○○ disputed | 2/2 | PHP Foundation PHP |\n| Wiz Research independently discovered the first flaw on 19 August and reported on 24 AugustWiz's X post says 'Wiz Research uncovers' with no credit to Calif or OpenAI; the blog thanks both. | Wiz; PHP Foundation (24 August) | reported | **A2** Reported●●○○○○ | 2/2 | Wiz PHP Foundation |\n| The most severe flaws ever detected by AIWiz's own wording is 'among the most severe vulnerabilities discovered in PHP, and arguably in software history'. OpenAI: 'one of the most impactful vulnerabilities in recent memory'. | BBC attributing Wiz | reported | **A2** Reported●●○○○○ opinion measures differently | 1/2 | BBC News Wiz |\n| Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory findingThe Foundation says the OOM signs were found while fixing one of the audit's findings, not in the audit report itself. | Quarkslab's blog; a Substack analysis | reported | **A6** Established●●●●●● | 1/2 | Quarkslab David Lopez-Kurtz |\n| Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday beforeUnverified by anyone else. | Dan Lorenc, via The Register | reported | **A2** Reported●●○○○○ | 0/1 | The Register |\n| Frontier AI found the flaw ahead of attackers, giving defenders time to prepareAmazon reports an exploit attempt against a honeypot on 17 October, four days before disclosure, from an actor whose source of exploit information is unknown. | OpenAI | disputed | **A2** Reported●●○○○○ opinion disputed | 1/2 | OpenAI on X THN |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Data protection officer · Head of AppSec · Developer."
    }
   ]
  },
  "fact-cf-millions": {
   "title": "Exploit attempts across Cloudflare's network: thousands in the ten hours before announceme",
   "kind": "fact",
   "path": "facts/cf-millions/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "faea3148c960",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTC\nWho says it: Matthew Prince, Cloudflare CEO, on X\nStatus: reported\nTopic: exploitation\nSources: x-eastdakota-php2shell-stats"
    }
   ]
  },
  "fact-imperva-none": {
   "title": "No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosur",
   "kind": "fact",
   "path": "facts/imperva-none/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "4b6064f4db32",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoring\nWho says it: Imperva Threat Research\nStatus: reported\nTopic: exploitation\nSources: imperva-blog-php2shell"
    }
   ]
  },
  "fact-huntress-none": {
   "title": "No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no pub",
   "kind": "fact",
   "path": "facts/huntress-none/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "141cc4955d07",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress\nWho says it: Huntress\nStatus: reported\nTopic: exploitation\nSources: huntress-php2shell-rapid-response"
    }
   ]
  },
  "fact-watchtowr-itw": {
   "title": "watchTowr sees active exploitation attempts and lists the flaws as exploited in the wild",
   "kind": "fact",
   "path": "facts/watchtowr-itw/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "c1ce33227e90",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "watchTowr sees active exploitation attempts and lists the flaws as exploited in the wild\nWho says it: watchTowr\nStatus: unverified\nTopic: exploitation\nSources: watchtowr-php2shell, watchtowr-php2shell-faq"
    }
   ]
  },
  "fact-no-confirmed-compromise": {
   "title": "As of 20:50 UTC on 22 October, no named organisation has said it was compromised through p",
   "kind": "fact",
   "path": "facts/no-confirmed-compromise/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "fe1f035a6a95",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "No named organisation has confirmed a compromise through php2shell\nWho says it: this site, from every captured source\nStatus: confirmed\nTopic: impact\nSources: cisa-kev-json, huntress-php2shell-rapid-response, imperva-blog-php2shell, aws-security-blog-madpot, weirdgloop-blog-php2shell"
    },
    {
     "v": 2,
     "hash": "eaa89f9d53f1",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.\nWho says it: this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October\nStatus: reported\nTopic: impact\nSources: cisa-kev-json, cisa-alert-php-20261021, huntress-php2shell-rapid-response, aws-security-blog-madpot, securityweek-first-attempts-sensors, securityweek-exploitation-days-before, recordedfuture-php2shell, imperva-blog-php2shell, weirdgloop-blog-php2shell"
    }
   ]
  },
  "fact-pocs-wrong": {
   "title": "None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechani",
   "kind": "fact",
   "path": "facts/pocs-wrong/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "c089dcd39151",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200\nWho says it: rjmendez (detection author) citing VulnCheck; Huntress\nStatus: reported\nTopic: technical\nSources: github-rjmendez-phpup-2026, huntress-php2shell-rapid-response"
    }
   ]
  },
  "fact-ac-high": {
   "title": "Triggering the bug is much easier than turning it into code execution; the CVSS vector say",
   "kind": "fact",
   "path": "facts/ac-high/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "efc10b318c57",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity high\nWho says it: Imperva; Fastly; the CVE record\nStatus: confirmed\nTopic: technical\nSources: imperva-blog-php2shell, fastly-blog-php2shell, cve-cve-2026-109618"
    }
   ]
  },
  "fact-fix-authored": {
   "title": "The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 U",
   "kind": "fact",
   "path": "facts/fix-authored/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "f368aa50de01",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTC\nWho says it: php/php-src commit 3584a98bd, read from a clone\nStatus: confirmed\nTopic: timing\nSources: github-php-src-fix-commit-3584a98bd, github-php-src-tag-php-8.5.12"
    }
   ]
  },
  "fact-fix-engine": {
   "title": "Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on o",
   "kind": "fact",
   "path": "facts/fix-engine/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "6d5543f92e8c",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed request\nWho says it: php/php-src fix commit; the GitHub advisories\nStatus: confirmed\nTopic: technical\nSources: github-php-src-fix-commit-3584a98bd, github-ghsa-w8hw-w9fx-j79w, github-ghsa-6wmf-4rv5-p3rp"
    }
   ]
  },
  "fact-more-paths": {
   "title": "Patching the demonstrated paths does not make the bailout mechanism safe; more paths shoul",
   "kind": "fact",
   "path": "facts/more-paths/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "706f5b366644",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expected\nWho says it: Fastly\nStatus: reported\nTopic: technical\nSources: fastly-blog-php2shell, openwall-oss-security-109619-thread"
    }
   ]
  },
  "fact-waf-nine-hours": {
   "title": "Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akam",
   "kind": "fact",
   "path": "facts/waf-nine-hours/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "b5ba9318dfcc",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 October\nWho says it: the vendors\nStatus: confirmed\nTopic: advice\nSources: cloudflare-blog-php2shell-waf, imperva-blog-php2shell, akamai-blog-php-core-rce, fastly-blog-php2shell, fortinet-fortiweb-php2shell"
    }
   ]
  },
  "fact-nl-offline": {
   "title": "The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and O",
   "kind": "fact",
   "path": "facts/nl-offline/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "ba2a46704c1f",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those services\nWho says it: the Dutch government\nStatus: confirmed\nTopic: impact\nSources: rijksoverheid-ncsc-php-news, dutchitleaders-websites-offline"
    }
   ]
  },
  "fact-fi-offline": {
   "title": "Finland's state IT provider Valtori restricted public traffic to government web services f",
   "kind": "fact",
   "path": "facts/fi-offline/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "ced3b762c743",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution\nWho says it: Yle; Helsinki Times, quoting Valtori\nStatus: reported\nTopic: impact\nSources: yle-finland-government-sites-shut, helsinkitimes-finland-shutdown"
    }
   ]
  },
  "fact-wikimedia-precaution": {
   "title": "The Wikimedia Foundation took down a number of systems 'as a precautionary measure until t",
   "kind": "fact",
   "path": "facts/wikimedia-precaution/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "739e4afa5ab7",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'\nWho says it: the Foundation, as quoted by CNN and The Cyber Express\nStatus: reported\nTopic: impact\nSources: cnn-php2shell-websites-shut, cyberexpress-php2shell-gov-sites"
    }
   ]
  },
  "fact-weirdgloop-13h": {
   "title": "Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of pag",
   "kind": "fact",
   "path": "facts/weirdgloop-13h/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "4d82869f9452",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cache\nWho says it: Weird Gloop\nStatus: confirmed\nTopic: impact\nSources: weirdgloop-blog-php2shell"
    }
   ]
  },
  "fact-edinburgh": {
   "title": "Edinburgh council's site went offline late on 21 October; the council called it 'essential",
   "kind": "fact",
   "path": "facts/edinburgh/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "d4dca1b4912c",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link\nWho says it: The Scotsman quoting the council\nStatus: reported\nTopic: impact\nSources: scotsman-edinburgh-council-offline"
    }
   ]
  },
  "fact-oxford": {
   "title": "Oxford City Council: 'a precaution because of a worldwide issue with the underlying techno",
   "kind": "fact",
   "path": "facts/oxford/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "382eb09c747c",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident'\nWho says it: the council's social post, via Oxford Chronicle\nStatus: reported\nTopic: impact\nSources: oxfordchronicle-councils-offline"
    }
   ]
  },
  "fact-uk-list": {
   "title": "Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility wer",
   "kind": "fact",
   "path": "facts/uk-list/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "16c9b98771af",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors\nWho says it: LBC; Insurance Business\nStatus: reported\nTopic: impact\nSources: lbc-uk-websites-offline, insurancebusiness-uk-councils-met"
    }
   ]
  },
  "fact-quarkslab-redacted": {
   "title": "Quarkslab's published audit summary lists 27 findings, two redacted because their fixes we",
   "kind": "fact",
   "path": "facts/quarkslab-redacted/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "28d878d18f8b",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Quarkslab's published audit summary lists 27 findings, two redacted because their fixes were complex and in progress; it does not describe an out-of-memory finding\nWho says it: Quarkslab's blog; a Substack analysis\nStatus: reported\nTopic: discovery\nSources: quarkslab-blog-php-src-audit, substack-lopezkurtz-patch-is-the-exploit"
    }
   ]
  },
  "fact-lorenc-ai-found": {
   "title": "Chainguard's team found the same bugs independently with an AI harness and a frontier mode",
   "kind": "fact",
   "path": "facts/lorenc-ai-found/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "c6a216f4307e",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "Chainguard's team found the same bugs independently with an AI harness and a frontier model after a researcher warned them on the Friday before\nWho says it: Dan Lorenc, via The Register\nStatus: reported\nTopic: discovery\nSources: theregister-php-blames-chainguard"
    }
   ]
  },
  "fact-kev-precedent": {
   "title": "The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure a",
   "kind": "fact",
   "path": "facts/kev-precedent/index.html",
   "scope": "fact",
   "versions": [
    {
     "v": 1,
     "hash": "08f2a16b8abc",
     "site": "0.2.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one day\nWho says it: CISA KEV catalog; Akamai (2024)\nStatus: confirmed\nTopic: exploitation\nSources: cisa-kev-json, cve-cve-2024-4577, akamai-blog-cve-2024-4577-one-day"
    }
   ]
  },
  "page-explained": {
   "title": "Explained from the start",
   "kind": "page",
   "path": "explained/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "8f318573a69d",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# php2shell, explained from scratch\n\nNo 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.\n\nStart here · ******Plain English\n\n# php2shell, explained from scratch\n\nNo technical background assumed. Seven short answers, in the order people usually ask them, each linking to the page with the evidence. Words in the dotted underline are explained when you hover or tap them.\n\nWhat is PHP?What went wrong?Why php2shell?What are the numbers?Why did sites go offline?Was anyone hacked?What happens now?How to read this site\n\n## 1. What is PHP, and is it on my computer?\n\nPHP is a programming language for websites. When you open a page on a site built with it, a program on the website's server, written in PHP, puts the page together (your name, the latest posts, the basket) and sends the result to your browser. WordPress, which runs a very large number of blogs, shops and company sites, is written in PHP; so are Drupal, Joomla, Moodle, Magento and the software behind Wikipedia.\n\n**PHP runs on servers, not on your phone or laptop.** This story is about the organisations that run websites. Visitors are affected only indirectly: if a site they use is broken into, or is taken offline as a precaution.\n\nA normal visitYour browserasks for a page→The website's server, running PHPbuilds the page→Database and filesthe site's content and settings\n\n## 2. What went wrong?\n\nTwo bugs were found deep inside PHP itself, not in any one website. Both are in how PHP cleans up after something goes wrong while it is handling a request.\n\nAn analogy. Think of PHP as the kitchen behind every page a website serves. When an order is impossible (it needs more than the kitchen is allowed to use), the cook abandons it. The flaws are in how the kitchen abandons and tidies up: in some cases it leaves the counter half cleared, and the next step, or the next order, uses what was left as if it were fresh. A customer who knows this can send an order designed to leave exactly the right things on the counter, so that the kitchen ends up following the customer's instructions instead of the menu.\n\nThe attackAnyone on the internetno account, no password→A crafted requestpushes PHP into its error path→The clean-up goes wrongleftover memory is trusted→The attacker's commands runon the server, as the website\nWhat that can reach- the website's own code and settings\n- passwords stored in those settings, such as the database's\n- files the website can read or write\n- other systems that trust this server\nWhat it does not automatically reach- systems the server is not allowed to talk to\n- passwords that were never on that server\n- your own phone or computer\n\nIn the jargon, this is *unauthenticated remote code execution*: no login needed, from anywhere, and the attacker's code runs. It is the most serious kind of flaw there is, which is why the response was so loud. The researchers proved it end to end against the most traditional way of running PHP, inside the Apache web server, before any of the website's own code had run. That last point matters: **it does not matter how well a website is written**; if PHP underneath it is unpatched, it is in scope. php.net PHP PHP\n\nThe technical version is on the two flaws, and the code itself on the code.\n\n## 3. Why is it called php2shell?\n\nSerious flaws get nicknames so people can talk about them: Heartbleed, Shellshock, Log4Shell. **php2shell** reads as *PHP to shell*. A shell is the command line an administrator types into; getting a shell on a server means being able to run commands on it. So the name is the whole attack in one word: start with a PHP website, end with a command line on its server. The US NSA wrote it PHP2Shell. NSA Cyber on X Calif\n\n## 4. What are CVE-2026-109618 and CVE-2026-109619?\n\nThey are the official names. A CVE number is a serial number for a security flaw, so that vendors, governments and journalists know they mean the same bug: CVE, the year the number was reserved, and a sequence number. Each has a public record saying what is affected and how bad it is.\n\n### CVE-2026-109618\n\nPHP running out of memory mid-request can leave memory half set up, and the clean-up that follows can be steered by an attacker. Severity 9.2 out of 10.\n\n### CVE-2026-109619\n\nLeftover settings from one visitor's request can point at memory that has been released, and the next request on the same worker uses it. Severity 9.2 out of 10.\n\nBoth are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Older versions (8.1 and before) are past their support date and got no ready-made fix. CVE record CVE record php.net\n\n## 5. Why did governments tell people to take websites offline?\n\nBecause an unpatched website with this flaw can be taken over by anyone, and updating every server takes time. The US NSA and CISA said: if you cannot update, take the system offline until you can. The UK's NCSC put that fourth on its list, after updating and temporary fixes; several European agencies said isolate it; others did not mention it at all. Dutch government services, including the DigiD login many Dutch citizens use, were taken offline as a precaution. NSA Cyber on X CISA NCSC UK Rijksoverheid / NCSC-NL\n\nTaking a site offline is a decision an organisation makes, not evidence it was attacked. The agencies page sets the sixteen sets of advice side by side.\n\n## 6. Was anyone actually hacked?\n\nNot that anyone has confirmed, as of the latest evidence this site holds. Attackers have certainly been trying: Cloudflare says it saw millions of attempts across its network, and Amazon says a decoy server was hit four days before the fix was public. But an attempt is not a success, no named organisation has said it was broken into, and the US list of flaws known to be exploited did not include either of these when last checked. That can change quickly, and this site will say so when the evidence does. Matthew Prince , Cloudflare CEO on THN CISA\n\nThe details: who went offline and who was compromised, and every sign of exploitation, in order.\n\n## 7. What happens now?\n\n- **If you only use websites:** nothing to do. Ignore messages that tell you to install anything because of this; that is a scam pattern.\n\n- **If you own a website:** ask whoever hosts it whether PHP has been updated and restarted. The website owner's briefing has the exact question to send.\n\n- **If you run systems:** update, restart, verify, and look for signs of compromise. The step-by-step list has every agency's advice in order.\n\n- **If you decide or communicate:** pick your briefing.\n\n## How to read this site\n\nEvery statement on this site carries one of five words, so you can tell a fact from a rumour at a glance:\n\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\nEvery one of those statements links to the pages it comes from, and every one of those pages was saved, dated and fingerprinted when it was read, so that it can be checked later even if the original changes. How that works."
    },
    {
     "v": 2,
     "hash": "0d755da499ad",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The PHP security flaws, explained from the start\n\nNo 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.\n\nStart here · ******Plain English\n\n# The PHP security flaws, explained from the start\n\nNo technical background assumed. Seven short answers, in the order people usually ask them, each linking to the page with the evidence. Words in the dotted underline are explained when you hover or tap them.\n\nWhat is PHP?What went wrong?Why php2shell?What are the numbers?Why did sites go offline?Was anyone hacked?What happens now?How to read this site\n\n## 1. What is PHP, and is it on my computer?\n\nPHP is a programming language for websites. When you open a page on a site built with it, a program on the website's server, written in PHP, puts the page together (your name, the latest posts, the basket) and sends the result to your browser. WordPress, which runs a very large number of blogs, shops and company sites, is written in PHP; so are Drupal, Joomla, Moodle, Magento and the software behind Wikipedia.\n\n**PHP runs on servers, not on your phone or laptop.** This story is about the organisations that run websites. Visitors are affected only indirectly: if a site they use is broken into, or is taken offline as a precaution.\n\nA normal visitYour browserasks for a page→The website's server, running PHPbuilds the page→Database and filesthe site's content and settings\n\n## 2. What went wrong?\n\nTwo bugs were found deep inside PHP itself, not in any one website. Both are in how PHP cleans up after something goes wrong while it is handling a request.\n\nAn analogy. Think of PHP as the kitchen behind every page a website serves. When an order is impossible (it needs more than the kitchen is allowed to use), the cook abandons it. The flaws are in how the kitchen abandons and tidies up: in some cases it leaves the counter half cleared, and the next step, or the next order, uses what was left as if it were fresh. A customer who knows this can send an order designed to leave exactly the right things on the counter, so that the kitchen ends up following the customer's instructions instead of the menu.\n\nThe attackAnyone on the internetno account, no password→A crafted requestpushes PHP into its error path→The clean-up goes wrongleftover memory is trusted→The attacker's commands runon the server, as the website\nWhat that can reach- the website's own code and settings\n- passwords stored in those settings, such as the database's\n- files the website can read or write\n- other systems that trust this server\nWhat it does not automatically reach- systems the server is not allowed to talk to\n- passwords that were never on that server\n- your own phone or computer\n\nIn the jargon, this is *unauthenticated remote code execution*: no login needed, from anywhere, and the attacker's code runs. It is the most serious kind of flaw there is, which is why the response was so loud. The researchers proved it end to end against the most traditional way of running PHP, inside the Apache web server, before any of the website's own code had run. That last point matters: **it does not matter how well a website is written**; if PHP underneath it is unpatched, it is in scope. php.net PHP PHP\n\nThe technical version is on the two flaws, and the code itself on the code.\n\n## 3. Why is it called php2shell?\n\nSerious flaws get nicknames so people can talk about them: Heartbleed, Shellshock, Log4Shell. **php2shell** reads as *PHP to shell*. A shell is the command line an administrator types into; getting a shell on a server means being able to run commands on it. So the name is the whole attack in one word: start with a PHP website, end with a command line on its server. The US NSA wrote it PHP2Shell. NSA Cyber on X Calif\n\n## 4. What are CVE-2026-109618 and CVE-2026-109619?\n\nThey are the official names. A CVE number is a serial number for a security flaw, so that vendors, governments and journalists know they mean the same bug: CVE, the year the number was reserved, and a sequence number. Each has a public record saying what is affected and how bad it is.\n\n### CVE-2026-109618\n\nPHP running out of memory mid-request can leave memory half set up, and the clean-up that follows can be steered by an attacker. Severity 9.2 out of 10.\n\n### CVE-2026-109619\n\nLeftover settings from one visitor's request can point at memory that has been released, and the next request on the same worker uses it. Severity 9.2 out of 10.\n\nBoth are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Older versions (8.1 and before) are past their support date and got no ready-made fix. CVE record CVE record php.net\n\n## 5. Why did governments tell people to take websites offline?\n\nBecause an unpatched website with this flaw can be taken over by anyone, and updating every server takes time. The US NSA and CISA said: if you cannot update, take the system offline until you can. The UK's NCSC put that fourth on its list, after updating and temporary fixes; several European agencies said isolate it; others did not mention it at all. Dutch government services, including the DigiD login many Dutch citizens use, were taken offline as a precaution. NSA Cyber on X CISA NCSC UK Rijksoverheid / NCSC-NL\n\nTaking a site offline is a decision an organisation makes, not evidence it was attacked. The agencies page sets the sixteen sets of advice side by side.\n\n## 6. Was anyone actually hacked?\n\nNot that anyone has confirmed, as of the latest evidence this site holds. Attackers have certainly been trying: Cloudflare says it saw millions of attempts across its network, and Amazon says a decoy server was hit four days before the fix was public. But an attempt is not a success, no named organisation has said it was broken into, and the US list of flaws known to be exploited did not include either of these when last checked. That can change quickly, and this site will say so when the evidence does. Matthew Prince, Cloudflare CEO on… THN CISA\n\nThe details: who went offline and who was compromised, and every sign of exploitation, in order.\n\n## 7. What happens now?\n\n- **If you only use websites:** nothing to do. Ignore messages that tell you to install anything because of this; that is a scam pattern.\n\n- **If you own a website:** ask whoever hosts it whether PHP has been updated and restarted. The website owner's briefing has the exact question to send.\n\n- **If you run systems:** update, restart, verify, and look for signs of compromise. The step-by-step list has every agency's advice in order.\n\n- **If you decide or communicate:** pick your briefing.\n\n## How to read this site\n\nEvery statement on this site carries one of five words, so you can tell a fact from a rumour at a glance:\n\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\nEvery one of those statements links to the pages it comes from, and every one of those pages was saved, dated and fingerprinted when it was read, so that it can be checked later even if the original changes. How that works."
    }
   ]
  },
  "page-glossary": {
   "title": "Glossary: every term, in plain English",
   "kind": "page",
   "path": "glossary/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "93f61a98bd6d",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Glossary: every php2shell term in plain English\n\n40 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.\n\nStart here · ******Plain English\n\n# Glossary: every term, in plain English\n\n40 words this story cannot avoid, each explained for someone who has never worked in security, and each in the sense it has in this story. On every other page, the first use of each of these words is underlined and links here.\n\nBCEGHKLMNOPRSUVWZ\n\n## B\n\n### Backport\n\nA fix copied to an older version. PHP published source-only backports for 7.4, 8.0 and 8.1, with no official release.\n\nWhen software is out of support, its maintainers usually stop fixing it. For php2shell the PHP project published the fix as source code for 7.4, 8.0 and 8.1 but no ready-to-install release, so anyone on those versions has to build it themselves or rely on a Linux distribution that does.\n\nWhere it matters in this story →\n\n## C\n\n### CDN\n\nContent delivery network: a service such as Cloudflare or Akamai that sits in front of many websites, caching pages and filtering traffic.\n\nA CDN keeps copies of a website's pages close to its visitors and screens the traffic on the way in. Because so much of the web sits behind a few CDNs, their firewall rules protected many sites before their owners did anything.\n\nWhere it matters in this story →\n\n### CERT\n\nComputer Emergency Response Team: a national or sector body that coordinates the response to cyber incidents.\n\nCERT-EU, CERT-FR, CERT.LV and JPCERT/CC are examples. They publish alerts, collect reports of attacks and advise organisations in their country or sector.\n\nWhere it matters in this story →\n\n### CISA\n\nThe US Cybersecurity and Infrastructure Security Agency.\n\nCISA is the US federal agency responsible for civilian cyber defence. It told organisations to take PHP systems offline if they could not patch, and keeps the KEV catalog.\n\nWhere it matters in this story → · the authority ↗\n\n### Confirmed, reported, disputed, unverified\n\nThe five words this site uses for how far a claim can be trusted.\n\nConfirmed: two or more primary sources agree, or the site counted it from a captured file. Reported: one party says so and nobody has contradicted it. Disputed: sources disagree, and both readings are shown. Contradicted: a primary source says otherwise. Unverified: even the outlet reporting it could not check it.\n\nWhere it matters in this story →\n\n### Coordinated disclosure\n\nKeeping a flaw secret between the finders and the maintainers until a fix is ready, then publishing both at an agreed time.\n\nThe agreed time is the embargo. For php2shell it was set for 22 October at 14:00 UTC. The CVE numbers leaked on 20 October, so the release was moved forward a day. The leak page reconstructs how.\n\nWhere it matters in this story →\n\n### CVE\n\nCommon Vulnerabilities and Exposures: the public catalogue that gives each known security flaw a unique ID, such as CVE-2026-109618.\n\nA CVE ID is a serial number for a security flaw, so that a vendor, a government agency and a journalist can be sure they are talking about the same bug. The format is CVE, the year the number was reserved, and a sequence number. This story has two: CVE-2026-109618 and CVE-2026-109619. Each has an official record that says what is affected and how severe it is.\n\nWhere it matters in this story → · the authority ↗\n\n### CVSS\n\nCommon Vulnerability Scoring System: a severity score from 0 to 10. Both flaws score 9.2, which is rated critical.\n\nCVSS turns the technical details of a flaw (can it be reached over the internet, does the attacker need a password, what can they do afterwards) into one number from 0 to 10. Anything from 9.0 up is critical. Both php2shell flaws are 9.2 under version 4.0 of the scale. The leaked early reports said 10.0, which was wrong.\n\nWhere it matters in this story → · the authority ↗\n\n### CWE\n\nCommon Weakness Enumeration: a catalogue of kinds of software weakness (the bug class), as opposed to CVE, which names one flaw.\n\nWhere a CVE names one specific flaw, a CWE names the type of mistake behind it, such as use-after-free (CWE-416). The php2shell records list five.\n\nWhere it matters in this story → · the authority ↗\n\n## E\n\n### End of life\n\nA version the maintainers no longer fix. PHP 8.1 and older are end of life.\n\nSoftware versions have a support window. After it ends, security fixes stop. PHP 8.1 and older are past theirs, so for organisations still on them php2shell is a migration project rather than an update.\n\nWhere it matters in this story →\n\n### ENISA\n\nThe European Union Agency for Cybersecurity.\n\nENISA coordinates the EU's network of national response teams. Its advice on php2shell is one of the sixteen compared on the agencies page.\n\nWhere it matters in this story →\n\n### Evidence vault\n\nThis site's private, encrypted store of every source it captured, each file hashed at the moment of capture.\n\nEvery page this site cites was saved, as served and as rendered, with a screenshot, into an encrypted vault. The pages themselves are not republished (they belong to their authors), but their fingerprints (hashes) are, so anyone can later check that nothing was changed.\n\nWhere it matters in this story →\n\n### Exploit, exploitation\n\nTo exploit a flaw is to actually use it in an attack. Exploitation attempts are tries; a compromise is a success.\n\nAn exploit is the code or technique that turns a vulnerability into an attack. This site keeps three things apart: an exploit existing, attempts being seen (requests that look like the attack), and a confirmed compromise (a named system actually broken into). For php2shell, the first two are reported; the third has not been confirmed anywhere as of the latest capture.\n\nWhere it matters in this story →\n\n## G\n\n### GitHub advisory (GHSA)\n\nThe security advisory the PHP project published on GitHub, with an ID starting GHSA. The most detailed primary record.\n\nThe PHP project publishes its security advisories on GitHub. Each has a GHSA identifier alongside its CVE. The two php2shell advisories carry the technical detail, the credits and the PHP team's own account of what was demonstrated.\n\nWhere it matters in this story →\n\n## H\n\n### Hash (SHA-256)\n\nA fingerprint of a file: change one byte and the hash changes, so a published hash proves later that a capture was not edited.\n\nA SHA-256 hash is a 64-character fingerprint computed from a file's contents. Two different files practically never share one. Publishing the hash of every capture is how this site lets readers check its evidence without republishing other people's pages.\n\nWhere it matters in this story →\n\n### Honeypot\n\nA decoy system set up to attract and record attacks.\n\nA honeypot looks like a real, vulnerable server and exists only to be attacked, so its owner can see what attackers are trying. Amazon reports one was hit with a php2shell-shaped request four days before disclosure.\n\nWhere it matters in this story →\n\n## K\n\n### KEV\n\nCISA's public list of flaws with reliable evidence of exploitation in the wild. Neither php2shell CVE was on it at the latest capture.\n\nThe Known Exploited Vulnerabilities catalog is maintained by the US agency CISA. A flaw goes on it when CISA has reliable evidence attackers are using it. It is the closest thing to an official, dated record of 'this was exploited', which is why this site checks it.\n\nWhere it matters in this story → · the authority ↗\n\n## L\n\n### longjmp\n\nA C function that jumps out of the middle of running code without tidying up. PHP used it to abort on out-of-memory; the fix removes that.\n\nlongjmp is a low-level C mechanism for leaving a function in a hurry. It is fast and it skips cleanup, which is exactly the problem: PHP used it when a request ran out of memory, and the half-finished state it left behind is what the first flaw abuses.\n\nWhere it matters in this story →\n\n## M\n\n### mod_php\n\nPHP running inside the Apache web server. The setup where a complete exploit was demonstrated; php.net ranks it highest risk.\n\nmod_php loads PHP directly into the Apache web server process. It is the oldest and simplest way to run PHP, still common on shared hosting, and the one the researchers exploited end to end before any application code ran.\n\nWhere it matters in this story →\n\n### Multipart\n\nThe format a browser uses to send a form with a file upload. Limiting multipart requests is one of the stopgaps.\n\nWhen you attach a file to a web form, the browser sends a multipart request. One of the demonstrated attack paths rides on PHP's handling of such requests, which is why some agencies suggest blocking or monitoring them at the edge where uploads are not needed.\n\nWhere it matters in this story →\n\n## N\n\n### NCSC\n\nNational Cyber Security Centre: the name of the national cyber agency in the UK, the Netherlands (NCSC-NL) and New Zealand.\n\nSeveral countries call their national cyber agency the NCSC. On this site NCSC UK, NCSC-NL and NCSC New Zealand are kept apart, because they gave different advice.\n\nWhere it matters in this story →\n\n### NSA\n\nThe US National Security Agency, whose cybersecurity arm issues advice to defenders.\n\nThe NSA's cybersecurity directorate publishes advice to US defence and critical-infrastructure organisations. Its post on X telling organisations that could not patch to take systems offline was one of the most widely shared pieces of advice in the story.\n\nWhere it matters in this story →\n\n## O\n\n### Out of memory (OOM)\n\nWhat happens when a program tries to use more memory than it is allowed. One flaw is in how PHP handles this.\n\nPHP sets a memory limit for each request. When a request hits it, PHP abandons the request. The first flaw (CVE-2026-109618) is that this abandonment could leave memory half set up, and the cleanup that follows could be steered by an attacker.\n\nWhere it matters in this story →\n\n## P\n\n### Patch\n\nAn update that fixes a flaw. For PHP it means installing a fixed version and restarting PHP.\n\nA patch is the fix. For php2shell the fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or a Linux distribution's updated package. Installing it is not enough on its own: PHP has to be restarted (and containers rebuilt) before the running server is actually fixed.\n\nWhere it matters in this story →\n\n### PHP\n\nA programming language that runs on web servers and builds the pages you see. WordPress, Drupal and Wikipedia's software are written in it.\n\nPHP is the language a large share of websites are written in. When you open a WordPress blog or a council website, a program on the server written in PHP builds the page and sends it to your browser. You never install PHP on your phone or laptop; it lives on the server. That is why this story is about websites and the organisations that run them, not about personal devices.\n\nWhere it matters in this story → · the authority ↗\n\n### PHP-FPM\n\nPHP running as a separate pool of worker processes behind a web server such as nginx. Susceptible; whether a full exploit exists is disputed.\n\nFPM (FastCGI Process Manager) is the most common modern way to run PHP behind nginx or a load balancer. The PHP project says FPM is susceptible; the two primary accounts differ on whether a complete exploit against it for the first flaw has been demonstrated.\n\nWhere it matters in this story →\n\n### php2shell\n\nThe nickname for these two flaws: from PHP to a shell, meaning an attacker can get a command line on the web server.\n\nSecurity flaws with a big impact get nicknames so people can talk about them (Heartbleed, Shellshock, Log4Shell). php2shell reads as PHP to shell: send a request to a PHP website, and come away with a shell, a command line on the server. The NSA wrote it PHP2Shell. The official names are the two CVE numbers.\n\nWhere it matters in this story →\n\n### Primary source\n\nThe party's own words: the CVE record, the vendor's advisory, the agency's page. Not a news report about them.\n\nThis site prefers primary sources and marks every source as primary or secondary. A claim that rests only on a news report is shown as reported until the original is found and captured.\n\nWhere it matters in this story →\n\n### Proof of concept (PoC)\n\nCode that shows a flaw can really be exploited. A public PoC makes attacks easier for others.\n\nResearchers write a proof of concept to convince the maintainers a bug is real. If it leaks or is published, less skilled attackers can reuse it. Several published php2shell PoCs reportedly do not work as published.\n\nWhere it matters in this story →\n\n## R\n\n### Remote code execution (RCE)\n\nAn attacker on the internet can make the server run commands of their choosing. The most serious kind of flaw.\n\nRemote code execution means someone who is not on your network, and may be on the other side of the world, can make your computer run their instructions. On a web server that usually means they can read what the website can read (its files, its database passwords) and use the server as a foothold. It is the worst outcome a single flaw can have, which is why the agencies reacted as they did.\n\nWhere it matters in this story →\n\n## S\n\n### SAPI\n\nServer API: the way PHP is plugged into the web server. Which one is used changes how exposed a site is.\n\nPHP can be attached to a web server in several ways: inside Apache (mod_php), as a separate pool of workers (PHP-FPM), as CGI, or through newer servers such as FrankenPHP. Each is a SAPI. The full exploit was shown against mod_php; the others are susceptible to different degrees.\n\nWhere it matters in this story →\n\n### SBOM\n\nSoftware bill of materials: a list of the components inside a piece of software.\n\nAn SBOM is the ingredient list for software. With one, an organisation can answer 'do we use PHP, and which version' in minutes instead of days, which is the first question this incident asked.\n\nWhere it matters in this story →\n\n### Shell\n\nA command line on a computer. Getting a shell on a server means being able to type commands on it.\n\nA shell is the text window where an administrator types commands. An attacker who gets a shell on a web server can run commands with whatever permissions the web server program has. It is where the nickname php2shell comes from.\n\nWhere it matters in this story →\n\n## U\n\n### Unauthenticated\n\nNo login needed: anyone who can reach the website can try the attack.\n\nMany flaws need the attacker to have an account first. An unauthenticated flaw does not: the attacker only needs to be able to send a request to the website, which for a public site means anyone on the internet.\n\nWhere it matters in this story →\n\n### Use-after-free\n\nA memory bug where a program keeps using memory after releasing it, so an attacker can control what is found there.\n\nWhen a program frees memory it promises not to use it again. If it does anyway, whatever was put there since (possibly by an attacker's request) is read as if it were trusted. The second flaw (CVE-2026-109619) is of this kind, across two requests handled by the same worker.\n\nWhere it matters in this story →\n\n## V\n\n### VEX\n\nVulnerability Exploitability eXchange: a vendor's statement of whether its product is affected by a given flaw.\n\nA VEX statement lets a vendor say 'our product contains PHP but is not affected', or 'is affected, fixed in version X'. The Dutch NCSC inventory is built from them.\n\nWhere it matters in this story →\n\n### Vulnerability\n\nA flaw in software that an attacker can use to make it do something it should not.\n\nEvery large program has bugs. A vulnerability is a bug with a security consequence: it lets someone read what they should not, change what they should not, or run their own code. This site uses vulnerability and flaw for the same thing.\n\nWhere it matters in this story →\n\n## W\n\n### WAF\n\nWeb application firewall: a filter in front of a website that blocks requests that look like attacks. A stopgap here, not a fix.\n\nA WAF inspects every request before it reaches the website and drops the ones that match known attack patterns. Cloudflare, Akamai, Fastly, Imperva, AWS and others shipped rules for php2shell, some before the fix was public. Every one of them says the same thing: it buys time, it does not replace patching.\n\nWhere it matters in this story →\n\n### Web server\n\nThe computer, and the program on it, that answers when a browser asks for a page. PHP runs there, not on your device.\n\nWhen you type an address into a browser, a web server somewhere receives the request and sends back the page. For PHP websites, the web server hands the request to PHP, which builds the page. Both flaws are reached by sending that server a specially crafted request.\n\nWhere it matters in this story →\n\n## Z\n\n### Zend engine\n\nThe core of PHP, written in C, that runs PHP code. Both flaws are here, below every PHP application.\n\nThe Zend engine is the part of PHP that reads PHP code and executes it, manages memory and handles errors. Because the flaws are in the engine, it does not matter how well the website's own code is written: any site on an unpatched PHP is in scope.\n\nWhere it matters in this story →"
    }
   ]
  },
  "briefing-everyone": {
   "title": "Briefing: Curious reader",
   "kind": "briefing",
   "path": "briefings/everyone/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "bd09cd37a4bf",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a curious reader: What happened, does it affect me, and should I worry?\n\nThe 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.\n\nBriefing for Alex, curious reader · ******Plain English\n\n# What happened, does it affect me, and should I worry?\n\nA\nThe answer in thirty seconds\n\nTwo serious holes were found in PHP, software that runs on the servers behind a large share of websites. They were fixed on 21 October 2026. Your phone and laptop are not the target: websites are, and it is the job of whoever runs them to update. Some sites were taken offline as a precaution. No organisation has confirmed being broken into as of the latest evidence.\n\nRead the site as Alex →\n\nYou do not need to know anything about computers to follow this. Below are the five things worth knowing, then the evidence behind them, folded away until you want it.\n\n## What to decide or do\n- **PHP is not on your phone or laptop.** It runs on the servers that build websites. This is a problem for the organisations that run those websites, and it is theirs to fix.\n- **Nothing to install, nothing to change** on your own devices because of this. Be wary of any message that says otherwise and asks you to click or download something: scammers use headlines like this one.\n- **If a website you use was down on 21 or 22 October, it was most likely a precaution.** Dutch government services such as DigiD were taken offline on purpose, as a precaution; that is a decision, not a sign of a break-in.\n- **Nobody has confirmed being hacked through this yet.** Attackers have been trying, in large numbers, and that may change; this site will say so when the evidence does.\n- **The big numbers in the headlines are not what they sound like.** 70% is roughly the share of websites built with PHP, not a share of the Internet that is broken. The numbers page explains each one.\n\n## Your reading path\n- Your briefing\n- Explained from scratch\n- Impact: offline vs compromised\n- The numbers\n\nChoose *read as Alex* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- what PHP is, in one sentence\n- whether their own phone or laptop is at risk\n- why websites went offline\n- whether anyone was actually hacked\n\n### What you can skip\n- version numbers\n- server settings\n- the code\n\n\n## The facts this rests on\nShow the 29 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 2,
     "hash": "6cdf88d6fa32",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a curious reader: What happened, does it affect me, and should I worry?\n\nThe 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.\n\nBriefing for Alex, curious reader · ******Plain English\n\n# What happened, does it affect me, and should I worry?\n\nA\nThe answer in thirty seconds\n\nTwo serious holes were found in PHP, software that runs on the servers behind a large share of websites. They were fixed on 21 October 2026. Your phone and laptop are not the target: websites are, and it is the job of whoever runs them to update. Some sites were taken offline as a precaution. No organisation has confirmed being broken into as of the latest evidence.\n\nRead the site as Alex →\n\nYou do not need to know anything about computers to follow this. Below are the five things worth knowing, then the evidence behind them, folded away until you want it.\n\n## What to decide or do\n- **PHP is not on your phone or laptop.** It runs on the servers that build websites. This is a problem for the organisations that run those websites, and it is theirs to fix.\n- **Nothing to install, nothing to change** on your own devices because of this. Be wary of any message that says otherwise and asks you to click or download something: scammers use headlines like this one.\n- **If a website you use was down on 21 or 22 October, it was most likely a precaution.** Dutch government services such as DigiD were taken offline on purpose, as a precaution; that is a decision, not a sign of a break-in.\n- **Nobody has confirmed being hacked through this yet.** Attackers have been trying, in large numbers, and that may change; this site will say so when the evidence does.\n- **The big numbers in the headlines are not what they sound like.** 70% is roughly the share of websites built with PHP, not a share of the Internet that is broken. The numbers page explains each one.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The numbers\n\nChoose *read as Alex* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- what PHP is, in one sentence\n- whether their own phone or laptop is at risk\n- why websites went offline\n- whether anyone was actually hacked\n\n### What you can skip\n- version numbers\n- server settings\n- the code\n\n\n## The facts this rests on\nShow the 29 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | 2/3 | Wiz Wiz on X BBC News |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 3,
     "hash": "1645c9801ab9",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a curious reader: What happened, does it affect me, and should I worry?\n\nThe 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.\n\nBriefing for Alex, curious reader · ******Plain English\n\n# What happened, does it affect me, and should I worry?\n\nA\nThe answer in thirty seconds\n\nTwo serious holes were found in PHP, software that runs on the servers behind a large share of websites. They were fixed on 21 October 2026. Your phone and laptop are not the target: websites are, and it is the job of whoever runs them to update. Some sites were taken offline as a precaution. No organisation has confirmed being broken into as of the latest evidence.\n\nRead the site as Alex →\n\nYou do not need to know anything about computers to follow this. Below are the five things worth knowing, then the evidence behind them, folded away until you want it.\n\n## What to decide or do\n- **PHP is not on your phone or laptop.** It runs on the servers that build websites. This is a problem for the organisations that run those websites, and it is theirs to fix.\n- **Nothing to install, nothing to change** on your own devices because of this. Be wary of any message that says otherwise and asks you to click or download something: scammers use headlines like this one.\n- **If a website you use was down on 21 or 22 October, it was most likely a precaution.** Dutch government services such as DigiD were taken offline on purpose, as a precaution; that is a decision, not a sign of a break-in.\n- **Nobody has confirmed being hacked through this yet.** Attackers have been trying, in large numbers, and that may change; this site will say so when the evidence does.\n- **The big numbers in the headlines are not what they sound like.** 70% is roughly the share of websites built with PHP, not a share of the Internet that is broken. The numbers page explains each one.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The numbers\n\nChoose *read as Alex* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- what PHP is, in one sentence\n- whether their own phone or laptop is at risk\n- why websites went offline\n- whether anyone was actually hacked\n\n### What you can skip\n- version numbers\n- server settings\n- the code\n\n\n## The facts this rests on\nShow the 29 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | **A4** Corroborated●●●●○○ status overstated | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "7bfa1384b3f4",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a curious reader: What happened, does it affect me, and should I worry?\n\nThe 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.\n\nBriefing for Alex, curious reader · ******Plain English\n\n# What happened, does it affect me, and should I worry?\n\nA\nThe answer in thirty seconds\n\nTwo serious holes were found in PHP, software that runs on the servers behind a large share of websites. They were fixed on 21 October 2026. Your phone and laptop are not the target: websites are, and it is the job of whoever runs them to update. Some sites were taken offline as a precaution. As of the evening of 22 October, no named organisation has said it was compromised through php2shell.\n\nRead the site as Alex →\n\nYou do not need to know anything about computers to follow this. Below are the five things worth knowing, then the evidence behind them, folded away until you want it.\n\n## What to decide or do\n- **PHP is not on your phone or laptop.** It runs on the servers that build websites. This is a problem for the organisations that run those websites, and it is theirs to fix.\n- **Nothing to install, nothing to change** on your own devices because of this. Be wary of any message that says otherwise and asks you to click or download something: scammers use headlines like this one.\n- **If a website you use was down on 21 or 22 October, it was most likely a precaution.** Dutch government services such as DigiD were taken offline on purpose, as a precaution; that is a decision, not a sign of a break-in.\n- **Nobody has confirmed being hacked through this yet.** Attackers have been trying, in large numbers, and that may change; this site will say so when the evidence does.\n- **The big numbers in the headlines are not what they sound like.** 70% is roughly the share of websites built with PHP, not a share of the Internet that is broken. The numbers page explains each one.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The numbers\n\nChoose *read as Alex* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- what PHP is, in one sentence\n- whether their own phone or laptop is at risk\n- why websites went offline\n- whether anyone was actually hacked\n\n### What you can skip\n- version numbers\n- server settings\n- the code\n\n\n## The facts this rests on\nShow the 29 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 5,
     "hash": "b8f727de962f",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a curious reader: What happened, does it affect me, and should I worry?\n\nThe 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.\n\nBriefing for Alex, curious reader · ******Plain English\n\n# What happened, does it affect me, and should I worry?\n\nA\nThe answer in thirty seconds\n\nTwo serious holes were found in PHP, software that runs on the servers behind a large share of websites. They were fixed on 21 October 2026. Your phone and laptop are not the target: websites are, and it is the job of whoever runs them to update. Some sites were taken offline as a precaution. As of the evening of 22 October, no named organisation has said it was compromised through php2shell.\n\nRead the site as Alex →\n\nYou do not need to know anything about computers to follow this. Below are the five things worth knowing, then the evidence behind them, folded away until you want it.\n\n## What to decide or do\n- **PHP is not on your phone or laptop.** It runs on the servers that build websites. This is a problem for the organisations that run those websites, and it is theirs to fix.\n- **Nothing to install, nothing to change** on your own devices because of this. Be wary of any message that says otherwise and asks you to click or download something: scammers use headlines like this one.\n- **If a website you use was down on 21 or 22 October, it was most likely a precaution.** Dutch government services such as DigiD were taken offline on purpose, as a precaution; that is a decision, not a sign of a break-in.\n- **Nobody has confirmed being hacked through this yet.** Attackers have been trying, in large numbers, and that may change; this site will say so when the evidence does.\n- **The big numbers in the headlines are not what they sound like.** 70% is roughly the share of websites built with PHP, not a share of the Internet that is broken. The numbers page explains each one.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- Impact: offline vs compromised\n- The numbers\n\nChoose *read as Alex* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- what PHP is, in one sentence\n- whether their own phone or laptop is at risk\n- why websites went offline\n- whether anyone was actually hacked\n\n### What you can skip\n- version numbers\n- server settings\n- the code\n\n\n## The facts this rests on\nShow the 29 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| 674 products in the NCSC-NL inventory: 206 vulnerable, 46 fixed, 418 under investigation, 3 not vulnerableCounted, not quoted. NCSC-NL calls unbacked entries 'investigation leads'. | NCSC-NL, counted by this site from the file at commit cca173c64ec5 | confirmed | **A1** Weak signal●○○○○○ contradicted status overstated | 1/1 | NCSC-NL |\n| PHP is used by almost 70% of websitesNone of the three cites the survey it comes from. A share of websites using PHP is an upper bound on exposure, not a count of vulnerable systems. | Cloudflare; OpenAI ('an estimated 70%'); Wiz body text | reported | **A2** Reported●●○○○○ measures differently | 3/3 | Cloudflare OpenAI on X Wiz |\n| Something like 30 million websites could be affectedNo basis given. | Alan Woodward, via the BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| PHP is exposed on about 2.6 million internet-facing hosts, of which Censys counted 1.57 million unpatched on 21 OctoberCensys: 2.58 million hosts seen, 1.58 million reporting a version, 1.57 million not patched; nearly 3 million by 22 October. VirusTotal: 5.1 million IPs running PHP, 1.1 million announcing a version. Unit 42: 22.6 million systems that 'could be vulnerable' (via Insurance Business). Censys's own post was not found. | VulnCheck and Censys, via The Hacker News and SecurityWeek | reported | **A2** Reported●●○○○○ measures differently | 0/2 | THN SecurityWeek |\n| About 6,000 potentially affected resources in Latvia, a few hundred in the public sectorPrimary source, one country, says 'potentially'. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Roughly 70% of the Internet is affectedThe BBC was 'unable to independently verify that figure'. Wiz's body text says 70% of websites and cites no measurement. | Wiz (headline, X post); BBC attributing Wiz | unverified | **A1** Weak signal●○○○○○ measures differently | 2/3 | Wiz Wiz on X BBC News |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Data protection officer · Head of AppSec · Developer · Communications team."
    }
   ]
  },
  "briefing-site-owner": {
   "title": "Briefing: Website owner",
   "kind": "briefing",
   "path": "briefings/site-owner/index.html",
   "scope": "site-owner",
   "versions": [
    {
     "v": 1,
     "hash": "2499a410748e",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a website owner: My website runs on WordPress or similar: am I affected, and what do I ask my host?\n\nThe 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.\n\nBriefing for Casey, website owner · ******Plain English\n\n# My website runs on WordPress or similar: am I affected, and what do I ask my host?\n\nC\nThe answer in thirty seconds\n\nIf your website runs on WordPress, Drupal, Joomla or anything else written in PHP, it is in scope: the flaw is in PHP itself, underneath your site. Updating plugins does not fix it. If someone hosts the site for you, ask them in writing whether PHP has been updated to a fixed version and restarted. If you run the server yourself, update PHP today.\n\nRead the site as Casey →\n\nYou do not need to understand the bug to deal with it. What you need is to know whose job the update is, and the exact question to ask. This page gives you both.\n\n## What to decide or do\n- **Find out whether your site runs on PHP.** WordPress, WooCommerce, Drupal, Joomla, Magento, PrestaShop, Moodle and most hosting control panels do. If you are not sure, ask whoever built the site.\n- **Updating WordPress, plugins or themes does not fix this.** The flaw is in PHP itself, one layer down. It has to be fixed on the server.\n- **If someone hosts the site for you**, send them this, in writing: *Has PHP on the server running my site been updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's fixed package, and have the PHP processes been restarted since? If my site is on PHP 8.1 or older, what is your plan?* Keep the reply.\n- **If you run the server yourself**, update PHP today and restart it. The step-by-step list has the temporary settings for a server you cannot update straight away.\n- **If your site is on PHP 8.1 or older**, there is no ready-made fix. Ask your developer or host about moving to a supported version now; it is overdue anyway.\n- **Keep calm about being hacked.** No organisation has confirmed a break-in as of the latest capture. If your host updated promptly, you are in the same position as almost everyone else.\n\n## Your reading path\n- Your briefing\n- Explained from scratch\n- If you run PHP\n- Affected systems\n\nChoose *read as Casey* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- am I affected\n- is it my job or my host's\n- exactly what to ask the host\n- whether updating WordPress plugins helps\n\n### What you can skip\n- the code\n- the disclosure politics\n- the agency comparison\n\n\n## The facts this rests on\nShow the 33 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src , read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince , Cloudflare CEO on |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 2,
     "hash": "6c007b7ba566",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a website owner: My website runs on WordPress or similar: am I affected, and what do I ask my host?\n\nThe 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.\n\nBriefing for Casey, website owner · ******Plain English\n\n# My website runs on WordPress or similar: am I affected, and what do I ask my host?\n\nC\nThe answer in thirty seconds\n\nIf your website runs on WordPress, Drupal, Joomla or anything else written in PHP, it is in scope: the flaw is in PHP itself, underneath your site. Updating plugins does not fix it. If someone hosts the site for you, ask them in writing whether PHP has been updated to a fixed version and restarted. If you run the server yourself, update PHP today.\n\nRead the site as Casey →\n\nYou do not need to understand the bug to deal with it. What you need is to know whose job the update is, and the exact question to ask. This page gives you both.\n\n## What to decide or do\n- **Find out whether your site runs on PHP.** WordPress, WooCommerce, Drupal, Joomla, Magento, PrestaShop, Moodle and most hosting control panels do. If you are not sure, ask whoever built the site.\n- **Updating WordPress, plugins or themes does not fix this.** The flaw is in PHP itself, one layer down. It has to be fixed on the server.\n- **If someone hosts the site for you**, send them this, in writing: *Has PHP on the server running my site been updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's fixed package, and have the PHP processes been restarted since? If my site is on PHP 8.1 or older, what is your plan?* Keep the reply.\n- **If you run the server yourself**, update PHP today and restart it. The step-by-step list has the temporary settings for a server you cannot update straight away.\n- **If your site is on PHP 8.1 or older**, there is no ready-made fix. Ask your developer or host about moving to a supported version now; it is overdue anyway.\n- **Keep calm about being hacked.** No organisation has confirmed a break-in as of the latest capture. If your host updated promptly, you are in the same position as almost everyone else.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- If you run PHP\n- Affected systems\n\nChoose *read as Casey* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- am I affected\n- is it my job or my host's\n- exactly what to ask the host\n- whether updating WordPress plugins helps\n\n### What you can skip\n- the code\n- the disclosure politics\n- the agency comparison\n\n\n## The facts this rests on\nShow the 33 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | 2/2 | watchTowr watchTowr |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 3,
     "hash": "0adbd4eea124",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a website owner: My website runs on WordPress or similar: am I affected, and what do I ask my host?\n\nThe 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.\n\nBriefing for Casey, website owner · ******Plain English\n\n# My website runs on WordPress or similar: am I affected, and what do I ask my host?\n\nC\nThe answer in thirty seconds\n\nIf your website runs on WordPress, Drupal, Joomla or anything else written in PHP, it is in scope: the flaw is in PHP itself, underneath your site. Updating plugins does not fix it. If someone hosts the site for you, ask them in writing whether PHP has been updated to a fixed version and restarted. If you run the server yourself, update PHP today.\n\nRead the site as Casey →\n\nYou do not need to understand the bug to deal with it. What you need is to know whose job the update is, and the exact question to ask. This page gives you both.\n\n## What to decide or do\n- **Find out whether your site runs on PHP.** WordPress, WooCommerce, Drupal, Joomla, Magento, PrestaShop, Moodle and most hosting control panels do. If you are not sure, ask whoever built the site.\n- **Updating WordPress, plugins or themes does not fix this.** The flaw is in PHP itself, one layer down. It has to be fixed on the server.\n- **If someone hosts the site for you**, send them this, in writing: *Has PHP on the server running my site been updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's fixed package, and have the PHP processes been restarted since? If my site is on PHP 8.1 or older, what is your plan?* Keep the reply.\n- **If you run the server yourself**, update PHP today and restart it. The step-by-step list has the temporary settings for a server you cannot update straight away.\n- **If your site is on PHP 8.1 or older**, there is no ready-made fix. Ask your developer or host about moving to a supported version now; it is overdue anyway.\n- **Keep calm about being hacked.** No organisation has confirmed a break-in as of the latest capture. If your host updated promptly, you are in the same position as almost everyone else.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- If you run PHP\n- Affected systems\n\nChoose *read as Casey* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- am I affected\n- is it my job or my host's\n- exactly what to ask the host\n- whether updating WordPress plugins helps\n\n### What you can skip\n- the code\n- the disclosure politics\n- the agency comparison\n\n\n## The facts this rests on\nShow the 33 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "a5739061da72",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a website owner: My website runs on WordPress or similar: am I affected, and what do I ask my host?\n\nThe 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.\n\nBriefing for Casey, website owner · ******Plain English\n\n# My website runs on WordPress or similar: am I affected, and what do I ask my host?\n\nC\nThe answer in thirty seconds\n\nIf your website runs on WordPress, Drupal, Joomla or anything else written in PHP, it is in scope: the flaw is in PHP itself, underneath your site. Updating plugins does not fix it. If someone hosts the site for you, ask them in writing whether PHP has been updated to a fixed version and restarted. If you run the server yourself, update PHP today.\n\nRead the site as Casey →\n\nYou do not need to understand the bug to deal with it. What you need is to know whose job the update is, and the exact question to ask. This page gives you both.\n\n## What to decide or do\n- **Find out whether your site runs on PHP.** WordPress, WooCommerce, Drupal, Joomla, Magento, PrestaShop, Moodle and most hosting control panels do. If you are not sure, ask whoever built the site.\n- **Updating WordPress, plugins or themes does not fix this.** The flaw is in PHP itself, one layer down. It has to be fixed on the server.\n- **If someone hosts the site for you**, send them this, in writing: *Has PHP on the server running my site been updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's fixed package, and have the PHP processes been restarted since? If my site is on PHP 8.1 or older, what is your plan?* Keep the reply.\n- **If you run the server yourself**, update PHP today and restart it. The step-by-step list has the temporary settings for a server you cannot update straight away.\n- **If your site is on PHP 8.1 or older**, there is no ready-made fix. Ask your developer or host about moving to a supported version now; it is overdue anyway.\n- **Keep calm about being hacked.** No organisation has confirmed a break-in as of the latest capture. If your host updated promptly, you are in the same position as almost everyone else.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- If you run PHP\n- Affected systems\n\nChoose *read as Casey* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- am I affected\n- is it my job or my host's\n- exactly what to ask the host\n- whether updating WordPress plugins helps\n\n### What you can skip\n- the code\n- the disclosure politics\n- the agency comparison\n\n\n## The facts this rests on\nShow the 33 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Data protection officer · Head of AppSec · Developer · Communications team."
    }
   ]
  },
  "briefing-pm": {
   "title": "Briefing: Project or programme manager",
   "kind": "briefing",
   "path": "briefings/pm/index.html",
   "scope": "pm",
   "versions": [
    {
     "v": 1,
     "hash": "cb0139a64a3c",
     "site": "0.3.0",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a project or programme manager: What unplanned work does this create, who do I chase, and what do I tell stakeholders?\n\nThe 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.\n\nBriefing for Taylor, project or programme manager · ******Plain English\n\n# What unplanned work does this create, who do I chase, and what do I tell stakeholders?\n\nT\nThe answer in thirty seconds\n\nExpect unplanned work this week: updating PHP on every system that uses it, restarting, and re-testing. Some teams may take systems offline for hours as a precaution. Anything still on PHP 8.1 or older has no ready-made fix and becomes a migration project. Ask each system owner for a patch date and a test plan.\n\nRead the site as Taylor →\n\nThis is a platform event, not an application bug, so it lands on every team that ships anything running on PHP at once. Plan for it the way you would plan for a datacentre move: an inventory, an owner per system, a date, a test.\n\n## What to decide or do\n- **Get the list.** Which systems run PHP, who owns each, and which are on the internet. Vendor products and hosting panels count. Without the list nothing else can be scheduled.\n- **Get a date per system.** Updating PHP means installing the fixed version, restarting, rebuilding containers and re-testing. Internet-facing systems first.\n- **Budget for regression testing.** The fix changes how PHP behaves when it runs short of memory: a system that used to limp along may now stop cleanly. Load tests are worth running before the release, not after.\n- **Plan for precautionary downtime.** Agencies advise isolating or taking offline what cannot be updated in time. Agree with stakeholders now who can make that call, how long it may last, and what users see meanwhile.\n- **Treat PHP 8.1 and older as a project.** There is no ready-made release for them. Moving to a supported version is a migration with its own scope and schedule.\n- **Expect a second round.** A report that the first fix may be incomplete is open. Keep a slot free in the next fortnight.\n\n## Your reading path\n- Your briefing\n- Explained from scratch\n- If you run PHP\n- Impact: offline vs compromised\n- Timeline\n\nChoose *read as Taylor* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- what unplanned work this creates\n- which systems and owners to chase\n- what to tell stakeholders about downtime\n- what changes after the fix\n\n### What you can skip\n- the code\n- the bug classes\n- the detection rules\n\n\n## The facts this rests on\nShow the 20 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src , read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 2,
     "hash": "9df929233524",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# Briefing for a project or programme manager: What unplanned work does this create, who do I chase, and what do I tell stakeholders?\n\nThe 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.\n\nBriefing for Taylor, project or programme manager · ******Plain English\n\n# What unplanned work does this create, who do I chase, and what do I tell stakeholders?\n\nT\nThe answer in thirty seconds\n\nExpect unplanned work this week: updating PHP on every system that uses it, restarting, and re-testing. Some teams may take systems offline for hours as a precaution. Anything still on PHP 8.1 or older has no ready-made fix and becomes a migration project. Ask each system owner for a patch date and a test plan.\n\nRead the site as Taylor →\n\nThis is a platform event, not an application bug, so it lands on every team that ships anything running on PHP at once. Plan for it the way you would plan for a datacentre move: an inventory, an owner per system, a date, a test.\n\n## What to decide or do\n- **Get the list.** Which systems run PHP, who owns each, and which are on the internet. Vendor products and hosting panels count. Without the list nothing else can be scheduled.\n- **Get a date per system.** Updating PHP means installing the fixed version, restarting, rebuilding containers and re-testing. Internet-facing systems first.\n- **Budget for regression testing.** The fix changes how PHP behaves when it runs short of memory: a system that used to limp along may now stop cleanly. Load tests are worth running before the release, not after.\n- **Plan for precautionary downtime.** Agencies advise isolating or taking offline what cannot be updated in time. Agree with stakeholders now who can make that call, how long it may last, and what users see meanwhile.\n- **Treat PHP 8.1 and older as a project.** There is no ready-made release for them. Moving to a supported version is a migration with its own scope and schedule.\n- **Expect a second round.** A report that the first fix may be incomplete is open. Keep a slot free in the next fortnight.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- If you run PHP\n- Impact: offline vs compromised\n- Timeline\n\nChoose *read as Taylor* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- what unplanned work this creates\n- which systems and owners to chase\n- what to tell stakeholders about downtime\n- what changes after the fix\n\n### What you can skip\n- the code\n- the bug classes\n- the detection rules\n\n\n## The facts this rests on\nShow the 20 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Primary | Sources |\n|---|---|---|---|---|\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | 0/2 | LBC Insurance Business |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | 2/3 | BBC News php.net php-src |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 3,
     "hash": "df9c0b0806cf",
     "site": "0.4.7",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a project or programme manager: What unplanned work does this create, who do I chase, and what do I tell stakeholders?\n\nThe 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.\n\nBriefing for Taylor, project or programme manager · ******Plain English\n\n# What unplanned work does this create, who do I chase, and what do I tell stakeholders?\n\nT\nThe answer in thirty seconds\n\nExpect unplanned work this week: updating PHP on every system that uses it, restarting, and re-testing. Some teams may take systems offline for hours as a precaution. Anything still on PHP 8.1 or older has no ready-made fix and becomes a migration project. Ask each system owner for a patch date and a test plan.\n\nRead the site as Taylor →\n\nThis is a platform event, not an application bug, so it lands on every team that ships anything running on PHP at once. Plan for it the way you would plan for a datacentre move: an inventory, an owner per system, a date, a test.\n\n## What to decide or do\n- **Get the list.** Which systems run PHP, who owns each, and which are on the internet. Vendor products and hosting panels count. Without the list nothing else can be scheduled.\n- **Get a date per system.** Updating PHP means installing the fixed version, restarting, rebuilding containers and re-testing. Internet-facing systems first.\n- **Budget for regression testing.** The fix changes how PHP behaves when it runs short of memory: a system that used to limp along may now stop cleanly. Load tests are worth running before the release, not after.\n- **Plan for precautionary downtime.** Agencies advise isolating or taking offline what cannot be updated in time. Agree with stakeholders now who can make that call, how long it may last, and what users see meanwhile.\n- **Treat PHP 8.1 and older as a project.** There is no ready-made release for them. Moving to a supported version is a migration with its own scope and schedule.\n- **Expect a second round.** A report that the first fix may be incomplete is open. Keep a slot free in the next fortnight.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- If you run PHP\n- Impact: offline vs compromised\n- Timeline\n\nChoose *read as Taylor* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- what unplanned work this creates\n- which systems and owners to chase\n- what to tell stakeholders about downtime\n- what changes after the fix\n\n### What you can skip\n- the code\n- the bug classes\n- the detection rules\n\n\n## The facts this rests on\nShow the 20 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| No named organisation has confirmed a compromise through php2shellA negative finding as of the latest capture. Amazon says 'broadly exploited' against sensors; Weird Gloop expects old forums to have been hit; CISA has not listed either CVE. | this site, from every captured source | confirmed | **A4** Corroborated●●●●○○ status overstated | 5/5 | CISA Huntress Imperva Threat Research Amazon Weird Gloop |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | **A6** Established●●●●●● | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | **A2** Reported●●○○○○ disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | **A2** Reported●●○○○○ disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | refuted measures differently | 2/3 | BBC News php.net php-src |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 4,
     "hash": "6db576928527",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a project or programme manager: What unplanned work does this create, who do I chase, and what do I tell stakeholders?\n\nThe 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.\n\nBriefing for Taylor, project or programme manager · ******Plain English\n\n# What unplanned work does this create, who do I chase, and what do I tell stakeholders?\n\nT\nThe answer in thirty seconds\n\nExpect unplanned work this week: updating PHP on every system that uses it, restarting, and re-testing. Some teams may take systems offline for hours as a precaution. Anything still on PHP 8.1 or older has no ready-made fix and becomes a migration project. Ask each system owner for a patch date and a test plan.\n\nRead the site as Taylor →\n\nThis is a platform event, not an application bug, so it lands on every team that ships anything running on PHP at once. Plan for it the way you would plan for a datacentre move: an inventory, an owner per system, a date, a test.\n\n## What to decide or do\n- **Get the list.** Which systems run PHP, who owns each, and which are on the internet. Vendor products and hosting panels count. Without the list nothing else can be scheduled.\n- **Get a date per system.** Updating PHP means installing the fixed version, restarting, rebuilding containers and re-testing. Internet-facing systems first.\n- **Budget for regression testing.** The fix changes how PHP behaves when it runs short of memory: a system that used to limp along may now stop cleanly. Load tests are worth running before the release, not after.\n- **Plan for precautionary downtime.** Agencies advise isolating or taking offline what cannot be updated in time. Agree with stakeholders now who can make that call, how long it may last, and what users see meanwhile.\n- **Treat PHP 8.1 and older as a project.** There is no ready-made release for them. Moving to a supported version is a migration with its own scope and schedule.\n- **Expect a second round.** A report that the first fix may be incomplete is open. Keep a slot free in the next fortnight.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- If you run PHP\n- Impact: offline vs compromised\n- Timeline\n\nChoose *read as Taylor* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- what unplanned work this creates\n- which systems and owners to chase\n- what to tell stakeholders about downtime\n- what changes after the fix\n\n### What you can skip\n- the code\n- the bug classes\n- the detection rules\n\n\n## The facts this rests on\nShow the 20 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | **A6** Established●●●●●● | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | **A2** Reported●●○○○○ disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | **A2** Reported●●○○○○ disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | refuted measures differently | 2/3 | BBC News php.net php-src |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    },
    {
     "v": 5,
     "hash": "a37a4dbdbbfc",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# Briefing for a project or programme manager: What unplanned work does this create, who do I chase, and what do I tell stakeholders?\n\nThe 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.\n\nBriefing for Taylor, project or programme manager · ******Plain English\n\n# What unplanned work does this create, who do I chase, and what do I tell stakeholders?\n\nT\nThe answer in thirty seconds\n\nExpect unplanned work this week: updating PHP on every system that uses it, restarting, and re-testing. Some teams may take systems offline for hours as a precaution. Anything still on PHP 8.1 or older has no ready-made fix and becomes a migration project. Ask each system owner for a patch date and a test plan.\n\nRead the site as Taylor →\n\nThis is a platform event, not an application bug, so it lands on every team that ships anything running on PHP at once. Plan for it the way you would plan for a datacentre move: an inventory, an owner per system, a date, a test.\n\n## What to decide or do\n- **Get the list.** Which systems run PHP, who owns each, and which are on the internet. Vendor products and hosting panels count. Without the list nothing else can be scheduled.\n- **Get a date per system.** Updating PHP means installing the fixed version, restarting, rebuilding containers and re-testing. Internet-facing systems first.\n- **Budget for regression testing.** The fix changes how PHP behaves when it runs short of memory: a system that used to limp along may now stop cleanly. Load tests are worth running before the release, not after.\n- **Plan for precautionary downtime.** Agencies advise isolating or taking offline what cannot be updated in time. Agree with stakeholders now who can make that call, how long it may last, and what users see meanwhile.\n- **Treat PHP 8.1 and older as a project.** There is no ready-made release for them. Moving to a supported version is a migration with its own scope and schedule.\n- **Expect a second round.** A report that the first fix may be incomplete is open. Keep a slot free in the next fortnight.\n\n## Your reading path\n- Your briefing\n- Explained from the start\n- If you run PHP\n- Impact: offline vs compromised\n- Timeline\n\nChoose *read as Taylor* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- what unplanned work this creates\n- which systems and owners to chase\n- what to tell stakeholders about downtime\n- what changes after the fix\n\n### What you can skip\n- the code\n- the bug classes\n- the detection rules\n\n\n## The facts this rests on\nShow the 20 claims behind this briefing, each with its status and sources- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| The fix was authored on 18 October at 15:26 UTC and entered the public branches at 14:06 UTC on 21 October, with merges into 8.3, 8.4 and 8.5 between 14:12 and 14:30 UTCCounted from the repository, not from a page. Five authors; 389 files; 10,689 insertions. | php/php-src commit 3584a98bd, read from a clone | confirmed | **A6** Established●●●●●● | 2/2 | php/php-src, read from a clone php-src |\n| The fixes were released at 14:00 UTC on 21 OctoberCERT-EU says 13:30 UTC; the tags and advisories are stamped 13:34 to 13:35 UTC; the GitHub release 14:06 UTC; the php.net feed entries carry 00:05 to 00:35 UTC, which are authoring times, not publication times. | php.net pre-announcement; Daubois; CERT-FR (16:00 Paris) | disputed | **A2** Reported●●○○○○ disputed | 7/8 | oss-security Daubois CERT-FR CERT-EU php-src PHP php-src php.net |\n| The pre-announcement was published at 19:30 UTC on 20 OctoberThe php.net feed says 20:32 UTC; oss-security relayed it at 20:22:51 UTC, so it was public by then. | PHP Foundation | disputed | **A2** Reported●●○○○○ disputed | 3/3 | PHP Foundation oss-security php.net |\n| The flaws were disclosed on 22 October 2026Primary sources put the release at 21 October: GHSAs 13:34Z, tags 13:35Z, CVE records 13:48Z and 13:54Z, GitHub release 14:06Z. | BBC framing (UK morning coverage) | contradicted | refuted measures differently | 2/3 | BBC News php.net php-src |\n\nEvery sentence above rests on these rows. They are folded away because they are written in the sources' own vocabulary; the glossary explains each term.\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Data protection officer · Head of AppSec · Developer · Communications team."
    }
   ]
  },
  "page-summary": {
   "title": "The specialist summary",
   "kind": "page",
   "path": "summary/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "40cad31eb042",
     "site": "0.3.1",
     "date": "2026-10-22",
     "reconstructed": true,
     "text": "# The specialist summary: CVE-2026-109618 and CVE-2026-109619\n\nThe 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.\n\nThe story · for specialists\n\n# The specialist summary: php2shell, CVE-2026-109618 and CVE-2026-109619\n\nOn 21 October 2026 at 14:00 UTC the PHP project released fixes for two critical flaws, **CVE-2026-109618** and **CVE-2026-109619**, nicknamed *php2shell*. Either can give an unauthenticated attacker remote code execution on a web server running PHP, the language behind WordPress, Drupal, Wikipedia and a large share of the web. The flaws were found with AI help, the coordinated disclosure broke down two days early, and by the morning of 22 October the NSA, CISA and the UK's NCSC were telling organisations that could not patch to take systems offline. This site follows the story as evidence: every claim points to a captured, dated and hashed source, every number says what it measures, and every contradiction between sources is left visible.\n\n144sources in the evidence vault137dated captures, each file hashed70claims with a status: 22 confirmed, 11 disputed or contradicted, 4 unverified68dated events on the timeline16national agencies compared10operators reported offline, 0 confirmed compromises674products in the NCSC-NL inventory\n\n**Developing, and agent-produced.** Software agents assemble this site from sources captured into a private evidence vault; the editor is Dinis Cruz. Nothing here is advice on what to patch in your environment. For that, read the php.net advisory and your national cyber-security agency. Where this site says a thing is *confirmed*, it means two or more primary sources agree, or the fact was counted from a captured file; *reported* means one party says so; *disputed* means the sources disagree; *unverified* means even the reporting outlet could not check it.\n\n## Six numbers, and what each one measures\n70%the Internetunverifiedalmost 70%websitesreportedabout 30 millionwebsitesreported2,608,039internet-facing hosts running PHPreportedabout 6,000potentially affected resources in Latvia, a few hundred in the public sectorreported674software entries in the NCSC-NL php2shell inventoryconfirmed\nThe figures in circulation range from 2.6 million hosts to 70% of the Internet. They are not contradictory so much as incommensurable: each measures a different thing. The numbers page says what each one counts, who said it, and whether anyone has checked it.\n\n## What is established\n- There are two flaws, both in the PHP engine, both rated CVSS v4.0 9.2, both fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The CVE records, the GitHub advisories and the php.net advisory agree on this. CVE record CVE record PHP PHP php.net\n- Unauthenticated remote code execution was demonstrated against Apache with mod_php before any application code runs. PHP-FPM is susceptible; the two primary accounts differ on whether a complete FPM exploit exists. PHP oss-security PHP Foundation\n- The flaws are old. The out-of-memory problem behind CVE-2026-109618 was first seen during a 2024 audit (Quarkslab, funded through OSTIF) and left unfixed because nobody could prove exploitation. PHP 8.1 and older are out of support; the project published minimal source backports for 7.4, 8.0 and 8.1, but the CVE records list only 8.2 to 8.5. PHP Foundation Calif php-src CVE record\n- Discovery was AI-assisted and three parties claim it. Calif reported first (hash on 5 August, report on 11 August); OpenAI reported the same root cause the same day; Wiz found it independently on 19 August and reported on 24 August. The GitHub advisories credit four reporters. Calif Ryan Austin, Calif on X PHP Foundation Wiz PHP\n- Disclosure broke down on 20 October around 15:00 UTC, when the CVE IDs circulated with a wrong CVSS of 10.0. The release moved forward a day; Calif published, then deleted, a demonstration video; Chainguard shipped patched images six hours before the embargo lifted. PHP Foundation Daubois PHP Foundation\n- The scale figures do not measure the same thing. *70% of the Internet* is a Wiz headline; the body of the same post, Cloudflare and OpenAI say 70% of *websites*; VulnCheck counts 2.6 million internet-facing hosts; Alan Woodward said *something like 30 million websites*; Latvia counted about 6,000 potentially affected resources in one country. Wiz Wiz on X Cloudflare OpenAI on X THN BBC News CERT.LV\n- Exploitation attempts are reported from several directions, but no agency has confirmed a successful compromise. Amazon says a honeypot was hit on 17 October, four days before disclosure. Cloudflare saw attack traffic after the leak. Latvia saw automated attempts, none successful. CISA has not listed either CVE as known-exploited. New Zealand's NCSC alone says it is *aware of reports of active exploitation*. THN Cloudflare CERT.LV CISA NCSC New Zealand\n- The agencies do not agree on taking systems offline. The NSA and CISA say take them offline if you cannot patch; the UK NCSC puts that fourth, after patching and temporary mitigations; CERT-EU, Canada and France say isolate; Australia, the Netherlands, Italy, Japan and New Zealand give no offline advice at all. NSA Cyber on X CISA NCSC UK CERT-EU CCCS CERT-FR ACSC NCSC-NL ACN / CSIRT Italia JPCERT/CC NCSC New Zealand\n\n## What is not\n\nOpen questions, stated rather than papered over. Each one names what would close it.\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n- What the 70% figure is measured from. None of the three pages that carry it names the measurement.\n- The model and the method. Calif says no special harness and names no model; OpenAI's blog, which we could not capture, reportedly names GPT-5.6 Sol; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas. What did the models do and what did the people do?\n- OpenAI's own blog post, the Patch the Planet launch post, the Spanish and Portuguese advisories and the Techzine piece on Chainguard are all blocked by bot challenges from this capture environment. The block is recorded; the content is not read.\n\n## The last 48 hours\n\n| When (UTC) | What | Source |\n|---|---|---|\n| 2026-10-22 05:20 UTC | JVN publishes its note (14:20 JST); JPCERT/CC alert JPCERT-AT-2026-0033 is dated 22 October. | JPCERT/CC JPCERT/CC |\n| 2026-10-22 06:16:24 UTC | BBC News opens its live page: 'Global scramble to fix critical cyber-security flaws as many websites taken offline'. | BBC News |\n| 2026-10-22 06:45:47 UTC | Greenbone on oss-security: the backports imply versions down to 7.4 are affected, whatever the subject line says. | oss-security |\n| 2026-10-22 06:55:50 UTC | The BBC reports the NSA's X post. | BBC News |\n| 2026-10-22 07:00 UTC | Ryan Austin on BBC Radio 4: no evidence of exploitation yet. | BBC News |\n| 2026-10-22 07:30:02 UTC | The UK NCSC page is modified (HTTP last-modified). | NCSC UK |\n| 2026-10-22 08:03 UTC | The evidence vault behind this site is opened; the first capture of the BBC live page is at 08:04:53Z. | BBC News |\n| 2026-10-22 08:40:58 UTC | NCSC-NL merges pull request 10; the inventory has 674 entries at commit cca173c64ec5. | NCSC-NL NCSC-NL |\n\nThe whole timeline → runs from the 2024 audit to the latest capture, with every time stated as its source states it and every conversion marked.\n\n## How this site works\n\nEvery source is captured into a private, encrypted vault, each file hashed at capture time; every claim carries one of five status words and the sources that earn it; the site is a deterministic build of the vault, and a gate refuses a broken link, an unsourced claim or a credential. The method, the team and the billing model are published."
    },
    {
     "v": 2,
     "hash": "16bef71df9a1",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# The specialist summary: CVE-2026-109618 and CVE-2026-109619\n\nThe 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.\n\nThe story · for specialists\n\n# The specialist summary: php2shell, CVE-2026-109618 and CVE-2026-109619\n\nOn 21 October 2026 at 14:00 UTC the PHP project released fixes for two critical flaws, **CVE-2026-109618** and **CVE-2026-109619**, nicknamed *php2shell*. Either can give an unauthenticated attacker remote code execution on a web server running PHP, the language behind WordPress, Drupal, Wikipedia and a large share of the web. The flaws were found with AI help, the coordinated disclosure broke down two days early, and by the morning of 22 October the NSA, CISA and the UK's NCSC were telling organisations that could not patch to take systems offline. This site follows the story as evidence: every claim points to a captured, dated and hashed source, every number says what it measures, and every contradiction between sources is left visible.\n\n144sources in the evidence vault137dated captures, each file hashed70claims with a status: 21 confirmed, 11 disputed or contradicted, 4 unverified68dated events on the timeline16national agencies compared10operators reported offline, 0 confirmed compromises674products in the NCSC-NL inventory\n\n**Developing, and agent-produced.** Software agents assemble this site from sources captured into a private evidence vault; the editor is Dinis Cruz. Nothing here is advice on what to patch in your environment. For that, read the php.net advisory and your national cyber-security agency. Where this site says a thing is *confirmed*, it means two or more primary sources agree, or the fact was counted from a captured file; *reported* means one party says so; *disputed* means the sources disagree; *unverified* means even the reporting outlet could not check it.\n\n## Six numbers, and what each one measures\n70%the Internetunverifiedalmost 70%websitesreportedabout 30 millionwebsitesreported2,608,039internet-facing hosts running PHPreportedabout 6,000potentially affected resources in Latvia, a few hundred in the public sectorreported674software entries in the NCSC-NL php2shell inventoryconfirmed\nThe figures in circulation range from 2.6 million hosts to 70% of the Internet. They are not contradictory so much as incommensurable: each measures a different thing. The numbers page says what each one counts, who said it, and whether anyone has checked it.\n\n## What is established\n- There are two flaws, both in the PHP engine, both rated CVSS v4.0 9.2, both fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The CVE records, the GitHub advisories and the php.net advisory agree on this. CVE record CVE record PHP PHP php.net\n- Unauthenticated remote code execution was demonstrated against Apache with mod_php before any application code runs. PHP-FPM is susceptible; the two primary accounts differ on whether a complete FPM exploit exists. PHP oss-security PHP Foundation\n- The flaws are old. The out-of-memory problem behind CVE-2026-109618 was first seen during a 2024 audit (Quarkslab, funded through OSTIF) and left unfixed because nobody could prove exploitation. PHP 8.1 and older are out of support; the project published minimal source backports for 7.4, 8.0 and 8.1, but the CVE records list only 8.2 to 8.5. PHP Foundation Calif php-src CVE record\n- Discovery was AI-assisted and three parties claim it. Calif reported first (hash on 5 August, report on 11 August); OpenAI reported the same root cause the same day; Wiz found it independently on 19 August and reported on 24 August. The GitHub advisories credit four reporters. Calif Ryan Austin, Calif on X PHP Foundation Wiz PHP\n- Disclosure broke down on 20 October around 15:00 UTC, when the CVE IDs circulated with a wrong CVSS of 10.0. The release moved forward a day; Calif published, then deleted, a demonstration video; Chainguard shipped patched images six hours before the embargo lifted. PHP Foundation Daubois PHP Foundation\n- The scale figures do not measure the same thing. *70% of the Internet* is a Wiz headline; the body of the same post, Cloudflare and OpenAI say 70% of *websites*; VulnCheck counts 2.6 million internet-facing hosts; Alan Woodward said *something like 30 million websites*; Latvia counted about 6,000 potentially affected resources in one country. Wiz Wiz on X Cloudflare OpenAI on X THN BBC News CERT.LV\n- Exploitation attempts are reported from several directions, but no agency has confirmed a successful compromise. Amazon says a honeypot was hit on 17 October, four days before disclosure. Cloudflare saw attack traffic after the leak. Latvia saw automated attempts, none successful. CISA has not listed either CVE as known-exploited. New Zealand's NCSC alone says it is *aware of reports of active exploitation*. THN Cloudflare CERT.LV CISA NCSC New Zealand\n- The agencies do not agree on taking systems offline. The NSA and CISA say take them offline if you cannot patch; the UK NCSC puts that fourth, after patching and temporary mitigations; CERT-EU, Canada and France say isolate; Australia, the Netherlands, Italy, Japan and New Zealand give no offline advice at all. NSA Cyber on X CISA NCSC UK CERT-EU CCCS CERT-FR ACSC NCSC-NL ACN / CSIRT Italia JPCERT/CC NCSC New Zealand\n\n## What is not\n\nOpen questions, stated rather than papered over. Each one names what would close it.\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n- What the 70% figure is measured from. None of the three pages that carry it names the measurement.\n- The model and the method. Calif says no special harness and names no model; OpenAI's blog, which we could not capture, reportedly names GPT-5.6 Sol; Wiz names Gemini 4 Argon, GPT-5.6 Sol and Wiz Atlas. What did the models do and what did the people do?\n- OpenAI's own blog post, the Patch the Planet launch post, the Spanish and Portuguese advisories and the Techzine piece on Chainguard are all blocked by bot challenges from this capture environment. The block is recorded; the content is not read.\n\n## The last 48 hours\n\n| When (UTC) | What | Source |\n|---|---|---|\n| 2026-10-22 05:20 UTC | JVN publishes its note (14:20 JST); JPCERT/CC alert JPCERT-AT-2026-0033 is dated 22 October. | JPCERT/CC JPCERT/CC |\n| 2026-10-22 06:16:24 UTC | BBC News opens its live page: 'Global scramble to fix critical cyber-security flaws as many websites taken offline'. | BBC News |\n| 2026-10-22 06:45:47 UTC | Greenbone on oss-security: the backports imply versions down to 7.4 are affected, whatever the subject line says. | oss-security |\n| 2026-10-22 06:55:50 UTC | The BBC reports the NSA's X post. | BBC News |\n| 2026-10-22 07:00 UTC | Ryan Austin on BBC Radio 4: no evidence of exploitation yet. | BBC News |\n| 2026-10-22 07:30:02 UTC | The UK NCSC page is modified (HTTP last-modified). | NCSC UK |\n| 2026-10-22 08:03 UTC | The evidence vault behind this site is opened; the first capture of the BBC live page is at 08:04:53Z. | BBC News |\n| 2026-10-22 08:40:58 UTC | NCSC-NL merges pull request 10; the inventory has 674 entries at commit cca173c64ec5. | NCSC-NL NCSC-NL |\n\nThe whole timeline → runs from the 2024 audit to the latest capture, with every time stated as its source states it and every conversion marked.\n\n## How this site works\n\nEvery source is captured into a private, encrypted vault, each file hashed at capture time; every claim carries one of five status words and the sources that earn it; the site is a deterministic build of the vault, and a gate refuses a broken link, an unsourced claim or a credential. The method, the team and the billing model are published."
    }
   ]
  },
  "front-now": {
   "title": "Front page: right now",
   "kind": "front",
   "path": "index.html",
   "scope": "front",
   "versions": [
    {
     "v": 1,
     "hash": "259691b587bd",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "A fix has been available since 21 October. Organisations that run websites on PHP are installing it. [php-net-advisory]\nGovernment cyber agencies in the US, the UK, the EU and elsewhere say: install the fix now, and take a website offline if you cannot. [cisa-alert-php-20261021, ncsc-news-php, certeu-sa-2026-018, nsa-x-2112903220209098897]\nAttackers are trying to use the flaws, in large numbers. No organisation has said it was broken into. [x-eastdakota-php2shell-stats, cisa-kev-json]\nSome organisations took websites offline as a precaution, among them Dutch government services such as the DigiD login. [rijksoverheid-ncsc-php-news, bbc-live-ckgel5xp2xv9t]"
    },
    {
     "v": 2,
     "hash": "1b314644618d",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "A fix has been available since 21 October. Organisations that run websites on PHP are installing it. [php-net-advisory]\nGovernment cyber agencies in the US, the UK, the EU and elsewhere say: install the fix now, and take a website offline if you cannot. [cisa-alert-php-20261021, ncsc-news-php, certeu-sa-2026-018, nsa-x-2112903220209098897]\nAttackers are trying to use the flaws, in large numbers. As of the evening of 22 October, no named organisation has said it was compromised through php2shell. [x-eastdakota-php2shell-stats, cisa-kev-json]\nSome organisations took websites offline as a precaution, among them Dutch government services such as the DigiD login. [rijksoverheid-ncsc-php-news, bbc-live-ckgel5xp2xv9t]"
    }
   ]
  },
  "front-glance": {
   "title": "Front page: at a glance",
   "kind": "front",
   "path": "index.html",
   "scope": "front",
   "versions": [
    {
     "v": 1,
     "hash": "8ff454557e0a",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "Is there a fix?: Yes (install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35)\nHow serious?: Critical (9.2 out of 10, both flaws)\nAre attackers trying?: Yes (millions of attempts, seen by one internet security company)\nAnyone confirmed hacked?: Not yet (no organisation, as of the latest check)\nWebsites taken offline: 10 organisations (reported, as a precaution)\nOn the US 'used in attacks' list?: Not yet (the US government's official list of flaws known to be used by attackers)\nWhat do governments say?: Update now (or take the website offline if you cannot; 16 agencies compared)"
    }
   ]
  },
  "front-facts": {
   "title": "Front page: the core facts",
   "kind": "front",
   "path": "index.html",
   "scope": "front",
   "versions": [
    {
     "v": 1,
     "hash": "a9ba1bdfcfcf",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "confirmed: There are two flaws. Both are in PHP itself, underneath every website that uses it, and both are rated critical: 9.2 out of 10. [cve-cve-2026-109618, cve-cve-2026-109619, php-net-advisory]\nconfirmed: Someone anywhere on the internet, with no password, can use them against a website that has not installed the fix, and make its server run their own commands. Researchers proved this on the most traditional way of running PHP; for other setups it is likely but less certain. [github-ghsa-w8hw-w9fx-j79w, github-ghsa-6wmf-4rv5-p3rp, php-foundation-blog-security-release]\nconfirmed: The fix is in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Websites on PHP 8.1 or older have no ready-made fix. [php-net-advisory, github-php-src-branch-7.4-backport]\nreported: The weak spot was first noticed in 2024 and left alone, because nobody could show it was dangerous. In August 2026, three research teams using AI tools showed that it was, and told the PHP project. [php-foundation-blog-security-release, calif-php2shell, wiz-blog-php2shell]\nconfirmed: The plan was to announce the fix on 22 October. Word leaked out on 20 October, so it was released a day early. [php-foundation-blog-security-release, daubois-blog-php2shell-rumors]\nreported: Attackers are trying. One internet security company reports millions of attempts; Amazon reports a decoy server was hit four days before the announcement. [x-eastdakota-php2shell-stats, thehackernews-php2shell-4days]\nconfirmed: No organisation has confirmed a break-in, and the US government's official list of flaws known to be used in attacks did not include these two when last checked. [cisa-kev-json, cisa-kev-catalog]\nconfirmed: Every agency says install the fix. They disagree on what to do if you cannot: the US says take the website offline, the UK lists that as a last resort, several European agencies say cut it off from the public internet, and some say nothing about it. [cisa-alert-php-20261021, ncsc-news-php, certeu-sa-2026-018, acsc-alert-php]\nconfirmed: The headline '70% of the Internet' is not what it sounds like. It is roughly the share of websites built with PHP, which is what the same company's own article says; nobody has measured how many are actually at risk. [wiz-blog-php2shell, x-wiz-io-php2shell, cloudflare-blog-php2shell-waf]"
    },
    {
     "v": 2,
     "hash": "48aa4802b3a9",
     "site": "0.5.8",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "confirmed: There are two flaws. Both are in PHP itself, underneath every website that uses it, and both are rated critical: 9.2 out of 10. [cve-cve-2026-109618, cve-cve-2026-109619, php-net-advisory]\nconfirmed: Someone anywhere on the internet, with no password, can use them against a website that has not installed the fix, and make its server run their own commands. Researchers proved this on the most traditional way of running PHP; for other setups it is likely but less certain. [github-ghsa-w8hw-w9fx-j79w, github-ghsa-6wmf-4rv5-p3rp, php-foundation-blog-security-release]\nconfirmed: The fix is in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Websites on PHP 8.1 or older have no ready-made fix. [php-net-advisory, github-php-src-branch-7.4-backport]\nreported: The weak spot was first noticed in 2024 and left alone, because nobody could show it was dangerous. In August 2026, three research teams using AI tools showed that it was, and told the PHP project. [php-foundation-blog-security-release, calif-php2shell, wiz-blog-php2shell]\nconfirmed: The plan was to announce the fix on 22 October. Word leaked out on 20 October, so it was released a day early. [php-foundation-blog-security-release, daubois-blog-php2shell-rumors]\nreported: Attackers are trying. One internet security company reports millions of attempts; Amazon reports a decoy server was hit four days before the announcement. [x-eastdakota-php2shell-stats, thehackernews-php2shell-4days]\nconfirmed: Attackers are trying, in large numbers. No organisation has said it was broken into through this flaw, as of the evening of 22 October, and the US government's official list of flaws known to be used in attacks did not include these two when last checked. [cisa-kev-json, cisa-kev-catalog]\nconfirmed: Every agency says install the fix. They disagree on what to do if you cannot: the US says take the website offline, the UK lists that as a last resort, several European agencies say cut it off from the public internet, and some say nothing about it. [cisa-alert-php-20261021, ncsc-news-php, certeu-sa-2026-018, acsc-alert-php]\nconfirmed: The headline '70% of the Internet' is not what it sounds like. It is roughly the share of websites built with PHP, which is what the same company's own article says; nobody has measured how many are actually at risk. [wiz-blog-php2shell, x-wiz-io-php2shell, cloudflare-blog-php2shell-waf]"
    }
   ]
  },
  "front-unknown": {
   "title": "Front page: what nobody knows yet",
   "kind": "front",
   "path": "index.html",
   "scope": "front",
   "versions": [
    {
     "v": 1,
     "hash": "791a47b54794",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "Whether any website was actually broken into before it installed the fix.\nWhether the fix is complete. A report on 21 October suggested it may not be; the PHP project has not answered it publicly yet.\nWho leaked the news on 20 October, and where.\nExactly which websites went offline, and why. Most of the list comes from one news live page and has not been confirmed by the organisations named.\nWhere the 70% figure comes from. None of the pages that use it says how it was measured."
    }
   ]
  },
  "front-latest": {
   "title": "Front page: latest",
   "kind": "front",
   "path": "index.html",
   "scope": "front",
   "versions": [
    {
     "v": 1,
     "hash": "8b53dad095d4",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "22 Oct, 05:20 UTC: Japan's national cyber agency issues its alert. [jpcert-at260033]\n22 Oct, 06:16 UTC: BBC News opens a live page: 'Global scramble to fix critical cyber-security flaws as many websites taken offline'. [bbc-live-ckgel5xp2xv9t]\n22 Oct, 06:55 UTC: The BBC reports the US NSA's advice: take systems offline if they cannot be updated. [bbc-live-ckgel5xp2xv9t, nsa-x-2112903220209098897]\n22 Oct, 07:00 UTC: One of the researchers who found the flaws tells BBC Radio 4 there is no evidence yet of them being used in attacks. [bbc-live-ckgel5xp2xv9t]\n22 Oct, 08:40 UTC: The Dutch national cyber agency's list of affected software reaches 674 products. [ncsc-nl-php2shell-software-list]"
    }
   ]
  },
  "page-interview": {
   "title": "Interview: the editor",
   "kind": "page",
   "path": "interview/index.html",
   "scope": "everyone",
   "versions": [
    {
     "v": 1,
     "hash": "541f1653d7cb",
     "site": "0.3.2",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# The editor, interviewed: Dinis Cruz on why this site exists\n\nDinis 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.\n\nAbout · interview\n\n# The editor, interviewed: Dinis Cruz on why this site exists\n\nDinis Cruz has worked in application security for a long time and runs the SGit Newsroom. He started this site on the morning of 22 October 2026 with two voice memos and kept steering it through the day. The questions below are the ones a reader would ask; the answers are his.\n\nHow this was made: the questions are written by the agent that builds the site; every answer is the editor's own words, quoted verbatim from his voice memos and voice notes of 22 October as transcribed, including the hesitations. Nothing was paraphrased. A live interview is pending, and its questions are at the foot of the page.\n\n### Why cover this story at all?\n\nOkay, so there's a big vulnerability flying around at the moment, and I would like to use this as a good case study for what we can do in the newsroom. But it's also a good way to explore other ways to visualise and to map a lot of this stuff.\nVoice memo 1, 22 October 2026, transcribed by otter.ai, 0:00\n### What made you doubt the coverage?\n\nthe BBC has that 70% of the internet is impacted, which is a crazy statement. Which then you look at the source, and the source says 70% of websites are impacted, and they look at it. Say 70% of websites that we can measure the language are impacted. Now, I've been in security and technology for a long time, and I and I could I don't buy that 70% of websites out there, especially some sort of websites that matter, that have a huge amount of information, are a impacted. B don't have other ways to protect this, right?\nVoice memo 2, 22 October 2026, transcribed by otter.ai\n### Is this about catching journalists out?\n\nit's not about naming and shaming a lot of this stuff, but it's also about you know making sure that the data is actually correct, right, and the statement is actually correct, and also figuring out good ways to find sources and then follow the rabbit holes, and also in a way help journalists, right?\nVoice memo 1, 22 October 2026, transcribed by otter.ai\n### Remote code execution sounds like game over. Is it?\n\nthis does remote code execution on on a website, right? But it doesn't mean that the website is compromised. Well, everything is compromised from day one, right? But what means it means that that website is compromised. But it depends what you're going to do with it, right? Depends what's on either side. Depends what credential exists on that website.\nVoice memo 1, 22 October 2026, transcribed by otter.ai, 5:04\n### Can an attack like this be seen?\n\nSo you now have remote code execution, but then what signals do you have? Like you know, and this is important, right? It's important to understand that a zero day like this is not invisibility cloak, right? So we have to be objective, right?\nVoice memo 1, 22 October 2026, transcribed by otter.ai, 5:04\n### Should organisations take websites offline?\n\nputting a website offline is an option, but should be like at the end of a long sequence of events, right? But also, it should be one of those things where companies should be able to do it very quickly, right? Like you know, this is the whole pull the plug, right? You know, like how fast can you pull the plug of a system, right?\nVoice memo 2, 22 October 2026, transcribed by otter.ai\n### What do you want to know now, a day in?\n\none of the things that I really want to know is that, like, what's new? Like, what's the latest? What's going on? Because I think some websites are starting to be attacked, some websites are starting to be compromised, which is bound to happen, right? So we need to also capture that information, and we need to capture that flow of the what's actually going on.\nVoice note to the design agent, 22 October 2026, transcribed, afternoon\n### Who is this site for?\n\nif I'm an exec, if I'm a person, a project manager, then I don't know who that is, right? And so it's very important that we map the persona. It's very important that we map who the persona is, who's reading this, and then literally modify the website and modify the whole UI for that particular persona.\nVoice note to the design agent, 22 October 2026, transcribed, midday\n### Why call it PHP October and not php2shell?\n\nthis is about PHP news in October. It just happened to be that there's a massive security incident here, and maybe in the future we just move to the next month, we just track all this stuff, right?\nVoice note to the design agent, 22 October 2026, transcribed, afternoon\n### Why version every section of the site?\n\nevery major section, needs to now be version controlled, and we need to track it, and that means that every time that information changes, like the update that we run there, especially because some of that is going to be programmatically written, right? We should have the date and the version, and also which version of the website was that created.\nVoice note to the design agent, 22 October 2026, transcribed, afternoon\n\n## Not yet answered\n\nThe questions for the next round, in the editor's own time:\n- If a named organisation confirms a compromise tomorrow, what should change on this site, and how fast?\n- Which single number would you put in front of a board this week?\n- What would change your mind about the 70% figure?\n- Three teams found the same bug class with AI help within weeks. What does that mean for the next one?\n- How fast should an organisation be able to pull the plug on one website, and how would you test it?"
    }
   ]
  },
  "briefing-dpo": {
   "title": "Briefing: Data protection officer",
   "kind": "briefing",
   "path": "briefings/dpo/index.html",
   "scope": "dpo",
   "versions": [
    {
     "v": 1,
     "hash": "d2f7f7bfd73c",
     "site": "0.5.9",
     "date": "2026-10-22",
     "reconstructed": false,
     "text": "# 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?\n\nThe 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.\n\nBriefing for Morgan, data protection officer · ******Some technical\n\n# Was personal data exposed, does this start a GDPR breach assessment or a 72-hour notification, and what do I document?\n\nM\nThe answer in thirty seconds\n\nA flaw is not a breach. An unpatched, internet-facing PHP application holding personal data is a risk to record and treat; it becomes a breach to assess when there is a sign of compromise on it. No named organisation has said it was compromised through php2shell as of the last check. Ask your hosts in writing, review from 17 October, and document the assessment either way.\n\nRead the site as Morgan →\n\nFour questions, in order: is personal data on a system that was exposed, has anything happened to it, does that make it a personal data breach, and what goes on the record. A vulnerability is not a breach, and an outage you chose is not one either; a sign that someone ran code on a system holding personal data is where the assessment starts. Written by the GRC desk; the full register is at GRC.\n\n## What to decide or do\n- **Find the personal data first.** Ask the CTO or security lead for the list of internet-facing PHP systems (vendor products and hosting panels count), and mark which hold or reach personal data: accounts, orders, case files, the database the application logs into. Code execution on the server gives an attacker what the PHP process can read, usually including the database credentials in its configuration.\n- **Exposed is not breached.** An unpatched system is a risk under Article 32 to treat and record, not a breach under Article 33. As of the last check, no named organisation has said it was compromised through php2shell; attempts are widely reported and two vendors report successful exploitation without naming a victim. What that statement rests on.\n- **When the 72-hour clock starts.** Under Article 33 it runs from when you become aware, with reasonable certainty, that personal data was affected: a web shell, a PHP worker spawning a shell, an unexplained database export on a system holding personal data. Ask the security lead to tell you the hour that happens, not the day after, and start the assessment then.\n- **A precautionary shutdown is a decision, not a breach.** Taking a service offline on purpose to protect it is not an accidental or unlawful loss of availability. Record who decided, when, for how long, and that no personal data was lost.\n- **Ask your processors in writing.** A host or managed platform is a processor under Article 28 and must tell you of a breach without undue delay (Article 33(2)). Ask each one: have you updated PHP on the systems that process our data, since when, have you seen any sign of compromise, and will you tell us within hours if you do? Keep the replies.\n- **Document either way.** Article 33(5) asks you to record every breach; accountability under Article 5(2) asks you to show your reasoning when you decide something is not one. Record: the systems and the personal data on each, the date each was patched or isolated, the log review window (from 17 October, the earliest reported attempt, not from the 21st), what was found, and the decision with its reasons and who made it.\n- **If it becomes a breach.** Notify the supervisory authority within 72 hours unless the breach is unlikely to result in a risk to people (Article 33), and tell the people affected without undue delay if the risk to them is high (Article 34). Coordinate with whoever owns the NIS2 or DORA report: the same incident can start a 24-hour clock there.\n\n## Your reading path\n- Your briefing\n- No named compromise: the evidence\n- Impact: offline vs compromised\n- grc/risks/r06-1/index.html\n- grc/frameworks/gdpr/index.html\n- If you run PHP\n\nChoose *read as Morgan* and the bar under the menu keeps your place on every page.\n\n### What this briefing covers\n- was personal data exposed\n- whether this is a breach yet, and when the 72-hour clock starts\n- what to ask the host and the other processors\n- what to document, breach or no breach\n\n### What you can skip\n- the C code\n- server settings\n\n\n## The facts this rests on\n- confirmed two or more primary sources agree, or the fact was counted from a captured file\n- reported one party says so, and it has not been contradicted\n- disputed the sources disagree, and both readings are shown\n- contradicted a primary source says otherwise\n- unverified even the reporting outlet could not check it\n- p/n primary sources among the n cited; a blocked capture is counted and marked\n\n| Claim | Who says it | Status | Fact-check | Primary | Sources |\n|---|---|---|---|---|---|\n| Latvia restricted access from abroad to several state digital resources, possibly until 26 October; lsm.lv and 112.lv were restored by 20:00 UTCThe one documented case of government services being pulled from the public internet, from the agency itself. | CERT.LV | confirmed | **A6** Established●●●●●● | 1/1 | CERT.LV |\n| The Dutch NCSC took its own site offline as a precaution, as did DigiD, MijnOverheid and Overheid.nl, with no signs of active exploitation of those servicesPrimary statement. | the Dutch government | confirmed | **A3** Echoed●●●○○○ status overstated | 1/2 (1 blocked) | Rijksoverheid / NCSC-NL Dutch IT Leaders |\n| Weird Gloop turned off its wiki web servers for 13 hours and still served about 94% of page views from cachePrimary, and the one outage with a measured cost. | Weird Gloop | confirmed | **A2** Reported●●○○○○ status overstated | 1/1 | Weird Gloop |\n| Parts of Wikipedia, Edinburgh council, French government sites, the University of Geneva, online shops and the BBC were affected or taken offlineNot captured from any of the named organisations. | BBC | reported | **A2** Reported●●○○○○ | 0/1 | BBC News |\n| As of 20:50 UTC on 22 October, no named organisation has said it was compromised through php2shell. Exploitation attempts are widely reported, and two security vendors, Hadrian and Patchstack, report successful exploitation without naming any victim.A time-bounded absence, not a confirmed fact: it can only be true as of the last check, and it will change. Changed from \"confirmed\" on 22 October at the editor's request (fact-check run 1 had marked it overstated; Perplexity and ChatGPT, asked by the editor, said the same). Attempts are not compromises: watchTowr says \"nobody has been successful to date\"; Amazon says it is unclear whether any attempt would have succeeded on real systems; Patchstack's incidents are reports from hosting partners with no victim named. Source watch (vault oq9gflln), pending promotion into the evidence vault: the PHP Foundation's executive director told The Verge and WIRED \"to our knowledge, there has been no successful attempt at remote code execution\" (raw/us/tech-press/the-verge/php2shell-websites-down/); officials in Germany, the Netherlands and Japan say they have not seen an attack succeed (The Next Web, raw/nl/tech-press/the-next-web/php2shell-no-confirmed-breaches/); GMO confirmed a break-in on 20 October on its FX trading VPS service (26,739 servers, logins possibly taken) without stating the cause (raw/jp/news/yahoo-news-jp/gmo-fx-login-leak/20261022T191523Z/); Czech Technical University says it stopped an active attack that was part of worldwide attempts against PHP sites, success not established (raw/cz/tech-press/lupa/cvut-cyber-attack/20261022T191510Z/); Valtec in Japan blamed php2shell for a break-in, then retracted: its own service's flaw (raw/jp/tech-press/impress-watch/valtec-php-attack/20261022T191433Z/); Fortune reports an anonymous startup owner alleging stolen source code, unnamed and not attributed to the flaw. Edited by researcher@php.newsroom. | this site, from every captured source in the evidence vault and the source watch, as of 20:50 UTC on 22 October | reported | **A4** Corroborated●●●●○○ status overstated | 6/9 | CISA CISA Huntress Amazon SecurityWeek SecurityWeek Recorded Future Imperva Threat Research Weird Gloop |\n| Finland's state IT provider Valtori restricted public traffic to government web services from 12:45 local time on 21 October as a precaution | Yle; Helsinki Times, quoting Valtori | reported | **A2** Reported●●○○○○ | 0/2 | Yle Helsinki Times |\n| The Wikimedia Foundation took down a number of systems 'as a precautionary measure until they can be safely patched'No Wikimedia-published statement captured. | the Foundation, as quoted by CNN and The Cyber Express | reported | **A4** Corroborated●●●●○○ | 0/2 | CNN The Cyber Express |\n| Edinburgh council's site went offline late on 21 October; the council called it 'essential maintenance' and did not confirm a link | The Scotsman quoting the council | reported | **A3** Echoed●●●○○○ | 0/1 | The Scotsman |\n| Oxford City Council: 'a precaution because of a worldwide issue with the underlying technology and is not a cyber incident' | the council's social post, via Oxford Chronicle | reported | **A2** Reported●●○○○○ | 0/1 | Oxford Chronicle |\n| Edinburgh and Oxford councils, the Met Police and the Office for Budget Responsibility were unavailable; Bristol, Lambeth and Barnet council sites showed errors | LBC; Insurance Business | reported | **A3** Echoed●●●○○○ | 0/2 | LBC Insurance Business |\n| CISA has not observed exploitation; neither CVE is in the Known Exploited Vulnerabilities catalogCatalog version 2026.10.21 fetched 2026-10-22T08:15Z, 1,754 entries. A point-in-time negative finding. | CISA | confirmed | **A6** Established●●●●●● | 3/3 | CISA CISA CVE record |\n| Amazon and Cloudflare saw sites being probed for the flawBoth companies have since said so themselves. | Alan Woodward, via the BBC; confirmed by both companies' own posts | confirmed | **A5** Confirmed●●●●●○ | 2/3 | BBC News Cloudflare Amazon |\n| The last PHP core RCE, CVE-2024-4577, was exploited in the wild one day after disclosure and in KEV three days after; php2shell is not in KEV after one dayCounted from the captured catalog. | CISA KEV catalog; Akamai (2024) | confirmed | **A2** Reported●●○○○○ status overstated | 3/3 | CISA CVE record Akamai Security Research |\n| There is no evidence yet that hackers have exploited the flaw | Ryan Austin, Calif, on Radio 4, 08:00 BST 22 October | reported | **A2** Reported●●○○○○ disputed | 0/1 | BBC News |\n| Reports of active exploitation existThe only agency saying so, and it does not say whose reports. | NCSC New Zealand | reported | **A2** Reported●●○○○○ disputed | 1/1 | NCSC New Zealand |\n| An exploit attempt hit an Amazon honeypot on 17 October from an anonymisation network; proof-of-concept attempts began about 02:00 UTC on 21 October from multiple actors; after release 'PHP2Shell is now being broadly exploited in the wild'Primary party. Amazon adds: 'it's unclear if any of these attempts would have succeeded in real-world systems'. Attempts against honeypots, not compromises of victims. | Amazon (CJ Moses, AWS Security Blog) | reported | **A2** Reported●●○○○○ disputed | 1/2 | Amazon THN |\n| Cloudflare observed attack traffic targeting its customers after the leak, with attackers mutating payloadsPrimary party, no volumes. | Cloudflare | reported | **A2** Reported●●○○○○ | 1/1 | Cloudflare |\n| Automated exploitation attempts were seen in Latvia; none succeededPrimary source. | CERT.LV | reported | **A2** Reported●●○○○○ | 1/1 | CERT.LV |\n| Exploit attempts across Cloudflare's network: thousands in the ten hours before announcement, tens of thousands within 45 minutes after, hundreds of thousands within two hours, millions by 22 October 01:25 UTCPrimary party. Attempts, not compromises; no blocked count; 1.4 million views at capture. | Matthew Prince, Cloudflare CEO, on X | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Matthew Prince, Cloudflare CEO on… |\n| No traffic matching the php2shell exploit patterns was seen during Imperva's pre-disclosure monitoringA negative finding from a party that had the details under embargo. | Imperva Threat Research | reported | **A2** Reported●●○○○○ measures differently | 1/1 | Imperva Threat Research |\n| No exploitation observed on Huntress partner systems as of 20:30 UTC on 21 October; no public exploit code known to Huntress | Huntress | reported | **A2** Reported●●○○○○ disputed | 1/1 | Huntress |\n| Criminals are using AI to 'vibe code' an attack method | unnamed researchers, via the BBC | unverified | **A1** Weak signal●○○○○○ opinion | 0/1 | BBC News |\n| watchTowr sees active exploitation attempts and lists the flaws as exploited in the wildwatchtowr.com returns HTTP 403 to this site's capture tool; known only from search summaries. | watchTowr | unverified | **A4** Corroborated●●●●○○ superseded | 2/2 | watchTowr watchTowr |\n| If an immediate update is not feasible, take the system offline until it can be fully mitigatedX post 13:45:58Z 21 October (10.1 million views at capture) and the press release. | NSA Cybersecurity | confirmed | **A6** Established●●●●●● | 2/2 | NSA Cyber on X NSA |\n| Organisations that cannot update immediately, or that run PHP 8.1 or older, should take PHP-based systems offline | CISA | confirmed | **A6** Established●●●●●● | 1/1 | CISA |\n| Edge protections went live hours before disclosure: Cloudflare at 03:02 UTC; Imperva, Akamai and Fastly on 21 October; Fortinet signatures by 22 OctoberEvery vendor says the same two things: it is a stopgap, and patch anyway. | the vendors | confirmed | **A2** Reported●●○○○○ status overstated | 5/5 | Cloudflare Imperva Threat Research Akamai Security Research Fastly Fortinet Community |\n| The risks require immediate patching across United States Government departments and agenciesNo CISA emergency directive was visible on the CISA home page at capture. | NSA | reported | **A6** Established●●●●●● | 1/2 | NSA CISA |\n| 'Where immediate remediation is not feasible, organisations should consider taking the system offline until it can be fully mitigated'That sentence is not on the NCSC page as captured at 08:09Z on 22 October. The page's offline advice is step 4 of 6 and is worded differently. The page was modified at 07:30Z that morning. The sentence's opening matches the Canadian CCCS text. | UK NCSC, as quoted by the BBC | disputed | **A2** Reported●●○○○○ disputed | 2/3 | BBC News NCSC UK CCCS |\n| The UK's NCSC, the NSA and their counterparts in the EU and Australia advise taking systems offline where patching is not feasibleAustralia's ACSC gives no offline advice. CERT-EU says isolate. The Netherlands, Italy, Japan and New Zealand give no offline advice. | BBC | contradicted | **A1** Weak signal●○○○○○ | 4/6 | BBC News ACSC CERT-EU NCSC-NL ACN / CSIRT Italia JPCERT/CC |\n| Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each CVSS v4.0 9.2, fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 | PHP Group (CNA), GitHub advisories, php.net | confirmed | **A6** Established●●●●●● | 5/5 | CVE record CVE record PHP PHP php.net |\n| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | PHP security team (GHSA, oss-security), php.net | confirmed | **A6** Established●●●●●● | 3/3 | PHP oss-security php.net |\n| The fix removes longjmp() for out-of-memory errors in favour of a delayed soft OOM at the next VM safe point and a hard OOM via _exit(); the changelog line is 'Avoid state corruption via bailout' | PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | PHP php.net php-src |\n| Updating is the only complete mitigation; the configuration measures reduce exposure to specific paths and do not make an installation safe | php.net; PHP security team | confirmed | **A6** Established●●●●●● | 3/3 | php.net oss-security PHP |\n| Triggering the bug is much easier than turning it into code execution; the CVSS vector says attack complexity highFastly: 'most deployments may be safe from RCE. Do not assume this holds true for you.' Imperva: five demonstrated techniques, three via session upload progress; about 67 KB of memory disclosed per attack. | Imperva; Fastly; the CVE record | confirmed | **A3** Echoed●●●○○○ opinion status overstated | 3/3 | Imperva Threat Research Fastly CVE record |\n| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed requestThe fix replaces bailout with a delayed error and an UnwindExit at a safe point, adds a hard limit that _exits, and resets the globals. See the code page. | php/php-src fix commit; the GitHub advisories | confirmed | **A6** Established●●●●●● | 3/3 | php/php-src, read from a clone PHP PHP |\n| Pre-authentication RCE was confirmed against WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCSTwo researcher parties, no third-party reproduction in the vault. The demo videos were not downloaded. | Calif; Wiz for WordPress and Drupal | reported | **A2** Reported●●○○○○ | 2/2 | Calif Wiz |\n| None of the public proof-of-concept exploits reviewed by VulnCheck has the correct mechanism; a lab reproduction of the leaked PoC's precondition produced a clean 200The Hacker News says the same of the public code. Fastly: working RCE needs knowledge of the running binary's layout on x86_64. | rjmendez (detection author) citing VulnCheck; Huntress | reported | **A1** Weak signal●○○○○○ status overstated | 1/2 | rjmendez, GitHub Huntress |\n| Patching the demonstrated paths does not make the bailout mechanism safe; more paths should be expectedA position, from a vendor; consistent with the Fediverse report of a third bug. | Fastly | reported | **A2** Reported●●○○○○ opinion | 1/2 | Fastly oss-security |\n| Remote code execution is confirmed on PHP-FPMGHSA-w8hw (CVE-2026-109618): 'no complete FPM exploit has been demonstrated for this SAPI'. The Foundation blog: RCE 'was also confirmed on PHP-FPM through application-level code paths'. GHSA-6wmf (CVE-2026-109619): session lifecycle RCE 'validated against mod_php and FPM'. The accounts may refer to different CVEs. | PHP Foundation blog; GHSA-6wmf for the session path | disputed | **A6** Established●●●●●● | 4/4 | PHP Foundation PHP PHP oss-security |\n| All PHP versions from 5 onwards are affected by at least one of the flawsThe CVE records list only 8.2 to 8.5 with defaultStatus 'unaffected'. php.net published source backports for 7.4, 8.0 and 8.1, which implies they are affected. A scanner that trusts the CVE record will miss 7.4 to 8.1. | NCSC-NL; Wiz ('>= 5.4'); CERT-FR (5.x, 6.x, 7.x, 8.0, 8.1) | disputed | **A3** Echoed●●●○○○ disputed | 3/4 | NCSC-NL Wiz on X CERT-FR oss-security |\n| A web application firewall may provide some protection until systems are patchedSwiss BACS: 'Even a web application firewall alone is not sufficient.' Cloudflare says its rules blocked the traffic it saw and that attackers mutated payloads to get past them. | CISA | disputed | **A6** Established●●●●●● | 3/3 | CISA BACS Cloudflare |\n| The flaws are CVSS 10.0The PHP Foundation: 'a wrong CVSS score of 10.0 (the actual score is 9.2)'. Daubois traces it to a social post relayed by Phoenix Security and to watchTowr via Cyber Daily. | social posts on 20 October, relayed by a vendor and a news site | contradicted | refuted contradicted | 1/2 | PHP Foundation Daubois |\n| The 8.5.12 fix may be incomplete, or there is a third, different bugPer a Matrix channel, Canonical asked PHP and 'was told that it's unrelated and not a real issue'. Second-hand. Nothing from PHP on the list at capture. | Fediverse posts relayed to oss-security by Aaron Rainbolt and Yves-Alexis Perez | unverified | **A1** Weak signal●○○○○○ opinion disputed | 0/1 | oss-security |\n\n## What is still open\n- Who first leaked the CVE IDs on 20 October, and where. The PHP Foundation does not say; a PHP security team member points to an anonymous Hacker News post. No copy of that post is in the vault.\n- Whether the deleted Calif video is the one now embedded on Calif's own write-up. Calif's page does not mention the leak.\n- Whether any site was actually compromised before it was patched or taken offline. Every claim of exploitation so far is of attempts, probes or honeypot hits.\n- Which sites were really taken offline, and why. The BBC's list (parts of Wikipedia, Edinburgh council, French government services, the University of Geneva, the BBC itself) has not been captured from any of those organisations. Latvia's geo-blocking is the one documented case, from the agency itself.\n- Whether the 8.5.12 fix is complete. A Fediverse report of a third bug or incomplete fix reached oss-security on 21 October; PHP reportedly told Canonical it is unrelated. Nothing from PHP on the list yet.\n\nThe full set of claims is on every claim; the ordered steps for a vulnerable system are on if you run PHP. Other readers: Curious reader · Website owner · Project or programme manager · Board member or executive · Security lead · PHP or platform engineer · Journalist · Security researcher · Analyst or policy advisor · CISO · CTO · CFO · Head of AppSec · Developer · Communications team."
    }
   ]
  }
 },
 "note": "The section ledger. Every major section of the site, every briefing and every fact is a projection of the data; its text is hashed on every build, and a new version is recorded only when that text changes. A version names the site release that created it and the date of that release. Versions marked reconstructed were rebuilt from the markdown twins and data files of earlier releases in git. Written by admin/build/build.py; never edit by hand."
}