Skip to content
SENTINEL
DEEN

Case study: php2shell

A PHP vulnerability rated 9.2 out of 10. What happened the night after.

On 21 October 2026, the PHP project released fixes for two vulnerabilities that together allow code execution without authentication: CVE-2026-109618 and CVE-2026-109619, known as php2shell, CVSS 9.2. This page shows how it played out on a server managed by Sentinel, what you can check yourself, and what Sentinel does not do here.

Chronology

From notice to audit log, without anyone getting out of bed.

  1. 21 Oct

    PHP releases the fixes. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 close both vulnerabilities. Observers report scanning traffic for the vulnerability even before the patch.

  2. 21 Oct, 16:07

    Ubuntu ships the packages. Security notice USN-8948-1 with fixed packages for Ubuntu 22.04, 24.04 and 26.04; for 22.04 as php8.1 in version 8.1.2-1ubuntu2.28.

  3. 22 Oct, 06:34

    Sentinel installs the update. In the maintenance window of a connected server running Ubuntu 22.04, set to 06:30 there, the run “Install 12 security updates” starts: check profile, record the package state, back up the configuration, snapshot of the whole machine, then the security updates, including php8.1 8.1.2-1ubuntu2.28, then the same check once more.

  4. 22 Oct, 06:37

    Run completed. Three minutes, result in the audit log: successful. Every step with command, output, duration and checksum. A good 14 hours after Ubuntu’s notice, the vulnerability was closed on this server.

Why not until the window? The packages did not show up in the server’s package lists until 22:37, six and a half hours after Ubuntu’s notice. Because two regular updates were pending at the same time, Sentinel planned everything together as one run for the maintenance window instead of installing the security updates on their own right away. On their own, they would not have needed a window. The audit log shows the hourly decision “Outside the maintenance window” from 22:41 onward. This has since been fixed: Sentinel splits off the security updates and installs them at the next hourly trigger without waiting for the window; the regular updates wait for the window.

One more detail from the audit log. This server’s website check was already red before the run because the site did not respond within 30 seconds. Sentinel carried out the maintenance anyway and counted as a failure only what would have newly turned red afterwards. Nothing did, and the old fault stayed reported as such.

For comparison, the manual route: learn about it from the news in the morning, check versions, plan a window, install, hope the site still runs afterwards. For ten servers, roughly speaking, a whole morning. On servers nobody maintains regularly, the vulnerability stays open until someone gets in.

Times in CEST, from the server’s Sentinel audit log and from the Ubuntu security notice. The server is a customer system; we do not disclose its name or address.

Check it yourself

Two commands, two minutes.

On Ubuntu and Debian, the PHP version number alone does not settle it; what counts is whether the package contains the fix. The distributions add fixes to their own package version without raising the PHP version. The package changelog tells you:

dpkg -l 'php*' | grep ^ii
apt-get changelog php8.1 | grep -m1 CVE-2026-109619

If a line with the CVE number appears, the installed package is fixed. On Ubuntu 24.04 the package is called php8.3, on 26.04 php8.5; on Debian 12 php8.2, on Debian 13 php8.4. The security notice USN-8948-1 lists which package versions are fixed.

If you cannot install right away

As an interim measure, the PHP project names disabling upload progress in php.ini, followed by a restart of PHP-FPM or the web server:

session.upload_progress.enabled = 0

This closes the known path via CVE-2026-109619, not every variant. Installing the update remains mandatory.

What Sentinel does

Not faster than Ubuntu. But faster than Monday.

This vulnerability was known and had a fix; that is exactly what Sentinel is built for: so that known vulnerabilities do not stay open until someone has time.

  • A check every ten minutes.Open security updates per server, matched against the Ubuntu security notices and the CISA catalog of actively exploited vulnerabilities. The exposure report tells you which servers are affected and whether a fix is available.
  • Installation, usually within an hour.Even at night, without waiting for a maintenance window, as far as the risk class allows. If regular updates are pending at the same time, Sentinel installs the security updates first; the rest wait for the window. First the check profile, then record the package state, then install, then the same check once more.
  • Rollback path.If the website is red after the update, Sentinel restarts stopped services and otherwise rolls back packages and configuration. If that fails, it pauses the server’s automation and raises an alert.
  • Audit log.Every step with a checksum chain. When a customer or auditor asks when php2shell was closed on your servers, the answer is there, with the time.

Limits

What an update does not cure.

If a server had already been taken over before the update, the update changes nothing about that. On the server, Sentinel detects changes to accounts, keys, scheduled jobs, services, ports and under /etc, and opens a case file for them. It does not see attacks on the web application itself, for example through this PHP vulnerability. That takes a web application firewall or analysis by humans.

If you suspect a successful attack: security analyses and penetration tests by LimeByte, the team behind Sentinel.

Request a pilot place How Sentinel handles vulnerabilities