Blue Team IT Security advisory ← Back to site
Security advisory · Critical

PHP2Shell: update PHP now.

Two critical flaws in PHP itself let attackers run code on a web server without logging in. Fixes are out, attacks are under way, and the only complete fix is to update. This page is our route from "is my site affected?" to "it's fixed and checked".

CVE CVE-2026-109618 CVE CVE-2026-109619 Severity CVSS v4.0 9.2 (both) Fixes released 21 Oct 2026
See the fix route → Get our help
▸ What happened

Two bugs, one big problem.

The flaws are in the PHP interpreter, not in any one website or plugin. Any site on a vulnerable PHP version is exposed, whether it runs WordPress, Drupal, Magento, Joomla, Laravel or hand-written PHP.

CVE-2026-109618

Out-of-memory corruption

When PHP runs out of memory part-way through a request, internal request data can be left half-set-up.

CVE-2026-109619

Stale request state

Request data can outlive its memory, and a later request handled by the same worker may use that stale state.

Who is affected

Every web-facing PHP

PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Reports say versions as old as PHP 5.4 are affected.

Attacks are real. Security firms including watchTowr and Cloudflare report active exploitation attempts, and Amazon recorded an attempt on 17 October, four days before disclosure. At the time of writing, Huntress had not seen exploitation across its partner base, and no source had confirmed a successful break-in of a specific server. That means "nothing seen yet", not "safe".
▸ Our status

Where we stand.

Server checkUpdated 22 Oct 2026, 16:00 SAST
ServerWeb PHPState
server-01.example.co.za8.4.XXAwaiting host confirmation
server-02.example.co.za8.3.XXUpdated and restarted
server-03.example.co.za8.2.XXUpdate scheduled
Status is updated as each server is confirmed, not before.
▸ The fix route

Six steps, in order.

Written for sites on hosting with a terminal (cPanel or SSH). On managed hosting you may not be able to do every step yourself, in which case the host's written confirmation is the evidence you need. Replace yourdomain.example with your own domain.

Disclaimer · use at your own risk

The steps and commands on this page are exploratory checks only. They help you find out what PHP your site runs and look for signs of trouble. None of them fixes the flaws, and no code fix is shown here. The only complete fix is the PHP update (or a confirmed backport) from PHP or your host.

Always double-check any code or command, from anywhere, including this page, before you run it. Make sure you understand what it does, run it on the right server, and take a backup first if you are unsure.

This page is general guidance, provided as is and without warranty. You use it at your own risk, and Blue Team IT accepts no liability for loss or damage that results from acting on it.

  1. Find the PHP your site really runs

    A control panel can show you a different PHP from the one serving your website (phpMyAdmin, for example, can run on the panel's own PHP). Check the web-facing version and handler.

    Terminal 
    f=v$RANDOM$RANDOM.php; echo '<?php echo PHP_VERSION," ",PHP_SAPI,"\n";' > ~/public_html/$f; curl -s https://yourdomain.example/$f; rm -f ~/public_html/$f

    It prints one line such as 8.4.26 litespeed and deletes its own temporary file. Do this for each domain or subdomain that may use a different PHP version.

    This step makes a change. The command writes one temporary file into your web folder, requests it once, then deletes it. It prints only the PHP version and handler, but it is a write to your web root.
    Do first · 2 minutes

  2. Update to a fixed release, or get the backport confirmed in writing

    PHP states that no configuration change fully closes these flaws. The complete fix is the matching release for your branch:

    PHP 8.58.5.12
    PHP 8.48.4.27
    PHP 8.38.3.36
    PHP 8.28.2.35

    Some hosts keep the old version number and backport the fix into a rebuilt package. If your web-facing version is lower than the table above, ask your host:

    "Does the PHP build serving my account contain the fixes for CVE-2026-109618 and CVE-2026-109619 (backported), and have the web server and PHP workers been restarted since? If not, when will a patched build be deployed?"

    On PHP 8.1 or older? Plan an upgrade to a supported branch, get a vendor backport, or isolate the site behind a firewall or VPN until you can.

    Same day

  3. Restart the PHP workers

    An update does nothing for workers that were already running. PHP-FPM, LiteSpeed or Apache has to be restarted so it loads the new build. On managed hosting this is the host's job, so include it in your question to them.

    Right after the update

  4. Check for signs of compromise since 17 October

    Attacks were reported from 17 October, so patching today does not undo anything that already happened. These checks are for cPanel-style hosting; adjust the log paths for your own server. A clean result means no evidence found, not proof of safety, because access logs do not record request bodies.

    • Unusual POST requests in your access logs, especially to PHP files you do not recognise.
    • New or changed PHP and config files in your web folders that you did not deploy.
    • PHP processes launching shells (sh, bash, curl, wget, python) or writing files into the web root.
    • Scheduled jobs you did not create.
    1 · POST requests since 17 Oct 
    zgrep -H -E '\[(17|18|19|20|21|22)/Oct/2026.*"POST ' ~/logs/*-Oct-2026.gz ~/access-logs/* 2>/dev/null | awk '{print $1,$4,$6,$7,$9}' | head -60
    2 · PHP and config files changed since 17 Oct 
    find ~ -xdev -type f \( -name '*.php' -o -name '*.phtml' -o -name '.htaccess' -o -name '.user.ini' \) -newermt '2026-10-17' -not -path '*/mail/*' -not -path '*/.cpanel/*' -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null | sort | head -50
    3 · Running processes and scheduled jobs 
    ps -u $USER -o pid,ppid,lstart,etime,cmd; crontab -l 2>&1

    If something looks wrong: isolate the server, keep the web server and PHP logs, and call us before changing anything. Do not delete files you have not identified.

    Same day · 20 minutes

  5. While you wait: reduce the exposure (this is not the fix)

    • Turn off session upload progress. Set session.upload_progress.enabled = 0 (in cPanel: MultiPHP INI Editor) and restart the workers. This closes one confirmed attack path for CVE-2026-109619 only. It does nothing for CVE-2026-109618.
    • Put a web application firewall in front. Cloudflare says it enabled rules for the known exploit vectors by default, but it also saw attackers change payloads to get around them. Treat a firewall as noise reduction, not protection.
    This step makes a change. It alters your PHP configuration and needs the workers restarted to take effect. Write down the current value first so you can put it back.
    Only until the update lands

  6. Re-check, then keep watching

    When your host says the update is done, run the step 1 command again and confirm the version, or the backport in writing. Then keep an eye on your logs for a few weeks, because scanning for unpatched sites will carry on long after the headlines fade.

    After the host's confirmation
▸ Need a hand?

We'll run this route for you.

We check the real web-facing version, chase your host for written confirmation, search for signs of compromise and report back in plain terms.

info@blueteamit.co.za WhatsApp 076 992 3731

This advisory reflects public reporting as of 22 October 2026 and will change as more is confirmed. It is general guidance, not a guarantee that any particular site is or is not affected. Use at your own risk, and always double-check any code before you run it.