NewsCompaniesFlawsGuides
Get the app

Two critical PHP flaws now have a fix. Some firms report early attacks

From the HARD Situation Room · First reported · Updated
For everything else happening in security now, see the Situation Room.

PHP, the language behind about 7 in 10 websites, released fixes on 21 October. Some security firms report early attacks; others, and the US agency CISA, haven't seen any. PHP 8.1 and older get no official fix.

Two critical flaws in PHP, the language behind most of the web, leaked before they could be fixed. Most families won't have to patch anything. The people they trust with their data will.

Current event. Latest update, : CISA, the US cybersecurity agency, added both php2shell flaws to its list of vulnerabilities being used in attacks on 26 October. In the timeline

What happened

On Tuesday, a post appeared on Hacker News naming two security flaws in PHP that weren't meant to be public yet. It was deleted within hours, but screenshots spread. Within hours, watchTowr, a security research firm, said it had reproduced one of them, and PHP's own security team published an emergency notice: two critical vulnerabilities, a fix coming on Wednesday, and a request that everyone running PHP get ready to upgrade.[1]

BleepingComputer headline: PHP warns admins of two critical flaws, emergency patches coming tomorrow
Tuesday's headline.BleepingComputer's report of PHP's emergency notice, 20 October.Screenshot: bleepingcomputer.com

Researchers have nicknamed the pair php2shell. The name says what's feared: send the right request to a website, and you get a shell on the server behind it, which means control of the machine and everything on it. PHP released the fix on 21 October, with an outline of both flaws: one in how PHP recovers when a request runs out of memory, the other in data one request leaves behind for the next. Neither needs a login. On the setup PHP rates most at risk, a single request can trigger the attack before the website's own code has even started.

PHP.net's security advisory: critical remote code execution vulnerabilities, update now, listing PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35
PHP's own advisory.The fixed versions and what's at risk, from PHP.net on 21 October.Screenshot: php.net

Timeline

  1. A post on Hacker News names two PHP flaws that weren’t meant to be public yet, and is deleted within hours. watchTowr says it has reproduced one; PHP publishes an emergency notice.[1]

  2. PHP releases the fix: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA says to take systems that can’t be patched offline.[2][3]

  3. HARD publishes its article, at Critical.

    What it said to do thenAsk anyone who runs a website for you whether it now runs PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or their vendor's fixed version. If it's on PHP 8.1 or older, ask for a plan to upgrade or take it offline. Ignore emails urging you to log in for a security update.
  4. Update 1 · Vendor revised

    PHP warned on 23 October of a third, related flaw (CVE-2026-115560) that the 21 October releases don't fix, and called it an unlikely way in. It only affects websites whose code changes how PHP stores sessions while it's running, the setting change PHP already recommended for the second flaw blocks it, and the fix comes in PHP's next regular release.[4][5]

  5. Update 2 · CISA added

    CISA, the US cybersecurity agency, added both php2shell flaws to its list of vulnerabilities being used in attacks on 26 October. A researcher has since seen attackers run their own code on an unpatched test server, Amazon says attempts began on 17 October, four days before the fix, and on 28 October CISA listed a Linux flaw it says can be chained with them to take full control of a server.[6][7][5][8][9]

    What to do nowAsk anyone who runs a website for you to confirm it's on PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or their vendor's fixed version. Ask them to check it for signs of a break-in since 17 October: updating doesn't remove anything an attacker already left behind. If it's on PHP 8.1 or older, ask for it to be upgraded or taken offline now. Ignore emails urging you to log in for a security update.

Why this one is big

PHP is the language underneath WordPress, Drupal, Magento and a long tail of booking systems, client portals and school websites. W3Techs, which tracks the technology behind websites, puts it at about 70% of the sites whose server-side language it can detect.[10]

  • PHP
  • WordPress
  • Drupal
  • Joomla
  • Laravel
Built on PHP.A few of the most common platforms that run on PHP, and the sites built with them.

The harder number is how many of those are old. More than a third of PHP websites still run version 7 or 5, which PHP stopped supporting years ago. PHP's official fix covers only 8.2 and newer. For 7.4 it posted source code a capable administrator can build from, and for anything older there's nothing to install. Some Linux vendors and paid support firms are backporting their own fixes, but most of those owners will have to upgrade, which is real work, or put the site behind protection and hope. The US cybersecurity agency, CISA, goes further: if a PHP system can't be patched, take it offline until it can.[3]

PHP 8
62.5%
PHP 7
29.4%
PHP 5
8.0%
PHP websites, by version.W3Techs, August 2026. Versions 7 and 5 no longer receive security fixes.

You can patch your own phone. You can't patch the thirty servers your family's data lives on.

Who is affected

It isn't your server. It's everyone else's.

Almost no family runs PHP at home. But think about where your details actually sit: the school's parent portal, the real estate agent's website, the family office's WordPress site, the accountant's client login, the booking system at the clinic. Some of those run PHP, and some run it on versions nobody has touched in years.

None of them are yours to fix. Each is someone else's job, on someone else's timeline, and you'll usually only hear about it if something goes wrong. That's the gap we wrote about in our essay: the companies you've given access to are another way in.

How this reaches a family

  1. A website you trustYour accountant’s, your school’s, the club’s. It runs on an old version of PHP.
  2. Attackers take it overThe two flaws let them run their own code on the server.
  3. HARDFake site protection and downloadsThe extension for Chrome and Brave catches known phishing pages and passwords typed into the wrong site. On a Mac, HARD notes where every download came from and checks it for malware.See how it works
  4. The site turns on its visitorsIt hands over the data it holds, or starts serving fake sign-in pages and downloads to the people who trust it.
Where HARD comes in.With HARD, the greyed-out steps don’t happen.

What to do this week

The steps below are from the article as first published, on 21 October 2026.

  1. Ask whoever runs a website for you.The family office, a business, a foundation, a personal site. Ask in writing: do you use PHP, which version, and have you installed Thursday's fix?
    Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Hosting companies and Linux vendors may number their fixed versions differently, so ask them to confirm.
  2. If the answer is PHP 8.1 or older, ask for a plan. Upgrade, take it offline, or put it behind a firewall. "We'll look into it" isn't a plan.
  3. Expect emails that ride the news. "Urgent security update, log in to confirm" is the oldest trick there is. Don't click. Go to the site yourself.
  4. Watch for breach notices over the next few weeks.If a company tells you it was affected, change that password. If every password is different, one breach stays one breach. The AT&T breaches show how long the fallout lasts.

Or have someone do it. Knowing which of your vendors run what, and calling them before the exploits land, is exactly what private cybersecurity is for.

  • CVE-2026-109618 Attackers can run their own code on PHP from anywhere, without logging in.
  • CVE-2026-109619 Attackers can run their own code on PHP from anywhere, without logging in.
  • CVE-2026-115560 Not on CISA’s list of flaws being used in attacks. Look it up in Search.
  • CVE-2026-46300 Attackers are using a flaw in Linux Kernel.
  • PHP every PHP flaw being used in attacks
  • PHP Group every PHP Group flaw being used in attacks
  • Linux every Linux flaw being used in attacks

References

Checked against the sources. Where reports disagree with PHP's own notice, we've used PHP's.

  1. ^ BleepingComputer. “PHP warns admins of two critical flaws, emergency patches coming tomorrow”. The leak, PHP's notice, the 9.2 rating and watchTowr's reproduction.
  2. ^ PHP. “Security advisory: critical remote code execution vulnerabilities, update now”. The fixed versions, who is most at risk, and fixes for older versions.
  3. ^ CISA (). “Critical vulnerabilities in PHP require immediate patching”. No attacks seen yet. Take systems offline if they can't be patched.
  4. ^ PHP (). “Informational advisory: Session upload progress”.
  5. ^ BleepingComputer (). “CISA confirms PHP2Shell vulnerabilities now exploited in attacks”.
  6. ^ CISA (). “Known Exploited Vulnerabilities Catalog: CVE-2026-109618”.
  7. ^ CISA (). “Known Exploited Vulnerabilities Catalog: CVE-2026-109619”.
  8. ^ BleepingComputer (). “Amazon says PHP2Shell exploitation began 4 days before patches”.
  9. ^ CISA (). “Known Exploited Vulnerabilities Catalog: CVE-2026-46300 (Linux kernel)”.
  10. ^ W3Techs. “Usage statistics of PHP for websites”. About 70% of websites with a known server-side language, and the split by version.
  11. BleepingComputer. “PHP ships emergency patches for critical PHP2Shell flaws”. The fixed versions, and Cloudflare's report of early attacks.
  12. Huntress. “Rapid response: php2shell, leaked critical PHP vulnerabilities”. No attacks on its partners' systems as of Wednesday, US time.
  13. watchTowr. “PHP remote code execution FAQ”. Reproduced one flaw before the fix. Now reports attacks from 21 October.

Situation Room articles are updated as events develop: updates are added to the timeline, and never edited away. Follow them by email or RSS.