Enviera

For operations teams

Your own ops system, run by usTake the repetitive work off your team

For founders with a prototype

Take your prototype to production

For teams that need engineers

An engineer in your team while you hireAn extended dev team, month to month
How we build
Sign inBook a call

PHP2Shell: are 70% of websites affected, and should you change your password?

Last updated: 24 October 2026

In short

PHP2Shell is two critical flaws in PHP: CVE-2026-109618 and CVE-2026-109619. The PHP team says every PHP installation serving web requests is at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed (php.net). So the problem is on the website's server, not on visitors' phones or laptops. What closes it is updating PHP on the server to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (php.net).

On 21 October a viral Indonesian Threads post called it a "flaw in the core engine of 70% of the world's websites", said there was "no fix yet", and suggested changing passwords (our translation). Here are the facts.

Half true: a flaw in the core engine of 70% of the world's websites

Fact: true when it was announced, but it isn't today's number.

About 70% is the share of websites that use PHP. As of 24 October 2026, W3Techs reports PHP on 69.3% of websites whose server-side programming language it knows (W3Techs). Kompas Tekno cites the same W3Techs data: about 70 percent of websites whose server-side language can be identified (Kompas Tekno). Wiz researchers also write that PHP powers 70% of all websites in the world (Wiz). When the flaws were announced, every PHP installation serving web requests was at risk until updated (php.net). So on that day, the ~70% figure matched these sources.

What's wrong is assuming it's still 70% now. Sites that have updated PHP are no longer exposed to these two flaws, and no public count of still-exposed sites exists. To know your status, check your version: how to check.

In Indonesia, BSSN, the national cyber agency, aimed its warning at site owners and operators (Kompas Tekno). The Ministry of Industry took its websites and several digital services offline from 22 October at 22:00 WIB, which it called a risk-mitigation step (Kompas Tekno).

Myth 1: there's no fix yet

Fact: outdated. The post went up at 08:47 UTC on 21 October. The day before, the PHP team had announced the security release for 21 October at 14:00 UTC (php.net), and the fixes shipped that day: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux distributions and LTS vendors got the patches in advance. For 7.4, 8.0 and 8.1, the PHP security team published minimal source backports (php.net).

Is it being exploited?

Yes, there are real attack attempts. Amazon found a first exploitation attempt in its MadPot honeypots on 17 October, four days before disclosure. On 21 October, still before the patch was released, more attempts came from varied anonymized infrastructure, which Amazon says suggests multiple actors. For these pre-disclosure attempts, Amazon says it's unclear whether any of them would have succeeded against real systems (AWS).

After the patch came out, new exploits appeared within hours, and Amazon says PHP2Shell "is now seeing broad exploitation attempts in the wild" (AWS). watchTowr has observed exploitation in its honeypot network since 21 October (watchTowr).

That's why Amazon advises starting investigations from at least 17 October, not from the disclosure date (AWS).

Half true: change your password or turn on 2FA

The full line in the post: "If you still use the same password on several websites, better change your password right away or turn on 2FA" (our translation).

Fact: good advice, but it doesn't fix the flaw. Wiz researchers showed that attackers can read PHP process memory, which can contain passwords, authentication tokens, API keys and certificates (Wiz), so changing reused passwords and turning on 2FA makes sense. But the flaw is in PHP on the server, and the PHP team says only an update is a complete solution (php.net).

Who needs to do what:

  • Site visitors: change passwords you reuse, turn on 2FA, and change your password right away on any site that announces a breach. These steps protect your account. They don't close the flaw on that site's server.

  • Site operators: update PHP first, then restart every PHP worker so the fix takes effect (watchTowr). Then check whether the server was broken into. Huntress has no confirmed indicators of compromise (IOCs) yet, but advises that if you find something, you isolate the server, keep the web server and PHP logs, and look for webshells, new files in the web root, and new cron jobs, scheduled tasks and accounts (Huntress). Kompas Tekno notes the check can also cover possible credential leaks. Technology firm PXL, quoted by Kompas Tekno, advises operators who find suspicious signs to change passwords and access keys and restore the site from a clean backup. Finding no signs isn't a guarantee either, because PHP2Shell can be used to read data in memory without leaving new files or accounts. So, in Kompas Tekno's summary of PXL and Malwarebytes, operators who were still running vulnerable PHP after 20 October are advised to change database passwords, security keys and API keys (Kompas Tekno).

Myth 2: I'm on Cloudflare, so I'm safe until I update

This came up in replies further down the thread. One reply said Cloudflare already blocks requests to the vulnerable path, "so you can still sleep easy tonight". A user then said "I use Cloudflare to set up my DNS", and the next reply answered: "Then you're set, safe for tonight" (our translations).

Fact: Cloudflare's WAF rules help, but they aren't a fix.

  • Cloudflare itself says customers should patch PHP even with the WAF protections (Cloudflare).

  • Using Cloudflare for DNS doesn't mean your traffic goes through Cloudflare. A proxied record (orange cloud) sends HTTP/HTTPS requests to Cloudflare's network. A DNS-only record (grey cloud) is answered with your server's real IP, so requests go straight to your server (Cloudflare Docs) and the WAF never sees them.

  • For the related flaw CVE-2026-115560 (see step 4 below), Cloudflare noted on 23 October that its WAF rule doesn't cover sites that changed session.upload_progress.name (Cloudflare).

  • Google Cloud calls its own WAF rules compensating controls only, and says upgrading PHP is required to fully resolve the flaws (Google Cloud).

The second reply ends with "remember to update tomorrow". That part is right.

What to do

  1. Check your server's PHP version and how PHP runs. Steps for cPanel/shared hosting and VPS: Am I affected by PHP2Shell?

  2. Update to a patched version, or ask your host to. Then restart every PHP worker (watchTowr).

  3. Look for signs of compromise, going back in your logs to at least 17 October (AWS).

  4. There's one more related flaw, CVE-2026-115560 (session upload progress). The PHP team calls it an unlikely RCE vector: it only applies when an app sets session.serialize_handler to php_binary or php_serialize and then switches it to php at runtime with ini_set() before session_start(). Its fix and full advisory come with the next regular release. Until then they suggest session.upload_progress.enabled=0, and if you set it on 21 October, keep it in place (php.net). The 21 October advisory says how: in php.ini, an FPM pool or server configuration, not with ini_set() or .user.ini, then restart every worker (php.net).

Want us to check and patch it?

We've checked and patched PHP hosts we run for clients (WordPress, WooCommerce and Moodle sites). For your server, we check the PHP version, SAPI and packages, then patch, upgrade or backport (PHP 7.4–8.1), restart the workers and look for signs of compromise. On shared hosting, we switch the PHP version where the hosting panel allows it. Where it doesn't, the server's PHP belongs to your host, and we send your host the exact request. You get a written findings report the same day you request it. For servers we patch ourselves, we report the final status as it is: checked and patched.

See the scope and request a check & patch →