php2shell PHP vulnerability: what happened and what site owners should do

On October 21, 2026 the PHP team shipped emergency releases — 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now widely known as php2shell. Both are rated 9.2 on CVSS v4.0: under the right conditions an attacker can run their own code on the server without logging in anywhere. Details leaked on October 20, before the fixes were out, and Amazon recorded the first exploitation attempts on October 17. Broad scanning is under way.

Here is what happened in plain words, who is affected and what to do, step by step.

If you are our client, you are covered: we closed this vulnerability for all of our clients as soon as the fixes were released. internet10k.com itself runs on a patched PHP version too.

What happened

Both bugs live in PHP itself, not in WordPress, Bitrix or your site's code.

• CVE-2026-109618. While PHP parses form data, a crafted request can exhaust the memory limit at an unlucky moment. An internal structure is left half-initialized, and cleanup then treats it as valid. Crucially, this happens while the request is being parsed — before any application code runs — so authentication and checks inside your app don't help.
• CVE-2026-109619. Data owned by one request can outlive it, and a later request handled by the same PHP worker uses memory that has already been freed. One path involves session upload progress, which PHP enables by default — even if your site never uses sessions.

Exploitation isn't trivial: the request has to be sized precisely and memory protections defeated. But with details public and scanning in progress, "nobody will bother with us" is not a plan.

Who is affected

According to the PHP team, every installation serving web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk for mod_php. Command-line PHP (CLI) is not listed.

• Vulnerable: all versions below 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
• PHP 7.4, 8.0 and 8.1 are affected too, with no official releases — only source backports for people who build PHP themselves, plus fixes from distributions and LTS vendors.
• PHP 5.4–7.3 are affected and will get no fix from the PHP project.

If your site runs on Tilda, Wix or another hosted builder, the platform patches its servers — nothing for you to do. If it runs on your own hosting or VPS — WordPress, 1C-Bitrix, custom code — it's on you or your contractor.

What to do, step by step

1. Find your site's PHP version. Your hosting panel shows it in the site settings. Sometimes it leaks in response headers — check with our CMS detector. If it shows up there, that's a minor issue in itself: it's better to hide the version.
2. Update to the fixed release of your branch. On your own server, use your distribution's packages or the panel. On shared hosting, confirm your provider has already updated — many did between October 21 and 23, not all. If the panel lets you choose a branch, switch to a supported one.
3. Restart PHP. Without a restart, PHP-FPM or Apache keep running old workers with old code.
4. If you're on PHP 8.1 or older, plan the move to a supported branch. Old plugins and custom code may need fixes — test that on a copy of the site, not in production.
5. Review logs from October 17 onward. Red flags: Allowed memory size ... exhausted ... in Unknown on line 0 errors ("Unknown" means the failure happened while parsing the request), worker crashes with Segmentation fault, POST requests with a PHP_SESSION_UPLOAD_PROGRESS field and very long field names, and above all a web process spawning a shell. A memory error alone doesn't prove an attack, but a burst of them is worth investigating.

If you can't update right away

The PHP team lists interim measures. They reduce exposure but don't make a server safe — updating is the only complete fix.

• For CVE-2026-109618: memory_limit = -1 at the administrator level (so the app can't override it), combined with request-size limits at the web server and a container memory limit. Don't use RLIMIT_AS or RLIMIT_DATA instead — they trigger exactly the failure the attack needs.
• For CVE-2026-109619: session.upload_progress.enabled = 0 in the main PHP configuration, plus fatal_error_backtraces = 0 on PHP 8.5. Setting these via ini_set() or .user.ini doesn't work — they must apply before the request is parsed.
• Restart all PHP workers after the change.

Separately, on October 23 PHP published a notice about another issue, CVE-2026-115560. It only affects sites that switch the session serialization handler at runtime and will be fixed in a regular release. If you're not sure how your code behaves, disabling session upload progress covers it as well.

After the update

Check that the site loads, forms submit, payments go through and integrations with your CRM or ERP still work — moving between PHP branches occasionally breaks old plugins. Then keep updates on a schedule, not just on headline days: the fix closed specific paths, not the whole class of bugs, and this won't be the last one.

If you'd rather not track this yourself, we can take your site on technical support: updates, monitoring and incident response are part of every plan. There's also dedicated WordPress support, and if you already see signs of a breach — hacked-site recovery.

Sources: php.net announcements, analyses by Datadog Security Labs and Tenable.

Need your PHP version checked or help with the update? Message us on Telegram or MAX.