PHP2Shell is the name given to two critical vulnerabilities in the PHP language itself — CVE-2026-109618 and CVE-2026-109619. In late October 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) confirmed that attackers are actively exploiting them and ordered federal civilian agencies to fix affected systems within three days.

If your website or application runs on PHP, this is not a theoretical issue. It is a patch-now event.

What is PHP2Shell?

PHP2Shell is not a WordPress plugin bug or a single CMS flaw. It is a pair of memory-safety issues inside the PHP runtime — the engine that executes PHP code for a large share of the web.

According to public reporting and vendor advisories:

• CVE-2026-109618 — Remote code execution via out-of-memory (OOM) corruption. When PHP aborts a request after a memory limit failure at the wrong moment, request memory can be left in an invalid state that later enables code execution.
• CVE-2026-109619 — Remote code execution via stale global state. A PHP worker can retain internal state from one request that is reused unsafely on a later request, creating a use-after-free condition.

Both issues are rated critical (around CVSS 9.2 on CVSS v4.0). Importantly, exploitation does not require a valid login. An unauthenticated attacker who can reach a vulnerable PHP web service may be able to run code on the server.

PHP is estimated to power a large majority of sites where the server-side language is known. That scale is why this disclosure caused emergency maintenance windows across hosting providers, governments, and large organizations.

Why this became an emergency

Parts of these weaknesses had been known or discussed in research circles earlier, but they were widely treated as difficult or impractical to exploit. That changed in 2026 when researchers — including work associated with security firm Calif and others, with AI assistance reported in coverage — demonstrated practical exploitation paths.

Key timeline points reported publicly:

• October 21, 2026 — PHP released emergency fixed versions.
• Shortly after disclosure — Exploitation attempts and research honeypot evidence increased.
• October 26, 2026 — CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog and set a short remediation deadline for federal civilian agencies.

TechCrunch and other outlets reported that CISA’s warning confirmed active exploitation and raised urgency for organizations still running unpatched PHP.

Who is affected?

Any service that uses PHP to handle web requests can be in scope, including:

• Apache with mod_php (often called out as especially high risk)
• PHP-FPM
• php-cgi
• Other PHP SAPIs used to serve websites and APIs

That includes WordPress sites, Laravel apps, Drupal, custom PHP applications, and many hosted control panels or appliances that embed PHP.

Being on “the latest WordPress” is not enough if the underlying PHP engine is still vulnerable.

Fixed PHP versions

The PHP project shipped fixes in these releases:

PHP branch	Fixed release
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Older branches (including PHP 8.1 and earlier) are end-of-life. Some vendors and the PHP project discussed or issued limited source backports for older lines, but the reliable path is to move onto a supported, patched 8.2+ release.

What you need to do right now

1. Check your PHP version

On the server:

php -v

Or check your host’s control panel / site health tools. If you are below the fixed releases listed above, assume you need action.

2. Patch PHP

• Upgrade to a fixed version: 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (or newer security releases in those branches).
• Restart all PHP workers / PHP-FPM pools / Apache after the upgrade so old processes are not still serving traffic.
• If you use a managed host (cPanel, Cloudways, WP Engine, SiteGround, etc.), confirm they have deployed the patched runtime to your account.

3. Do not stop at the CMS layer

Update WordPress, plugins, and themes as usual — but understand that PHP2Shell is fixed in the PHP engine, not by a WordPress plugin update alone.

4. If you cannot patch immediately

• Reduce exposure: restrict admin interfaces, put vulnerable apps behind VPN or IP allow-lists where possible.
• Ask your host whether emergency mitigations or WAF rules are in place.
• Prioritize internet-facing production systems first.
• Plan an urgent upgrade path off end-of-life PHP.

Temporary mitigations are not a substitute for the official patch.

5. Check for compromise

Because CISA listed these as known exploited vulnerabilities, treat patching as necessary but not always sufficient. After upgrading:

• Review access logs around late October 2026 for unusual requests.
• Look for unexpected admin users, scheduled tasks/cron jobs, or modified core files.
• Scan for webshells and unknown PHP files in uploads and cache directories.
• Rotate credentials if you see signs of intrusion (CMS admin, hosting, database, SFTP/SSH, API keys).

Practical guidance for WordPress and small business sites

1. Confirm the PHP version your site actually runs in production.
2. Upgrade to a patched PHP 8.2+ release through your host.
3. Restart services / confirm the new version is live.
4. Remove abandoned plugins and keep the rest updated.
5. Keep backups offline or off the web root.
6. Monitor the site for unfamiliar admin activity after patching.

If your host still forces an old PHP branch, contact support and escalate. Running unpatched PHP on a public website is an active risk while exploitation is confirmed.

Why this matters beyond one patch cycle

PHP2Shell is also a reminder of deeper industry issues:

• Critical internet infrastructure still depends on under-funded open-source projects.
• Bugs once dismissed as “hard to exploit” can become practical when research methods improve — including AI-assisted analysis.
• Organizations that delay runtime upgrades accumulate silent risk until a CISA-level event forces emergency work.

The operational lesson is straightforward: keep PHP on a supported branch, apply security releases quickly, and treat the language runtime as part of your security perimeter — not just an invisible server setting.

Bottom line

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) allows unauthenticated remote code execution against vulnerable PHP web servers. CISA has confirmed exploitation. The fix is to upgrade to a patched PHP release — 8.5.12, 8.4.27, 8.3.36, or 8.2.35 — restart PHP workers, and verify your systems were not already compromised.

If you maintain client sites, check every host and every environment. The sites that get burned are usually the ones still sitting one version behind.

---

Sources for public reporting and advisories include CISA KEV updates, PHP security releases, and coverage from outlets such as TechCrunch on active exploitation of these critical PHP bugs.