PHP2Shell: Two vulnerabilities, one global security challenge

When details of two critical PHP vulnerabilities leaked before their scheduled disclosure, many security teams had less than a day to answer one question: Are we running vulnerable versions?

The flaws, CVE-2026-109618 and CVE-2026-109619, allow unauthenticated attackers to run commands on affected servers through crafted web requests. No login is required. Both vulnerabilities received critical severity ratings of 9.2 under CVSS v4.0. Because the vulnerabilities exist in PHP itself, even well-written applications may be exposed if they run on a vulnerable PHP installation. Code quality alone can't protect against a vulnerability in the underlying runtime.

The scale makes the problem larger. PHP powers a significant portion of the web, including websites built on WordPress, Joomla, and Drupal. According to VirusTotal research, approximately 5.1 million IP addresses were identified as running PHP, with roughly 3.8 million having at least one open port. Not all are necessarily vulnerable or exploitable, but the numbers illustrate why PHP2Shell became a global security concern.
 

Knowing where you’re exposed is the hard part

Applying patches is relatively straightforward. The harder work is finding every place PHP runs, including servers, containers, base images, developer machines, and managed services.

A vulnerable version number doesn't automatically mean a system can be exploited. Exposure depends on how PHP is deployed. PHP's security advisory identified Apache with mod_php as the highest-risk configuration because an attack can succeed before application code runs. PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed were also identified as affected, making deployment configurations just as important as version numbers.

Managed hosting adds another layer of complexity. If you can't see the runtime, you can't verify whether it's vulnerable or patched. Ask your providers which PHP versions and handlers they run, when patches will be applied, and how they'll notify you once updates are complete. Document their responses, because a general assurance that they're handling the issue isn't the same as knowing your exposure.

A firewall rule is a stopgap

Cloudflare and other providers deployed web application firewall (WAF) rules to block known attack methods. These measures bought teams time, but Cloudflare reported detecting early exploitation attempts before patches were released. Attackers were already looking for ways in.

However, PHP's developers warned that no mitigation fully prevents exploitation, and that patching is the only lasting fix. Their interim guidance included lowering post_max_size, disabling session.upload_progress.enabled, and adjusting PHP memory settings while enforcing limits at the container or operating system level. These measures can reduce exposure to certain attack paths, but they may also affect application functionality, including file uploads.

Treat these measures as temporary safeguards. WAF rules provide an additional layer of protection while you patch, but they aren't a substitute for updating vulnerable PHP installations.

Patch fast without skipping the checks

Emergency fixes still require testing, integrity verification, and approval. The goal is to make those steps efficient enough that they don't slow down the response. A lengthy approval process creates risk, but so does bypassing security checks under pressure.

Teams that respond effectively are usually prepared in advance. They have an accurate software inventory, a software bill of materials (SBOM) for each deployable build, and an established fast-track process with named approvers and clear criteria for emergency changes. When PHP is defined in a shared base image, rebuilding and redeploying services from that updated image can address the vulnerability across multiple applications, rather than patching individual running containers.

This emphasis on preparation reflects lessons DigiCert learned through its Customer Zero initiative to modernize certificate management across our own infrastructure. The team discovered that incomplete inventories, duplicate records, and unclear ownership made automation harder to scale. Although certificate management and vulnerability response involve different technologies, the lesson applies to both: Accurate visibility and clear ownership are essential to responding quickly and reliably.

On October 21, the PHP development team released patched versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and older no longer receive security updates from the project, although some vendors provide backported fixes. The PHP security team also provided minimal source backports for versions 7.4, 8.0, and 8.1. If you're running an older version, check with your vendor about available fixes or plan an upgrade to a supported release. Don't assume that software is secure simply because it's still working.

Prepare for the next critical vulnerability

PHP2Shell was a test of operational readiness as much as a test of PHP security. Teams that could quickly identify where PHP was running, which versions were affected, and who owned those systems were better positioned to respond. For teams without that visibility, discovering the extent of their exposure became another urgent task.

The next critical vulnerability may affect a different technology, but the underlying challenge will be familiar. Accurate inventories, clear ownership, tested emergency procedures, and security checks built into release workflows help teams respond without sacrificing control.

DigiCert recently introduced Secure Releases in DigiCert Software Trust Manager to help organizations better understand and manage software risk. By connecting information about software releases, SBOMs, known vulnerabilities, and security findings, Secure Releases helps teams identify affected versions and make informed decisions throughout the release lifecycle.

When the next critical vulnerability emerges, knowing what's in your software, which releases are affected, and who needs to act can make all the difference.