PHP2Shell: what to do if your site runs PHP

On 21 October 2026 PHP fixed two critical issues — CVE-2026-109618 and CVE-2026-109619. Researchers and press call the pair PHP2Shell (php2shell).

In short: crafted HTTP requests can let an unauthenticated attacker run code on the server or read process memory (passwords, tokens). The bug is in PHP itself, not a “bad plugin”.

Any PHP that serves web requests is in scope: PHP-FPM, Apache mod_php (PHP rates this highest risk), php-cgi, FrankenPHP, LiteSpeed. Even a Hello World on a vulnerable build is unsafe.

Public exploits exist. Honeypots and researchers saw exploitation attempts; CISA urges immediate patching. That is not the same as “you are already breached” — but waiting is not a plan.

Almost any internet-facing PHP site: storefronts, landings, shops, admin panels, Laravel/Symfony APIs, Bitrix, WordPress, Joomla, Drupal, custom apps.

PHP from 5.4 through current branches before the patch is at risk. PHP 8.1 and older get no fix from the PHP project: you need a vendor/host backport or an upgrade to a supported branch.

Extra risk: staging, “temporary” hosts and shop copies on subdomains — often left unpatched.

See also: Bitrix on the perimeter, new subdomains.

Official fixes (move at least to this build in your branch):

• PHP 8.5.x → 8.5.12 or newer
• PHP 8.4.x → 8.4.27 or newer
• PHP 8.3.x → 8.3.36 or newer
• PHP 8.2.x → 8.2.35 or newer
• PHP 8.1 and older → vendor/host backport or move to a supported branch; otherwise CISA advises taking internet-facing PHP offline until patched

A WAF may blunt some known patterns. It does not replace updating the runtime. Updating WordPress/Bitrix plugins alone does not close PHP2Shell.

1. Learn the PHP version in production (hosting panel, internal phpinfo, or the external banner if the version is visible).

2. If below a safe build — upgrade PHP in the panel / with the host / via the container image. Align with your Bitrix vendor: a minor bump is usually safer than a major jump.

3. Check copies: `dev.`, `stage.`, `test.`, old agency subdomains. Patch or take them off the internet.

4. After patching, restart php-fpm / workers and confirm production really runs the new build.

5. Review logs for odd POSTs, error spikes and unknown files in the document root.

External view without server access: Radar check and Bitrix on the perimeter.

The CMS is not the root cause: PHP underneath is. Updating WordPress core/plugins ≠ patching PHP2Shell.

On shared hosting: panel → PHP version → pick a safe build from the list above. If you cannot — ticket the host with CVE-2026-109618 / CVE-2026-109619 and ask them to update the runtime.

On managed WordPress plans ask support: “which PHP version do I run, and is it patched for php2shell?”

Several sites in one account — check each; vhosts often use different PHP branches.

Until the patch lands, some providers enable WAF rules. That is a cushion, not the fix.

Update distro packages or the base image to a safe PHP build, rebuild and redeploy containers (an old image layer may still ship old PHP).

Cover every environment: prod, staging, preview, CI runners that expose PHP publicly.

Apache mod_php is priority one per PHP’s own risk note; PHP-FPM must be updated too.

Interim steps (not a full fix): limit multipart uploads if the app allows, tighten WAF, lock down admin paths. Full closure is only an updated runtime.

After upgrade: `php -v` on the host and confirm the web pool uses the same binary.

This is where PHP is most often forgotten: agency staging, an old storefront on `old.`, a Bitrix demo, phpMyAdmin on a side host.

Take unused hosts offline; patch the rest like production.

Inventory and new-host alerts: new subdomains and shadow IT.

The question is not “does the CVE exist” but “do we run PHP on the perimeter, and is a vulnerable version visible”.

• Add the root domain in signalfort and verify ownership (DNS TXT)
• Wait for host discovery and stack matching
• If PHP/version are visible and matched, you get a finding (first as a match)
• “Confirmed” only after a safe check on a paid plan — not the same as “we were breached”

More on statuses: how to tell if a CVE affects you. Start: free check.

Do not paste public PoCs onto production “to test” — that creates risk yourself.

• Do not assume “we updated Bitrix/WordPress, so PHP is fine”
• Do not leave PHP 8.1+ older builds internet-facing without a vendor answer
• Do not run public exploits against production
• Do not forget containers and stands next to the main domain

Confirm the new version from the panel and from outside. Restart workers.

Review web and PHP logs for anomalies around disclosure dates (attempts showed up in telemetry from about 17–21 October 2026).

Look for unexpected files in the site root, new admin users, odd cron jobs.

If you suspect compromise — isolate the host and follow your IR process. signalfort helps with exposure and matches; it does not replace on-server incident response.