PHP2Shell: Remote Code Execution in PHP and the Credentials Behind It

PHP2Shell is the name widely used for two critical flaws in the PHP interpreter itself, CVE-2026-109618 and CVE-2026-109619, which can let an unauthenticated request achieve remote code execution on a web server before any application code runs. Because the bugs sit in the runtime rather than in a framework, CMS or plugin, well-written applications are exposed along with badly written ones. The PHP project shipped emergency releases on 21 October 2026 and CISA added both CVEs to its Known Exploited Vulnerabilities catalogue on 26 October 2026. This guide covers the timeline, what is affected, how to check and patch each kind of environment, and, in the most depth, the credentials a PHP worker can read and what an attacker reaches with each one. It is written for web platform owners, hosting providers, agencies running many sites, and SOC and incident response teams. Facts were checked against the PHP project's advisories and the CISA KEV data on 28 October 2026. This is a live issue with follow-up advisories already published, so check the sources for changes before acting on any detail here.

Key takeaways

• Patch the runtime, then restart every worker. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or a distribution backport. The PHP project says none of its interim mitigations makes an installation safe, and long-running workers keep the old code in memory until restarted.
• mod_php is the highest-risk deployment, but nothing that serves PHP is exempt. The PHP project rates Apache mod_php highest because an unauthenticated request can trigger the attack before application code runs, and states that PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are affected too.
• Patching does not undo a compromise. Amazon, as reported by BleepingComputer, saw exploitation attempts from 17 October, four days before the patches, and CISA's KEV entry flags forensic triage. Investigate exposed hosts, do not just update them.
• The real prize is the secrets behind PHP. Code execution as the web worker exposes database credentials and salts in wp-config.php, .env files, plugin API keys, SMTP keys, backup and remote management keys, SSH keys and hosting panel tokens. Each is a non-human identity that outlives the patch unless it is rotated.
• Rotate in order and prove it worked. Remove persistence first, then rotate the credentials that grant the widest access, then confirm at each provider that the old credential fails and that nothing new was created while it was valid.

The story: disclosure to exploitation to KEV

The sequence matters because it sets the window you need to investigate. Dates below come from php.net, the php-src GitHub advisories and the CISA KEV data unless marked as reported by a news outlet.

Two practical consequences follow. First, any internet-facing PHP host that was unpatched from 17 October should be investigated, not only patched. Second, the follow-up advisories mean "patched on 21 October" is not the end state: Windows estates need the -1 rebuilds, and the CVE-2026-115560 fix will arrive in a later release. The CISA KEV Catalogue Guide explains how KEV due dates and forensic triage flags should drive priority outside the US federal sector.

How PHP2Shell works, at a defender's level

This section gives what you need to judge exposure. It deliberately leaves out exploitation mechanics.

Four points from the advisories matter for risk decisions:

• Impact is code execution as the web worker account. On a typical Linux host that is www-data, apache or nginx, or the per-site user on shared hosting. It is not root, but it is everything the worker can read, which is the point of the identity section below.
• Reliability varies. The PHP project says success depends on the build, loaded extensions, front-end behaviour and memory layout. Multiple workers raise the number of attempts an attacker needs but do not remove the condition, so a large FPM pool is not a mitigation.
• The request does not need to reach your code. On mod_php the attack can fire during request parsing, so application firewalls inside the code, authentication middleware and CMS security plugins do not see it.
• Configuration location matters. The stale-state mitigation only works where it applies before request parsing: php.ini, an FPM pool or server configuration. ini_set() and .user.ini come too late.

A short history of PHP mass exploitation

PHP2Shell is not the first time the runtime, rather than an application, has been the target. The pattern repeats: a flaw in how PHP is invoked or parses requests, a large exposed population, and fast weaponisation.

The lessons carry straight into PHP2Shell. CVE-2024-4577 showed that an old fix can be bypassed on a platform nobody tested, which is why the Windows estate deserves its own checks below. The 2021 Git server case is the identity version of the same story: the weakness was a forgotten password-based write path to build-critical code, not a code bug. Long-lived, password-style credentials on PHP infrastructure keep turning up in incident reports.

Am I exposed? Step-by-step checks by environment

Work through these in order. Record for each host the PHP version, the build source (upstream, distribution, vendor), the SAPI, whether session.upload_progress.enabled is on, and whether the host faces the internet. That record is your triage list.

1. Build the inventory. Query configuration management, package managers (dpkg -l 'php*', rpm -qa 'php*'), container image SBOMs and registry scanners for PHP. Include admin tools, monitoring dashboards, appliances and staging sites, which are often forgotten. See the SBOM operations guide.
2. Self-managed Linux servers. Run php -v for the CLI, but check the web SAPI separately, because the CLI and web server can use different builds. For Apache, apachectl -M shows whether php_module (mod_php) is loaded. For FPM, check the running master version (php-fpm -v for the binary in use) and the pool definitions. Then read the distribution security tracker for the package: enterprise and LTS distributions backport fixes onto older version numbers, so the upstream version string alone misleads in both directions.
3. Effective configuration. Confirm the values the web SAPI actually uses, not just php.ini: check FPM pool files, Apache php_admin_value lines and any per-directory overrides. A temporary, access-restricted phpinfo() page on a non-production host, removed afterwards, shows the effective values for that SAPI.
4. Shared hosting. You usually cannot see the binary. Check the control panel's PHP version selector and ask the provider in writing whether its builds include the 21 October fixes and whether workers were restarted. Ask whether upload progress is disabled at the server level.
5. Managed WordPress and PaaS. Check the provider's status page or security bulletin for PHP2Shell. The runtime is the provider's responsibility; your logs, your secrets and your plugins are still yours.
6. Containers. Scan every image in every registry, not only running ones, because an old tag can be redeployed by an autoscaler or rollback. Look at the PHP version inside the image and at the base image date. Images that bundle php-fpm and a web server count as one exposure.
7. Windows. Identify PHP installs under IIS (usually FastCGI), Apache on Windows and developer stacks such as XAMPP. Check both the PHP version and whether the build is the -1 rebuild with Brotli 1.2.1. Search for any internet-reachable php-cgi.exe, which is the CVE-2024-4577 lesson.
8. Embedded and vendor products. Appliances, NAS devices and commercial web applications often ship their own PHP. The KEV notes say the flaw is in an open-source component used by different products, so track each vendor's advisory separately.
9. External view. Map internet-facing hosts that serve PHP, including marketing microsites, agency-hosted sites and old campaign domains. Rank by internet exposure, then by SAPI (mod_php first), then by the value of the secrets the host holds.

Patching and interim mitigations by environment

Patching is the fix. The interim measures below come from the PHP advisories and php.net, which state that none makes an installation safe. Use them where a patch will take more than a day, and keep the upload progress setting afterwards if you do not use the feature.

By environment

• Self-managed Linux: apply the distribution security update or the upstream release, then restart Apache or every FPM master, not a graceful reload alone where your service manager keeps the old master. Confirm afterwards that the running process maps the new binary (for example, compare the process start time with the package install time). Patch in rings: one canary host, a small production group, then the rest. Keep the previous package for rollback but prefer rolling forward with configuration mitigations over rolling back to a vulnerable build. The Emergency Out-of-Band Patching Playbook covers change approval at this speed.
• Shared hosting customers: select a fixed PHP version in the panel if offered, set the upload progress value only where the host allows server-level overrides, and get written confirmation of patch and restart dates. Those dates bound your investigation window.
• Hosting providers running shared platforms: patch per-version PHP builds (many platforms run several versions side by side, each a separate binary to patch), disable upload progress globally while you patch, restart per-user pools, and publish a bulletin with the times. One shared runtime across thousands of accounts means one unpatched build is thousands of exposures.
• Managed WordPress: the provider patches the runtime. You should still update plugins, check for unknown administrator accounts and plugins, and review application passwords, because a site compromised before the provider patched stays compromised.
• Containers: rebuild from a patched base image, redeploy, and retire vulnerable tags so they cannot be pulled again. Do not patch running containers in place. Ephemeral containers reduce persistence risk but not credential theft: a secret read from an environment variable is just as stolen. See the Container Image Security Guide.
• Windows builds: install the -1 builds from the php.net Windows download page, which include Brotli 1.2.1; a server already on 8.x.y from 21 October still needs the rebuild if any code enables cURL automatic decompression. Restart the IIS application pool or Apache service, and remove any php-cgi.exe reachable from the internet. See the IIS Hardening Guide.
• End-of-life PHP (8.1 and older): apply the project's minimal source backports or a commercial LTS build as a stop-gap, place the host behind strict front-end limits, and schedule the upgrade. PHP 8.2 joins this group on 31 December 2026.

WAF and edge rules for oversized or malformed multipart requests can cut noise and buy time. They are a supplement, not a fix, because the vulnerable code runs in the runtime and rule bypasses are routine. General runtime hardening, supported-version planning and WordPress core hardening are covered in the PHP and WordPress Security Guide, so this page does not repeat them.

What sits behind PHP on hosting: the identity and secrets overlay

A web shell on a PHP host is rarely the attacker's goal. It is the way in to the credentials the PHP worker must read to do its job. Every one of them is a non-human identity with its own blast radius, and most are long-lived, unowned and shared across environments. This is where PHP2Shell turns from a patching job into a breach. ATT&CK calls the core move T1552.001 Credentials In Files.

Making the worker read less

• Move wp-config.php out of reach. WordPress's hardening documentation allows wp-config.php to sit one directory above the installation, which puts it outside the web root for a site at the webspace root, recommends permissions of 400 or 440 so only the owner and web server can read it, and gives an Apache <Files "wp-config.php"> deny block. It also notes the debate about how much moving the file helps. Neither step stops code running as the worker from reading it, which is why vaulting matters.
• Separate the worker from the secret store. A PHP worker that can read its own config can be made to leak it. Fetch secrets at start-up from a manager using a workload identity, keep them in process memory, and give each site its own identity so one compromise reveals one site's secrets. See the Secrets Management Guide.
• Per-site users on multi-site hosts. Run each site's FPM pool as its own Unix user with open_basedir limited to that site's tree. One shared www-data account across 50 sites means one PHP2Shell foothold reads 50 sets of credentials.
• Scope at the provider, not just on the host. A sending-only email key, a restricted payment key or a read-only database user still leaks, but it is worth much less when it does.

Assume compromise: web shells, persistence and credential rotation

Use the Web Shell Response Playbook for the full workflow: roles, containment, eradication and communications. The points below are specific to PHP2Shell and to getting credential rotation right.

Preserve and hunt

• Preserve first: snapshot affected VMs or containers before patching where possible, and collect web server access and error logs, PHP and FPM logs, and auth logs from at least 17 October 2026.
• Web shells (T1505.003): new or modified PHP files in web roots, upload and cache directories, and files whose content does not match the deployment artefact or the WordPress.org checksums. Unknown plugins with plausible maintenance names are a known WordPress pattern, as the UpdraftCentral Key Theft 2026 campaign showed.
• Other persistence: cron entries for the web user (T1053.003), auto_prepend_file or .htaccess changes, new authorized_keys lines (T1098.004), new WordPress administrators, new application passwords and new provider-side API keys created by a stolen key.
• Process behaviour: the worker account spawning shells (T1059.004), download tools pulling binaries (T1105) or sustained CPU from unknown processes (T1496 Resource Hijacking).

Rotation order

1. Remove persistence and close the entry point first. Patch, restart, remove web shells, or better, rebuild from a known-good image. Rotating while a shell is live just hands the attacker the new values.
2. Hosting panel, provider API and cloud credentials. These reach every other site and system, so they go first.
3. SSH and SFTP keys and deployment credentials. Remove unknown authorized_keys entries, reissue deploy keys and CI variables.
4. Database credentials. Create a new account or password, update the config, restart workers, then drop or disable the old one.
5. Third-party API keys. Payment, email, CRM, AI provider, backup and remote management keys: revoke at the provider and issue new restricted keys, not just edit the config value.
6. WordPress keys and salts, application passwords and admin passwords. Regenerate salts (signs everyone out), revoke all application passwords and reissue the ones still needed, force administrator password resets with MFA.
7. TLS keys where the worker could read them: reissue the certificate with a new key and revoke the old one.

Proving rotation worked

• The old credential fails. Test it from an isolated host: the old database password is refused, the old API key returns an authentication error, the old SSH key is denied.
• Nothing new was minted. At each provider, list keys, users, OAuth grants and webhooks, and remove any created during the exposure window. An attacker with a payment or cloud key often creates a second one.
• No use after rotation. Watch provider audit logs, database logs and cloud trails for the old credential's ID and for logins from new addresses.
• The new value is not on the old host. If you rebuilt, confirm no backup, snapshot or log captured the new secret on a compromised system.

Partial rotation is a common reason incidents recur. The Incomplete rotation breaches guide and the Leaked Credential Response Playbook go further.

Detection

The PHP advisory recommends log_errors, a working error_log and error_reporting=E_ALL when investigating in an isolated environment, and warns that clean logs do not prove a host is safe. See the Linux Detection and Response Guide for process telemetry.

Metrics that show the response is working:

• Percentage of internet-facing PHP hosts on fixed builds with workers restarted (target 100 percent inside your emergency SLA).
• Percentage of hosts with upload progress disabled where the feature is unused.
• Percentage of exposed hosts with forensic triage completed for the 17 October onward window.
• Number of secrets rotated and verified as failing, against the number readable by workers on suspected hosts.
• Registry images still carrying vulnerable PHP.
• Count of static secrets in PHP config files across the estate, tracked down over the following quarter.

Hosting providers, agencies and multi-site estates

Scale changes the problem. A single company website is one patch and one rotation list. A host or agency is thousands of runtimes and tens of thousands of credentials, many of them held centrally.

• Do not let a provider keep readable copies of credentials. In the GoDaddy Managed WordPress Breach 2021, one compromised password reached the provisioning system and exposed original WordPress admin passwords, SFTP and database credentials and, for a subset of customers, SSL private keys, for up to 1.2 million customers. A PHP2Shell foothold on a host's own panel or tooling would be the same event by a different route.
• Treat remote management keys as admin credentials. In the UpdraftCentral case, stolen vendor-held connection keys signed commands that installed backdoor plugins on fully patched sites. Agencies that connect every client site to one dashboard should know which keys exist, which user each runs as, and delete those not in use. See the NHI Offboarding and Decommissioning Guide.
• One identity per site. Separate Unix users, database accounts, email keys and SSH keys per site turn an estate-wide incident into a single-site one.
• Agree who patches. Many agency incidents trace to hosting nobody owned. Put runtime patching, restarts and incident contact in each client agreement. See the Cybersecurity for MSPs and MSSPs Guide.

The breach evidence

None of these incidents was caused by PHP2Shell. Each shows what happens to the credentials behind PHP once someone can read them, which is exactly the follow-on risk here.

Beyond this incident: retire the credentials worth stealing

Rotation closes the PHP2Shell window, but it does not change the odds next time. The PHP runtime has been the target in 2012, 2024 and now 2026, and every time the attacker's real prize was the same: database passwords, API keys and tokens sitting in files the web worker can read, valid for months or years. Rotate them today and the new values go straight back into the same files, ready for the next runtime bug. That is a treadmill, not a fix.

The strategic answer is to make stolen credentials worth very little. A secret that expires in minutes, is bound to one workload and is issued only when needed gives an attacker a short window and nothing to sell. It also turns the next incident from "find and rotate everything" into "revoke one identity and wait for the leases to run out".

Most PHP estates cannot jump there in one step. A realistic path, in order:

1. Get secrets out of files. Move database, SMTP, payment and AI provider keys out of wp-config.php, .env and wp_options into a secrets manager, fetched at start-up into process memory. This alone stops a simple file read from collecting everything. See the Secrets Management Guide.
2. Give each site its own identity. One workload identity per site to fetch its own secrets, one database account per site, no shared SMTP or storage keys. A compromise then reveals one site, not the estate. See the Cloud Workload Identity Guide.
3. Replace static cloud and CI keys with federation. Instance roles and OIDC federation instead of access keys on web servers or in deployment pipelines. See the Workload Identity Federation Guide.
4. Move to short-lived and dynamic credentials where the platform supports them. Database credentials issued per worker with a lease, and SSH certificates that expire in hours instead of keys that never do. See the Dynamic Secrets and Ephemeral Credentials Guide and the SSH Certificate Authority Guide.
5. Automate what stays static. Some third-party plugins and SaaS APIs will only take a long-lived key for years yet. Give each one an owner, a scope as narrow as the provider allows and a scheduled, tested rotation. See the Secrets Rotation Runbook Template.

Measure progress with one number: the count of long-lived secrets readable by web workers across the estate. The detection metrics above already ask you to track it down over the next quarter. When it is close to zero, the next PHP2Shell is still a patching job, but it is no longer a breach.

Framework mapping

Practitioner checklist

First 24 hours

• Inventory every PHP runtime, its SAPI, build source and internet exposure; rank mod_php and shared hosting first.
• Patch to 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor backport; on Windows use the -1 builds.
• Restart every worker and verify the running build, not just the installed package.
• Where patching slips, set session.upload_progress.enabled=0 at server level, fatal_error_backtraces=0 on 8.5, and edge request limits.
• Preserve logs and snapshots from 17 October 2026 for exposed hosts.
• Hunt for web shells, unknown plugins and admins, new cron jobs, new authorized_keys and worker child processes.
• On any suspected host, rotate in order: panel and cloud tokens, SSH and deploy keys, database, third-party keys, salts and application passwords.

First 30 days

• Prove each rotation: old credentials fail, no new keys were minted, no use after rotation.
• Move secrets out of web roots and plaintext config into a secrets manager with per-site identities.
• Split shared worker, database and email identities so one site cannot read another's secrets.
• Delete unused application passwords, remote management keys and backup connections; set owners and expiry for the rest.
• Retire vulnerable container tags and add PHP version gates to image builds.
• Plan PHP 8.2 upgrades before 31 December 2026, and watch for the CVE-2026-115560 release.
• Write runtime patching and incident contacts into hosting and agency agreements.

Standards and references

• PHP: GHSA-w8hw-w9fx-j79w RCE via OOM corruption (CVE-2026-109618)
• PHP: GHSA-6wmf-4rv5-p3rp RCE via stale global state (CVE-2026-109619)
• PHP: News, security releases and advisories (21, 23 and 26 October 2026)
• CISA: Known Exploited Vulnerabilities Catalog
• PHP: GHSA-3qgc-jrrr-25jv Argument injection in PHP-CGI (CVE-2024-4577)
• NIST NVD: CVE-2012-1823
• WordPress: Hardening WordPress
• WordPress: Application Passwords Integration Guide
• BleepingComputer: Amazon says PHP2Shell exploitation began 4 days before patches

Related NHI Mgmt Group resources: Web Shell Response Playbook · PHP and WordPress Security Guide · Secrets Management Guide · Leaked Credential Response Playbook · Emergency Out-of-Band Patching Playbook