PHP2Shell: The PHP Flaw That Could Hand Over Your Website

Written by Mark McDougal

Most of the attacks we write about start with a person: someone opens a phishing email, gives up a password or pays a fake invoice. This one needs only a single web request sent to a website that hasn't been updated.

This week the PHP project fixed two critical flaws, now known as "PHP2Shell," that can let an attacker run their own commands on a web server without logging in. CISA, CERT-EU and national cyber agencies in the UK, Canada, Australia and New Zealand have all put out alerts urging organizations to patch immediately.

If your organization has a website, a parent portal, an online store, or a WordPress site, give this five minutes.

First, What Is PHP?

PHP is the programming language running behind the scenes on a huge share of the internet. It builds the page when someone visits your site, submits a form, or logs into a portal.

How common is it? W3Techs, which tracks web technologies, reports that PHP is used by 69.3% of websites whose server-side language it can identify. WordPress, which runs a great many school, church, city and small-business websites, is built on PHP.

PHP also hides inside other products. CISA points out that "PHP is often a component of other software and prevalence may not be directly observable." Think management portals and vendor web apps. For example, ConnectWise said it temporarily took its Axcient Backup for Files legacy portal offline while remediating the PHP vulnerabilities. ConnectWise says backups kept running and the portal was restored on October 22.

What Happened

  • October 20: The PHP project announced an upcoming security release for two critical vulnerabilities (per CERT-EU).

  • October 21: PHP released fixes in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619. CERT-EU lists both with a CVSS score of 9.2 out of 10.

  • October 23: CISA updated its alert with a detection rule and partner guidance. Separately, PHP disclosed a third, lower-risk issue (CVE-2026-115560) that only affects an unusual setup. PHP is fixing it in its next regular release and recommends a configuration change in the meantime.

PHP's own advisory doesn't mince words: "There are no complete mitigations, updating is the only safe choice."

How the Attack Works

  • The attacker finds a PHP website. Researchers at Datadog report “broad untargeted scanning.”

  • They send one specially crafted request, such as a large form submission or file upload. They don't need a username or password.

  • PHP stumbles while processing it. One flaw involves what happens when PHP runs out of memory partway through handling a request. The other involves leftover data from one request being reused by the next one.

  • The mess becomes an opening. In both cases, PHP can end up working with memory the attacker shaped. That can let the attacker run their own commands on the server.

  • It happens before your website’s code even runs. Datadog reproduced the attack and confirmed that "application-level authentication can't block an attack: PHP processes the malicious request before any application code runs." That means your login page, plugins and passwords can't stop it.

From there, an attacker can plant a backdoor, steal data, deface the site, or move on to other systems.

PHP says every installation that serves web requests is at risk, including Apache with mod_php (which it considers the highest risk), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed.

Is Anyone Exploiting It Yet?

The sources are still catching up, so here's who said what:

  • Amazon Threat Intelligence says it saw a PHP2Shell exploit attempt against its honeypots on October 17, four days before the patch was public. It says it saw more attempts from multiple actors after release, and that PHP2Shell "is now seeing broad exploitation attempts in the wild." Amazon also says it's unclear whether those attempts would have succeeded on real systems.

  • Datadog Security Labs says that, as of October 21, it had “multiple reports of active exploitation in the wild.”

  • CISA says it had not observed successful exploitation as of its alert. As of the October 23 KEV catalog, these CVEs are not listed in CISA's Known Exploited Vulnerabilities catalog.

Working exploit code is out there and attackers are trying it. Amazon recommends starting any investigation from October 17, the day of its first sighting.

Who in Arkansas Should Pay Attention

  • Small and mid-sized businesses with a WordPress site, an online store, a customer portal or a booking form.

  • K-12 districts running district and school websites, parent portals or ticketing and fundraising sites.

  • Colleges and universities, with dozens of department sites and older apps.

  • Anyone using a hosting company or web developer. You may not manage PHP yourself, but someone does, and you need to know they patched.

How to Check and Fix It

1. Find out what you have. CISA's first recommendation is to inventory everything running PHP. Don't forget vendor portals and appliances.

2. Patch. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Prioritize internet-facing systems.

3. Deal with old PHP. PHP 8.1 and older no longer get updates from the PHP project. Some Linux vendors and long-term support providers offer backported fixes. CISA says systems that can't be updated "should take PHP-based systems offline until they can be patched or updated." W3Techs reports that roughly a third of PHP sites it tracks still run PHP 7 or older, so this isn't a small group.

4. Ask your hosting provider or web developer, in writing:

  • What PHP version is our site running today?

  • Was it updated to a fixed version, and on what date?

  • Are any of our other sites, staging sites or portals still on PHP 8.1 or older?

  • Did you review our logs back to October 17 for signs of exploitation?

5. Use a web application firewall (WAF) as a stopgap. CISA says a WAF "may provide some protection" until you patch. Datadog notes that controls at a reverse proxy in front of PHP can block malicious requests before they reach PHP.

6. Look for signs of compromise. CISA, Amazon and Datadog all point to similar warning signs:

  • Unusually large form submissions or uploads.

  • Memory-exhaustion errors and PHP worker crashes.

  • PHP processes launching command shells or downloading tools.

  • Unexpected new or modified files on the web server.

Patching won't remove an attacker who got in before you updated, so check for these signs even if you're already patched.

Would Your Organization Catch It?

  • Do you know every website and portal you own, and what PHP version each one runs?

  • If your web host patched, would they tell you, or would you have to ask?

  • If your web server started a command shell at 2 a.m., who would see the alert?

  • Would anyone notice if a new file showed up on your website?

If those are hard to answer, you're not alone.

How Red Garrison Can Help

At Red Garrison, we think like attackers, and attackers love an unpatched website that nobody is watching.

  • Web application penetration testing. We test your websites and portals the way an attacker would, including outdated components like PHP and vulnerable plugins.

  • External penetration testing. We map what you have facing the internet, including the forgotten sites and portals, and show you what an attacker could reach.

  • Managed MDR powered by Huntress. 24/7 human-led detection and response, so a shell launched from your web server gets caught and contained quickly.

  • Incident Assist. If you think your site was hit, we'll help you investigate, clean up and recover, with pricing defined up front.

  • Free OSINT snapshot. See what attackers can already learn about your organization from the outside.

Let's Make Sure Your Website Isn't the Easy Way In

Schedule a free assessment with Red Garrison this week. We'll help you list your public websites and portals, confirm which ones run PHP, check whether they're patched against PHP2Shell, and tell you honestly what we'd fix first. If you think something already looks wrong, don't wait. Start with Incident Assist, or call us at (501) 404-5966.

We think like attackers. We work like partners.

Sources

Mark McDougal
Next

Your Firewall Needs More Than a One-Time Setup