{"id":6248,"date":"2026-10-22T04:22:54","date_gmt":"2026-10-22T07:22:54","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/10\/22\/php2shell-how-the-vulnerabilities-were-found-and-what-developers-should-check\/"},"modified":"2026-10-22T04:22:54","modified_gmt":"2026-10-22T07:22:54","slug":"php2shell-how-the-vulnerabilities-were-found-and-what-developers-should-check","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/10\/22\/php2shell-how-the-vulnerabilities-were-found-and-what-developers-should-check\/","title":{"rendered":"PHP2Shell: How the Vulnerabilities Were Found\u2014and What Developers Should Check"},"content":{"rendered":"
\n
\n

PHP lists PHP-FPM, Apache with mod_php<\/code>, php-cgi<\/code>, FrankenPHP and LiteSpeed among the affected web-serving setups. It identifies mod_php<\/code> as the highest-risk setup, with a demonstrated attack that runs before application code. PHP’s security advisory<\/a><\/p>\n

This is a runtime security issue. A vulnerable installation and a confirmed compromise are different findings; discovering an affected version does not establish that an attacker has used it.<\/p>\n

<\/a> How the vulnerabilities were found <\/h2>\n

<\/a> Earlier investigation provided clues <\/h3>\n

The PHP Foundation describes a 2024 audit performed by Quarkslab through OSTIF. While fixing an audit finding, a PHP core developer found signs of the OOM problem later associated with CVE-2026-109618.<\/p>\n

At that stage, a potential exploit had been theorized, but concrete attack vectors had not been found. The Foundation describes difficult compatibility and implementation trade-offs, limited specialist capacity and a decision process that delayed a fix. That is more precise than saying nobody had noticed anything before 2026. PHP Foundation’s account<\/a><\/p>\n

<\/a> Calif revisited fatal-error behavior <\/h3>\n

In its own account, Calif dates the start of its audit to 30 July 2026<\/strong> and its first discovery to 1 August<\/strong>. Researcher Ryan Austin examined memory-limit failures and the points where they could interrupt PHP’s native operations.<\/p>\n

One finding involved bookkeeping becoming visible before an operation had fully initialized its data. If an allocation failed at that point, later cleanup could treat unfinished data as valid. Calif then used the observed pattern to guide AI-assisted searches for related failure paths.<\/p>\n

Its timeline separates discovery from reporting: the first bug was reported to PHP on 11 August<\/strong>, followed by an RCE proof of concept on 14 August<\/strong>. Calif’s original write-up<\/a><\/p>\n

<\/a> Wiz independently found related vulnerabilities <\/h3>\n

Wiz records its first discovery on 19 August<\/strong>, RCE validation against Drupal on 20 August<\/strong> and WordPress on 21 August<\/strong>, and reporting to PHP on 24 August<\/strong>.<\/p>\n

Its write-up describes four exploitable instances grouped into the two CVEs, including memory disclosure and memory corruption. WordPress, Drupal and Joomla were demonstration targets, rather than the location of the underlying PHP engine flaws. Wiz’s research and timeline<\/a><\/p>\n

These accounts describe overlapping work. They should not be compressed into a story about a single researcher, company or model finding everything.<\/p>\n

<\/a> What role did AI actually play? <\/h2>\n

The published accounts describe researchers directing AI-assisted investigation, testing and validation. OpenAI says Calif identified a critical flaw using GPT-5.6 Sol through Patch the Planet, while Wiz independently discovered and reported both vulnerabilities. PHP’s maintainers led the fixes and release. OpenAI’s coordination account<\/a><\/p>\n

Wiz reports using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol. It says adapting working exploit chains required repeated testing and debugging across different memory layouts and that frontier models reduced that effort. Those are the research team’s reported results, not a benchmark we independently reproduced. Wiz’s description of AI’s role<\/a><\/p>\n

The useful engineering lesson is to examine interrupted operations as carefully as successful ones: <\/p>\n

\n
Operation begins \u2193 Some state becomes visible \u2193 A failure interrupts initialization \u2193 Cleanup or a later request trusts incomplete or stale state <\/code><\/pre>\n
\n<\/p><\/div>\n<\/p><\/div>\n
This is a conceptual explanation of the failure pattern, not an exploit recipe or a model of every affected path.<\/p>\n
  <\/a> Does this mean every WordPress or Laravel site is exposed? <\/h2>\n
The application name alone cannot answer that question. The runtime build, hosting environment and applied fixes matter.<\/p>\n
For example, Automattic stated on 21 October that WordPress.com, WordPress VIP, WP Cloud, Pressable and Tumblr were already protected. That prevents a misleading conclusion that every WordPress installation still requires its owner to patch PHP personally. Automattic also explains that application, theme and plugin updates alone do not replace a runtime fix. Automattic’s notice<\/a><\/p>\n
Keep maintaining the application. Also establish who maintains its runtime: your team, your hosting provider or another platform operator.<\/p>\n
  <\/a> Which releases contain the upstream fixes? <\/h2>\n
PHP’s 21 October security releases are:<\/p>\n
\n\n\n\n\n\n\n\n\n
PHP branch<\/th>\nFixed upstream release<\/th>\n<\/tr>\n<\/thead>\n
8.5<\/td>\n8.5.12<\/td>\n<\/tr>\n
8.4<\/td>\n8.4.27<\/td>\n<\/tr>\n
8.3<\/td>\n8.3.36<\/td>\n<\/tr>\n
8.2<\/td>\n8.2.35<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
Distribution and LTS vendors may backport the fix while retaining an older upstream version number. PHP 8.1 and older have no routine upstream updates; vendor fixes and exceptional minimal source backports for 7.4, 8.0 and 8.1 require checking the relevant guidance. PHP release and update guidance<\/a><\/p>\n
Ubuntu illustrates why the full package version matters: its notice lists fixed distribution builds, including 8.3.6-0ubuntu0.24.04.13<\/code> for Ubuntu 24.04. It also states that applications using PHP may need restarting after the update; installing packages alone may leave old processes running. Ubuntu’s package and restart guidance<\/a><\/p>\n
  <\/a> A practical checklist for your team <\/h2>\n
Use the following as a working record for each deployment:<\/p>\n