PHP2Shell: How Hard Is It to Exploit, and What PHP Is Changing

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is harder to exploit than the first wave of alarm suggested, and most public proof of concept code appears not to work. That does not make it safe to wait. Skilled teams built working exploits, and attacks are reported. Upgrade PHP, restart workers, and check logs back to 17 October.

Two posts topped Hacker News on 22 October. One, from independent writer Elias Taylor, argues there is no easy exploit for the bug. The other, from the PHP Foundation, explains the release and lists what the project is changing so the next serious bug is fixed faster. This post weighs the first against the other attributed sources, then sets out what the second commits to. Our PHP2Shell explainer covers the flaws, versions and workarounds; we do not repeat them, and we give no exploit details.

What changed since release day

By 22 October the question had moved from whether the bug was real to how hard it is to use.

Two of these rows conflict. The Foundation says its team had identified no functional exploits at release. Amazon reports proof of concept code circulating hours before release and attempts as early as 17 October. Both can be true at once: an attempt is not the same as a working exploit, and Amazon itself says it does not yet know whether any of the attempts it saw would have worked against real systems.

The case that it is hard to exploit

Elias Taylor's post, published 21 October, is short and makes a narrow argument. Here is a fair summary in our words.

• There is a real bug. Taylor does not say PHP2Shell is fake or harmless. The post states plainly that there is a bug and that it matters.
• The public exploits mostly do not work. Taylor says thousands of repositories claiming to be proofs of concept appeared, and that many do not work against a plain PHP install. The suggested test is to run them yourself in a disposable Docker-hosted PHP server rather than trust a model's account of whether they work.
• Many depend on a second, serious hole. According to the post, a lot of the public code only succeeds when the target already has something like a local file inclusion flaw. If an attacker already has that, the server was in deep trouble anyway, so the extra severity from PHP2Shell is smaller than it looks.
• The comparison is to the easy ones. Taylor contrasts this with bugs such as Log4Shell, Heartbleed and Shellshock, where botnets appeared quickly because exploitation was trivial. The conclusion: "This is too difficult to exploit easily." The post adds that this is not a Log4j moment.
• Why people panicked. Taylor points to a core team member calling the issue cataclysmic, a belief that PHP is insecure, a flashy exploit video, and anxiety about AI.
• A point about AI-written exploits. Taylor argues that many of the public PoCs look as though a language model made the design decisions, and suggests some only "work" because the test server was modified to add a vulnerability.

What the post does not do matters as much. It does not name a SAPI such as mod_php or PHP-FPM, it does not discuss the official advisories, and it refers only to public GitHub code, not the exploits the original reporters built. It also does not tell readers to skip or delay patching. It is a critique of the public PoC flood and of the hype, not a claim that the bug cannot be exploited.

That critique has merit. Tenable also says it has not verified that circulating code works and warns it can carry malware. An exploit that needs a separate file inclusion bug is far less urgent than one that does not.

The case that it is exploitable enough

The other sources describe different evidence: exploits built by the reporters, and sensor traffic.

The official advisory. PHP's GitHub advisory for CVE-2026-109618 says full RCE was validated over HTTP against Apache mod_php with default input and memory limits and normal multi-worker prefork settings. That is not a lab modified to add a hole. Yet the same advisory supports part of Taylor's point: its CVSS v4.0 vector marks attack complexity as high and attack requirements as present, and it says exploit portability and reliability depend on the PHP build, extensions, front end behaviour and memory allocator layout. In plain terms: it works, and it is fiddly.

The Foundation. Its post adds that RCE was also confirmed on PHP-FPM through application-level code paths, and that the second bug was used for RCE against a real application on mod_php.

Wiz. Wiz says it showed unauthenticated RCE against the latest WordPress, Drupal and Joomla container images it tested, and that a plain "Hello World" app on a vulnerable version is also exposed because the flaw is in PHP itself. Wiz also describes a memory disclosure path that can read passwords, tokens or API keys from worker memory without code execution. On difficulty, Wiz is candid: building a working exploit meant chaining several bugs and adapting to each target's memory layout through repeated testing. It credits frontier AI models with lowering that barrier, saying its team could adapt exploits across several applications within hours.

Sensor networks. Here the sources disagree, and the disagreement is mostly about time.

watchTowr's FAQ still carried some pre-release text when we read it on 22 October, so use it for the exploitation note, not patch status.

Weighing it up

Read side by side, these sources are less contradictory than the headlines.

1. Public PoC code and reporter exploits are different things. Taylor's evidence is about the public flood. The advisory, the Foundation and Wiz are about exploits built by the reporters. Both observations can stand: most public code is junk, and a skilled team has working chains.
2. Hard is not the same as rare. A bug that needs tuning per target is slow for a script and fast for a capable group. Wiz says AI tools let its team adapt exploits across applications within hours, which narrows the gap between "hard" and "routine".
3. Attempts are not compromises. Amazon's report is about attack traffic hitting honeypots, and Amazon says it does not yet know whether those attempts would have worked. Huntress seeing nothing across its partners on day one fits that picture.
4. Memory disclosure lowers the bar. Even where code execution is unreliable, Wiz says secrets can be read from worker memory without it.
5. Your exposure depends on your SAPI. The advisory puts mod_php first and FPM next. Taylor's post does not address SAPIs, so it cannot tell you whether yours is the easy case.

Our reading: Taylor is right that the public exploit flood was overstated and that this is not a Log4Shell-style free-for-all. That supports calm, not delay. The same day, the people who found the bug showed RCE on default mod_php and on major CMS images, and Amazon reported attempts going back four days before disclosure.

How difficulty should change your plan, and how it should not

"Hard to exploit" is useful for ordering work. It is not a reason to drop anything from the list.

What difficulty should not change: whether you upgrade, whether you restart workers, and whether you look back at logs. Amazon advises starting any investigation from 17 October, not the disclosure date.

What the PHP Foundation says it is changing

The Foundation's post is frank about why a bug first spotted in 2024, during work on PHP's external audit, took until October 2026 to fix. It says competing fixes each had costs (breaking compatibility, adding denial of service risk, or forcing changes across many extensions), the consensus-based security team could not settle on one, and work stalled and restarted for months. It calls this "a structural failure" of decision-making and resourcing.

Here is what the post says is changing.

People. An Ecosystem Security Team, set up by the Foundation in May 2026, works with the PHP security team on triage, coordination and hardening. Volker Dusch is the Foundation's AI Security Engineer in Residence. Alexandre Daubois joined in July 2026 to triage and fix security reports, and Daniel Scherzer joined in September for hardening work.

Decisions.

• The security team is changing its process so decisions can be made by majority, with compromise encouraged. The post says this work continues.
• Project leadership will be brought in sooner on serious vulnerabilities with hard trade-offs.
• Measures are being prioritised so that bugs needing complex fixes are resolved faster, and the post commits to turning this experience into lasting, repeatable processes.

Funding. Foundation money let several people work on the out-of-memory fix full time from 11 August, including weekends. The post asks companies that depend on PHP, hosting providers, cloud platforms, distributions and governments to fund this work, and points to the Sovereign Tech Agency's funding of the 2024 audit as a model.

Tooling and AI.

• Alpha-Omega worked with Anthropic's Claude Mythos to scan PHP earlier in 2026, and the Foundation later added OpenAI's Daybreak Red to validate reports and exploits.
• AI also helps triage and group reports that share a root cause, but the post says a person makes every decision and works on every patch.
• Sanitizer builds and reproduction environments matching CI on every supported platform.
• Since 1 July the team has published 15 CVEs and closed over 100 invalid, duplicate or unreproducible reports.

Delivery. The fix was shipped across all supported branches, and distributions and LTS vendors got the patch in advance.

What the post does not announce. No new embargo rules, no end-of-life or backport policy change, no fuzzing programme, no memory safety initiative, and no dates for most of the changes.

The Foundation's 14 October post adds context: the PHP Group has been a CVE Numbering Authority for php-src since 2019, reports go through php-src's GitHub security advisory form, and AI-assisted reports are accepted only if reproduced on a real PHP build.

What the leak teaches about disclosure

The Foundation's account of 20 and 21 October lists four separate leaks: CVE IDs with wrong details, a proof of concept video published by mistake, mitigation advice shared with some critical infrastructure providers that may have spread, and built images with the fix published hours early. None were technical write-ups, yet together they gave attackers a head start. We assign no blame; the lesson is that an embargo now has many participants, and each is a possible leak. Our post on AI found vulnerabilities covers why that number keeps growing.

What to do now

Our fleet-wide guide covers finding and patching every PHP runtime. These steps cover what the difficulty debate adds.

1. Confirm the fix is live in the process that serves traffic. A patched package on disk does nothing until workers restart.

# Which PHP does the web server actually run?
sudo apachectl -M 2>/dev/null | grep -i php        # mod_php loaded?
php-fpm8.3 -v                                       # adjust binary name
# Workers started before the upgrade are still running old code
ps -eo pid,lstart,comm | grep -E 'php-fpm|apache2|httpd'

2. Do not use a public PoC to decide whether you are safe. Taylor's point cuts both ways: if most public code fails even on vulnerable installs, a failed test proves nothing. Check versions instead. If you want to test claims, do it as Taylor suggests, in a disposable lab, never on production.

3. Look back to 17 October, not 21 October. Amazon recommends this window. Start with web server error logs, since Wiz lists memory limit errors after unusual multipart requests as a sign to investigate.

# Memory limit errors since 17 Oct (adjust paths for your distro)
sudo grep -h "Allowed memory size" /var/log/apache2/error.log* /var/log/php*-fpm.log* 2>/dev/null | wc -l

# Bursts of HTTP 500s in access logs
sudo awk '$9 == 500' /var/log/apache2/access.log | awk '{print $4}' | cut -d: -f1,2 | sort | uniq -c | sort -rn | head

4. Search request body or WAF logs for upload progress fields. Amazon suggests looking for POST requests that contain the string PHP_SESSION_UPLOAD_PROGRESS. Most access logs do not record bodies, so this check belongs in WAF or reverse proxy logs if you keep them.

5. Check for new or changed PHP files since 17 October.

sudo find /var/www -type f -name '*.php' -newermt 2026-10-17 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

6. Look for processes started by web workers. Amazon and Huntress both point to unexpected child processes. A shell, curl or wget under a PHP worker deserves a closer look.

ps -eo pid,ppid,user,comm --forest | grep -B1 -A3 -E 'php-fpm|apache2|httpd' | grep -E 'sh|bash|curl|wget|python|perl'

7. Rotate secrets on any server that was exposed and unpatched. Wiz's memory disclosure path means database passwords, API keys and session signing keys in worker memory may have been read without any code running.

8. Write down any delay. If you defer a patch because exploitation looks hard, record who decided, for which systems and until when, and revisit it daily.

What would have helped

The difficulty debate matters less to teams who can patch in hours.

• A known list of SAPIs, not just versions. The difference between mod_php and FPM changed the risk. Record the SAPI next to each PHP version in your inventory.
• A rebuild path measured in hours. Amazon recommends timelines for critical internet-facing bugs in hours rather than days. That only works if base image bumps and redeploys are routine.
• Behaviour-based detection. Amazon advises detections that do not depend on CVE signatures. A PHP worker spawning a shell is suspicious whatever the bug.
• Cheap secret rotation. Short-lived credentials limit the damage from memory disclosure bugs.
• Supporting the projects you depend on. The Foundation is explicit that full-time people and funding are what unstuck this fix. If PHP runs your business, that is a supply chain line item.

Where Safeguard fits

Safeguard would not have prevented PHP2Shell, does not patch servers and does not tell you whether an exploit works. It helps with knowing where PHP is and making the change quickly.

• Finding PHP in what you build. safeguard scan --image <name> builds an SBOM of a container image and lists the PHP it ships; safeguard scan --sbom <file> does the same for SBOMs from vendors; safeguard scan --dir . covers repositories. Results land as JSON under ./output. For a flaw this new, check the PHP version in the SBOM directly rather than waiting for database matches.
• Which projects ship this version. The platform shows which projects contain a given component and version. See SBOM incident response for that workflow.
• Prioritising honestly. Reachability analysis helps rank many findings, but it does not lower the priority here, because PHP2Shell triggers in the runtime before your code runs.
• Gates. Once the CVEs are in your findings, policies and gates evaluated in the platform can stop a build that still ships an unpatched PHP image.
• Making the change. The Safeguard CLI's assistant can edit a Dockerfile to a patched base image and run your build and tests, asking before each command under its default permission mode. The desktop and phone apps can send that work to a computer running the CLI and approve each command.

Where it does not help: PHP installed by hand on hosts you never scan, managed hosting and appliances you cannot inspect, restarting workers, reading request bodies, judging exploit difficulty, or detecting a break-in.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. PHP core is a C runtime outside those ecosystems, and PHP2Shell was found by Calif, OpenAI and Wiz, as the Foundation's post credits. We make no claim that Safeguard found it.

Gold Open Source (gold.safeguard.sh, free, no login) is searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action.

Gold Registry (registry.safeguard.sh, paid) provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore-signed, with evidence pages; an artifact loses its badge on regression. We are not claiming a patched PHP build was available there before the public fix. The habit it supports is the one that matters here: take patched, signed components from a curated source and rebuild fast when a fix lands.

Common mistakes

• Treating "hard to exploit" as "safe to wait". Taylor's post does not say that, and the official advisory shows RCE on default mod_php.
• Treating "broadly exploited" as "you are breached". Amazon is describing attempts on honeypots. Check your own logs before assuming the worst.
• Ignoring memory disclosure. If full RCE is unreliable on your stack, secrets in memory may still have leaked.

Troubleshooting

• Version looks old after patching. Distribution packages often backport fixes without changing the upstream number. Check the changelog for the CVE IDs.
• Workers die more often after upgrade. PHP's advisory says the fix stops at the next safe point and adds a hard exit at a higher memory threshold. Review memory_limit and post_max_size in your pool settings.
• No body logs to search. Turn on request body logging at your WAF or proxy for the next few weeks, scoped to POST requests with multipart bodies.

FAQ

Is PHP2Shell hard to exploit?

Harder than the first posts suggested. The official advisory rates attack complexity high, but it also says full RCE was validated on Apache mod_php with default settings, and Wiz showed RCE against WordPress, Drupal and Joomla images.

Is Elias Taylor's analysis wrong?

Not on its own terms. It argues the public PoC flood mostly does not work and that many require a second vulnerability. It does not test the reporters' exploits, discuss SAPIs, or advise against patching. It and the advisory describe different code.

Is PHP2Shell being exploited in the wild?

Sources disagree. Amazon says it is now broadly exploited, with an attempt on 17 October, and watchTowr reports honeypot hits. Huntress had seen none across its partners on 21 October. Amazon does not yet know whether the attempts it saw would have worked.

Should I still patch if exploitation is hard?

Yes. Upgrading to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restarting workers is the only complete fix, per PHP, Wiz and Amazon. Difficulty only changes order: mod_php facing the internet goes first.

What is the PHP Foundation changing?

More security staff, majority decisions in the security team, earlier leadership involvement for hard trade-offs, funding for full-time fix work, AI tools for validation and triage with humans making every call, and sanitizer-based reproduction on every supported platform. It did not announce new embargo or EOL rules.

Did AI make PHP2Shell easier to exploit?

Wiz says frontier models lowered the barrier and let it adapt exploits within hours. Taylor argues AI also produced many broken public PoCs. Both effects are visible in the same week.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

The CLI demo is a real session fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json and runs install and tests with your approval. For PHP2Shell you would run the same loop against your PHP image: ask the assistant to bump the base image tag in your Dockerfile, rebuild, and rerun php -v inside the container, approving each command. The demo does not show this incident.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on your computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here the folder would be the repository that holds your PHP Dockerfiles or Ansible roles, and the edits would be the version bump plus the restart step, each reviewed before it runs.

Click through it at your own pace, or open it full screen.

The mobile demo is a real Android session: work goes to a computer running the CLI and you approve the command on the phone with Allow once, Allow for turn or Deny. PHP2Shell leaked on a Tuesday evening and fixes landed the next afternoon; this is how you would approve a rebuild and worker restart away from your desk.

Click through it at your own pace, or open it full screen.

To scan the images you build and run, download Safeguard and follow the CLI docs. For the wider picture, see governments taking websites offline over PHP2Shell and October 2026 security incidents and what would have helped.

Quick check

Sources

• PHP Foundation: Today's PHP security release, and how we're strengthening PHP security (21 Oct)
• PHP Foundation: How the PHP security team handles your reports (14 Oct)
• GHSA-w8hw-w9fx-j79w: RCE via OOM corruption, CVE-2026-109618 (php-src on GitHub)
• Elias Taylor: There isn't an easy exploit for this PHP vulnerability
• Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure in MadPot
• Wiz Research: PHP2Shell
• watchTowr: PHP CVE-2026-109618 FAQ
• Huntress: php2shell, leaked critical PHP vulnerabilities
• Tenable: PHP2Shell frequently asked questions
• Help Net Security: PHP2Shell vulnerabilities patched (updated 22 Oct)
• UK NCSC: Critical security issue affecting PHP

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.