PHP2Shell: Patching PHP and Validating Exploit Claims

Evidence reviewed on October 22, 2026. Exploitation reports can change.

Check your website with BlackSight's free PHP2Shell checker. Get a quick public PHP version check, see the response evidence, and follow a remediation plan. Hidden or inconclusive versions still need confirmation from your host.

A repository called “exploit,” a convincing terminal transcript, and an AI-generated explanation can look like proof. A security assessment should ask a harder question: does the claimed behavior actually happen on the system being assessed?

The PHP2Shell discussion is a useful example of why that question matters. There are real vulnerabilities to fix, and there are public claims whose assumptions deserve scrutiny.

What PHP actually confirmed

PHP's October 21 security release addresses CVE-2026-109618 and CVE-2026-109619, involving unsafe memory handling during failed requests. The official advisory calls for urgent updates and describes demonstrated unauthenticated remote code execution on Apache with mod_php, before application code runs.

The PHP Foundation also says its team inspected circulating public PoCs and found no functional exploits among those reviewed at the time of disclosure. That is a useful, time-specific observation. It does not erase the working exploits already confirmed during the coordinated investigation. Read the maintainers' account.

What about exploitation in the wild?

As of October 22, “no exploitation has been observed” would be misleading. Cloudflare reports attack traffic targeting the vulnerabilities. AWS reports an attempt against its honeypots dating to October 17 and describes broader exploitation after disclosure. AWS also notes uncertainty about whether the earlier attempts would have succeeded against real-world systems.

A vulnerable deployment, a working laboratory exploit, an attack attempt, and a confirmed breach are different findings. An alert should say which one the evidence supports. Calling every probe a breach exaggerates impact; calling the whole incident AI hype dismisses confirmed security work.

Where the criticism of AI-generated PoCs matters

In his October 21 essay, Elias Taylor argues that some circulating PHP exploit demonstrations depend on altered test servers or additional application vulnerabilities. He criticizes accepting an LLM's success claim without running and inspecting the test independently. He also explicitly advises readers to patch.

That critique gives reviewers a concrete check: inspect the target as carefully as the exploit. If a demonstration adds an unsafe file-inclusion endpoint, the report must disclose that prerequisite. It cannot quietly turn a specially weakened test application into a claim about every PHP website.

We have not independently reproduced the repositories Taylor discusses. His assessment of those examples should be treated as attributed analysis, rather than a blanket verdict on all PHP2Shell exploits.

What a manual penetration test should establish

A useful manual pentest connects a suspected weakness to a reproducible result on the agreed target. The person signing the report should verify the result independently, regardless of who or what generated the script.

• Environment: record the actual runtime, configuration, application, and relevant security controls.
• Prerequisites: state any required access, extra bug, information leak, or configuration change.
• Evidence: distinguish a crash or response anomaly from demonstrated code execution or data access.
• Impact: explain the privileges and data reached, within the agreed testing scope.
• Remediation: check that the fix addresses the observed behavior and document any remaining uncertainty.

AI can help investigate and draft tests. A human-written report can overstate a finding too. The standard should be reproducibility and independently checked impact, with failed assumptions recorded instead of hidden.

Which PHP versions need an update?

Use the following minimum fixed versions for upstream PHP builds. The CVE-2026-109618 advisory and CVE-2026-109619 advisory list the same fixed releases. Choose the latest supported patch release in your branch that includes both fixes.

PHP 8.1 and older no longer receive upstream security updates. Obtain a confirmed fix from a vendor that still supports your installation, or migrate to a supported branch. PHP's release advisory says there is no complete configuration workaround. A WAF can reduce exposure while you update; it does not replace the runtime fix.

Before changing production, back up application files, configuration, and databases; test the patch with your extensions and application. The commands below are examples for the stated installation. Use the branch, service name, and package source your website actually uses. Worker restarts can briefly interrupt requests, so use your normal maintenance or rolling deployment procedure.

Linux: Debian, Ubuntu, and RHEL-family servers

Debian and Ubuntu: refresh package metadata and apply updates through your configured repositories. This example performs the normal system package upgrade, including PHP; review the proposed changes before confirming. Check that PHP packages were upgraded and were not kept back or pinned to an unfixed build. Ubuntu documents this APT workflow.

sudo apt update
sudo apt upgrade
dpkg -l 'php*'

Then restart the PHP service used by your site. For example, a site using PHP 8.3-FPM needs sudo systemctl restart php8.3-fpm. If Apache loads PHP as mod_php, restart Apache with sudo systemctl restart apache2. Restarting Nginx alone does not replace PHP-FPM workers. Adjust the service name for PHP 8.2, 8.4, or your hosting package.

Check the complete package version. Ubuntu 24.04's fixed PHP 8.3 package is 8.3.6-0ubuntu0.24.04.13, according to its first CVE tracker and second CVE tracker. The “8.3.6” prefix does not make that patched Ubuntu package vulnerable. Debian's corresponding trackers for CVE-2026-109618 and CVE-2026-109619 list fixed Bookworm and Trixie packages. Match the advisory to your distribution and repository; an Ubuntu fix number says nothing about a third-party PHP build.

RHEL, Rocky Linux, AlmaLinux, and Fedora: check your vendor's advisory for your release and PHP stream. For standard packages named php*, update them and restart the installed FPM service:

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm
rpm -qa 'php*'

Red Hat's DNF instructions explain package updates. A successful command does not prove that a fixed package was available: compare the installed build with your vendor's erratum. Remi collections, control panels, source builds, and other custom installations can use different package and service names. Update those through their provider rather than switching package streams blindly.

Windows: IIS, Apache, and bundled PHP

1. Find the PHP installation configured in the website's handler. Download a patched build from the official PHP Windows downloads. Match the architecture and extension requirements. Use Non-Thread-Safe (NTS) for IIS/FastCGI and Thread-Safe (TS) for Apache with mod_php, as described in PHP's Windows installation guide.
2. Extract the replacement into a new directory and carry over the reviewed php.ini settings. Install compatible extensions; do not mix arbitrary DLLs from different PHP builds.
3. For IIS, point the site's FastCGI application and handler mapping at the new php-cgi.exe. PHP's IIS guide explains the handler. Recycle the affected application pool and confirm the old PHP processes have exited. For Apache mod_php, update the configured module path and restart that Apache service.
4. Test the site through the browser and confirm the runtime it uses. For XAMPP, WampServer, or another bundle, obtain a vendor-supported update that actually includes the PHP fixes; Windows Update alone does not establish this.

As an additional check, run php.exe -v from the new installation's directory. That checks the binary on disk, not which executable IIS is still using.

macOS: Homebrew and local development stacks

If your site uses Homebrew's php@8.4 formula and its FPM service, update that formula and restart it. Homebrew lists 8.4.27 as the patched PHP 8.4 release.

brew update
brew upgrade php@8.4
brew services restart php@8.4
"$(brew --prefix php@8.4)/bin/php" -v

Use your installed formula name, such as php or php@8.3, instead of changing branches just to match this example. If Apache loads PHP directly, restart that Apache service too. The Homebrew manual documents upgrade and service commands. For MAMP or another bundled stack, update through its vendor and select the patched runtime in the application. Updating your Mac's Homebrew PHP does not update MAMP's separate copy or your production host.

Docker: replace the image and running containers

Change the PHP image tag or pinned digest in your deployment to a release containing the fixes, keeping the appropriate FPM/Apache variant and compatible extensions. Updating PHP on the Docker host does not patch the PHP binary inside a container. For a Compose service named php that uses a prebuilt image:

docker compose pull php
docker compose up -d --no-deps --force-recreate php
docker compose exec php php -v

Use your actual service name. A pull only fetches the image; recreating the service starts containers from it. If you build your own image, update its FROM reference, run docker compose build --pull php, then recreate the service. Docker documents this in its build reference. Verify every replica after rollout. For WordPress images, replace the image that contains WordPress's PHP runtime. Preserve your existing database and upload volumes.

WordPress and shared hosting: what to change and ask your host

Updating WordPress core, plugins, or themes does not update PHP. In WordPress, open Tools → Site Health → Info → Server to see the version serving your site. WordPress's PHP update guide explains the hosting workflow. Its general recommended branch is not a check for these specific security patches.

1. Back up files and the database, and check theme/plugin compatibility on staging.
2. In your hosting panel, choose a supported PHP branch whose installed patch level includes the fixes. A selector that only says “8.3” or “8.4” is not enough evidence.
3. Ask the host to confirm both CVEs are fixed in the package serving your domain and that old workers have been replaced. Shared-hosting customers usually need the host to install the server package itself.
4. Recheck Site Health and test sign-in, forms, uploads, and checkout if applicable. For a vendor backport, retain the host's full package-build confirmation too.

Message to your hosting provider: Please confirm that the PHP runtime serving my domain contains fixes for CVE-2026-109618 and CVE-2026-109619. Which complete package version or image is deployed, and have the old PHP workers been restarted or replaced? If a fix is pending, what is the update plan?

The same runtime check applies to Drupal, Joomla, Magento, and other PHP applications. Keep their supported PHP versions and extension requirements in mind when choosing an upgrade path.

How to verify the fix is actually deployed

• Match the website's configured handler to the updated PHP installation. Check the full package build or image against the vendor advisory; php -v in a shell can refer to another installation.
• Confirm every web node and replica has replaced its old workers. Use authenticated application diagnostics, WordPress Site Health, or your hosting inventory rather than leaving a public phpinfo() page online.
• Test normal application requests and review PHP/web-server error logs after the update. A clean external scan or a missing version header does not prove patch status.
• If you suspect earlier compromise, preserve and investigate server-side evidence. Patching closes the vulnerability; it does not remove an attacker or a web shell already present.

Datadog's technical analysis discusses runtime inventory and investigation signals. Treat suspicious process execution and file changes as evidence to investigate, not as something a version update automatically resolves.

At a minimum, set up BlackSight's free plan

We recommend setting up scanner.blacksight.io as a minimum security baseline for your website, even if you stay on the Free plan. It costs $0 and requires no credit card. Make checking your public website a routine alongside keeping PHP and your application updated.

1. Create your free account, add your main website, and complete domain verification to unlock its available scan types.
2. Run the included checks, such as SSL, security headers, and CMS scanning. Review the findings and work through the recommended fixes.
3. Enable scheduled scanning within your plan's limits, review new reports, and re-scan after changes when your scan allowance permits.

Free includes one instant scan per month and one scheduled scan per quarter for each supported scan type, with 30-day report history. It provides a starting point for regular checks; more frequent scanning and additional scan types are available on paid plans.

Set up your free BlackSight account

What scanning can establish

On paid plans, BlackSight's technology scan can help identify exposed runtime information and flag supported version evidence for review. Web, SSL, and security-header scans provide additional checks of what your public service exposes. These findings help prioritize work; they do not certify that PHP2Shell is exploitable or that the runtime is patched.

Combine recurring scanning with manual penetration testing when you need deeper validation of application-specific impact. Our guide to scanning and pentesting explains how they work together. Teams using an AI assistant can also retrieve reports through BlackSight's MCP integration while keeping human review part of the workflow.

Frequently asked questions

Is PHP2Shell just an AI false alarm?

No. PHP's maintainers confirmed working exploits for the underlying vulnerabilities. AI-generated public proof-of-concept claims still need independent validation, but unreliable demonstrations do not invalidate the security fixes.

Have PHP2Shell exploitation attempts been reported?

Yes. As of October 22, 2026, AWS and Cloudflare report attack activity. An attempted exploit does not by itself prove that a particular website was compromised. The PHP team's earlier observation about public PoCs was limited to what it reviewed at disclosure time.

What should a manual pentest validate?

The tester should document the actual environment, verify every prerequisite, reproduce the behavior independently within the agreed scope, establish impact from server-side evidence, and check the remediation.

Which PHP versions fix PHP2Shell?

The first fixed upstream releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Install a supported release containing both fixes, or the fixed package specified by your Linux or hosting vendor. Vendor backports can retain an older-looking PHP version number.

Does updating WordPress fix PHP2Shell?

Updating WordPress core, themes, or plugins does not update the server's PHP runtime. Use your hosting provider's PHP settings or ask support to apply fixes for both CVE-2026-109618 and CVE-2026-109619. In WordPress, Tools → Site Health → Info → Server shows the PHP version used for the web request.

How do I check that the website is using patched PHP?

Check the PHP handler serving the website, the installed package build or deployed image, and your vendor's advisory. Restart or replace old PHP workers and verify every server or replica. A command-line php -v check alone can inspect a different installation from the one serving the website.

Can I start with BlackSight's free plan?

Yes. Set up a free account at scanner.blacksight.io, add and verify your main website, and run the included checks as a security baseline. Free includes limited scanner types, one instant scan per month and one scheduled scan per quarter per supported scan type, and 30-day report history. No credit card is required. Scanning complements PHP patching; it does not certify that PHP2Shell is fixed.

Can a website scanner prove that PHP2Shell has been fixed?

External scanning can help identify exposed technology and other observable weaknesses. Confirming this runtime fix requires checking deployed PHP packages or images and any vendor backports. A clean external scan alone is not proof that the PHP runtime is patched.