PHP2Shell: How the Vulnerabilities Were Found—and What Developers Should Check

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

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.

How the vulnerabilities were found

Earlier investigation provided clues

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.

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

Calif revisited fatal-error behavior

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

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.

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

Wiz independently found related vulnerabilities

Wiz records its first discovery on 19 August, RCE validation against Drupal on 20 August and WordPress on 21 August, and reporting to PHP on 24 August.

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

These accounts describe overlapping work. They should not be compressed into a story about a single researcher, company or model finding everything.

What role did AI actually play?

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

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

The useful engineering lesson is to examine interrupted operations as carefully as successful ones:

Operation begins ↓ Some state becomes visible ↓ A failure interrupts initialization ↓ Cleanup or a later request trusts incomplete or stale state 

This is a conceptual explanation of the failure pattern, not an exploit recipe or a model of every affected path.

Does this mean every WordPress or Laravel site is exposed?

The application name alone cannot answer that question. The runtime build, hosting environment and applied fixes matter.

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

Keep maintaining the application. Also establish who maintains its runtime: your team, your hosting provider or another platform operator.

Which releases contain the upstream fixes?

PHP’s 21 October security releases are:

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

Ubuntu illustrates why the full package version matters: its notice lists fixed distribution builds, including 8.3.6-0ubuntu0.24.04.13 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 practical checklist for your team

Use the following as a working record for each deployment:

• Inventory: hostname or application, owner, hosting provider, PHP branch, full package/image version and web-serving runtime.
• Patch evidence: the applicable upstream release or vendor advisory confirming the backport. Record the complete build, not just “PHP 8.3.”
• Deployment: the package or image that was installed, where it was deployed and when the relevant workers were restarted or replaced.
• Verification: confirmation that web traffic is reaching the updated deployment, followed by normal application smoke checks.

Check the serving environment explicitly. A local terminal’s PHP binary is not evidence about every FPM pool, Apache instance, container or replica.

For a managed host, ask:

Have CVE-2026-109618 and CVE-2026-109619 been fixed in the PHP runtime serving our site? Which package or build contains the fix, and have all relevant workers been restarted or replaced?

This makes the response auditable without asking a website owner to diagnose engine internals.

If you cannot patch immediately

CERT-EU recommends considering isolation of internet-facing applications from public networks until the fix is applied and verified. It also emphasizes that temporary measures cover specific paths and do not make an installation safe. CERT-EU advisory

Choose interim controls with the operator responsible for that environment. Avoid copying a configuration change without understanding its availability effects and the attack paths it does not address.

What developers can take from this

Our practical interpretation of the published research is:

1. Review failure paths. Ask which state remains visible when initialization stops halfway through.
2. Keep discovery and proof separate. A suspicious pattern, a crash and demonstrated RCE provide different levels of evidence.
3. Make runtime ownership explicit. Application maintenance and runtime maintenance need named owners and separate verification.
4. Close the deployment loop. “The fix exists” and “our serving processes use it” are different milestones.

For this incident, prioritize patching and verifying the PHP deployment. A change of programming language is a separate architectural decision.

Need help with the PHP runtime behind your website? Contact TechWebster to discuss your setup and next steps.

This article summarizes the linked primary disclosures and separates reported research from our operational recommendations. We have not independently reproduced the exploits. Recheck the official advisories before applying changes, as guidance may evolve.