loading
loading
If you run PHP anywhere in your environment, patch to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now. Two critical flaws disclosed last week, CVE-2026-109618 and CVE-2026-109619 (nicknamed "PHP2Shell"), let an unauthenticated attacker run code on a server with nothing more than a crafted web request. Both carry a CVSS v4.0 score of 9.2, every earlier release is affected, and exploitation in the wild has been reported. The patch is the easy part. The hard part is finding every copy of PHP you own, because PHP rarely shows up where you expect it. This post covers what the flaws are, how far exploitation has gone, and how to get to full coverage fast. What happened Details leaked before the planned embargo, so the PHP security team moved fast and shipped fixes within about a day of announcing them. The two vulnerabilities Both bugs live in PHP core, not in any framework or plugin, so they reach anything that runs PHP to serve web requests. Affected server setups include PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php as the highest risk. No login is needed: the attacker only has to reach a PHP endpoint over HTTP. Fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Every earlier release is affected. PHP has also published minimal source backports for 7.4, 8.0 and 8.1, but there are no official releases for those branches. Treat a backport as a stopgap and plan the upgrade. Is it being exploited? Yes, though reliable public exploits are still scarce. watchTowr reports exploitation in its honeypot network as of October 21, and Tenable relays Cloudflare's CTO saying Cloudflare is seeing early attacks. Other telemetry, such as Patchstack's, shows mostly probing so far. Neither CVE is in CISA's KEV catalog yet, and no public indicators of compromise have been released. How hard the bug is to weaponize depends on the platform. VulnCheck reproduced both flaws and found: Code execution works on ARM64, and on x86 systems where address space layout randomization (ASLR) is turned off. Dozens of public proof-of-concepts exist, but very few work and none bypass ASLR on x86-64. Red Hat likewise rates RCE as hard in practice on default PHP-FPM deployments. Don't read that as permission to wait. Exploits mature quickly once a patch diff is public, and fake PoC repositories for headline CVEs often carry malware, so treat any you find with caution. Tanium's research on exploitability is in Why PHP2Shell is real(opens in a new tab). Most at risk: internet-facing PHP applications, especially those running mod_php or on ARM64 hosts. It's also worth retro-hunting recent web server and PHP-FPM logs for unexplained worker crashes and unusual multipart requests. Why finding PHP is harder than it looks No one has a complete list of PHP-based applications, and anything custom-built won't be on any list. PHP hides in several places at once: OS packages on Linux (php, php-fpm, php8.x), which package managers and most inventory tools see. Homebrew and similar on macOS, outside the system's own package list. Bundled copies on Windows. PHP on Windows usually arrives as a zip extracted to a folder or inside a stack like XAMPP, WampServer, Laragon or a vendor product. It often never registers as an installed application at all. Applications that ship their own PHP, where the fix depends on the application vendor rather than the OS. Containers, where the version is baked into the image tag. PHP is often more widespread than teams expect, and it doesn’t only run on servers. Developer tools, local web stacks and bundled applications put it on workstations too, often without registering as an installed application. The reliable answer is to look at the binaries themselves. In testing, PHP builds from version 5 through 8 all embed their version string (X-Powered-By: PHP/x.y.z), so you can read the exact version straight from the file without running it. How Tanium helps Tanium itself is not affected. Tanium does not use PHP, so there is no impact to Tanium software or Tanium Cloud services. Tanium Guardian content for PHP2Shell is available now in Tanium Cloud. The dashboard shows where PHP is installed and running so you can prioritize patching, with a single fleet-wide count of endpoints with vulnerable PHP across Linux, Windows and macOS. It combines: The existing Installed Applications and Homebrew Applications sensors, which find PHP installed through package managers on macOS and Linux. A Windows PHP Installations sensor that finds PHP where Installed Applications can't see it, including IIS, XAMPP, WampServer, Laragon, package managers and manually extracted copies, and reports version, install type, install path and owning user. The version is read from the binary's file metadata without executing it. A pre-built Saved Question that lists running PHP processes so you can prioritize systems that may be serving traffic. A pre-built Saved Question that identifies PHP containers, matching running containers against php, FrankenPHP and about 25 common PHP-based images such as WordPress, Drupal, Joomla, Nextcloud and Magento. Requires Tanium Cloud Workloads. Tanium Comply finds PHP on disk. For customers licensed for Comply, the dashboard includes PHP2Shell findings by endpoint, full finding details and a 7-day trend, with a pivot to the Comply findings page filtered to the two CVEs. The finding details report shows the specific on-disk locations where PHP was found, which catches copies that package and registry inventories miss. Vulnerability Library definitions for Windows, Linux and macOS are live now — sync the TVL and run an assessment to pick them up. On-premises customers can import the Guardian content manually today. Steps and downloads are in Guardian content for on-premises customers(opens in a new tab) on the Tanium Help Center. Know what's exposed to the internet. More than 13 million internet-facing assets run PHP versions that may be affected, according to Censys Internet Intelligence. Tanium External Attack Surface Management (EASM) discovers the internet-facing assets tied to your organization and identifies the PHP services, versions and web properties among them, with these CVEs surfaced through its coverage of exploitable and weaponized vulnerabilities. Tanium Attack Path Mapping then shows which of those exposed assets share an exposure point with a cloud instance, role or privileged identity: the places where one exploited PHP server becomes a route deeper into your environment. Already using Tanium SBOM? Inventorying PHP versions there is a sound early step. It shows which applications carry a vulnerable PHP and need a vendor update. What to do now Work through these in order; the first three matter most today. Find every PHP install, including Windows copies that never registered as applications. Record the exact version of each. Rank by exposure. Internet-facing servers, mod_php setups and ARM64 hosts come first. Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 through your OS vendor, a php.net build or your application vendor. Restart PHP-FPM and web server workers so the new binary is loaded. If you can't patch yet, isolate internet-facing PHP apps where you can, as CERT-EU advises, and put WAF or IDS rules in front of them (Cloudflare and VulnCheck have both shipped rules for the known vectors). Apply the partial setting with care. session.upload_progress.enabled=0 blocks one demonstrated path for CVE-2026-109619 only and does nothing for CVE-2026-109618. It must be set in php.ini, an FPM pool or server config, followed by a worker restart; ini_set() and .user.ini won't apply it. Hunt. Review recent web server and PHP-FPM logs for worker crashes and malformed multipart uploads. Plan off end-of-life PHP. Anything on 8.1 or older has no official fixed release. Where fixed packages stand (as of Oct 21, 16:30 UTC) Distro packages are still rolling out, so check your vendor before assuming a fix is available. The Remi repository won't ship updates today, so PHP advises switching to distro packages or building from source if you depend on it. Read more here. Supplied by Tanium
document fetched 2026-10-27 02:54 · canonical https://theregister.com/security/2026/10/26/partner-content-no-login-no-app-code-no-warning-what-next/5305336