On 21 October 2026 at 14:00 UTC the PHP team shipped out-of-band security 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, nicknamed php2shell — that allow unauthenticated remote code execution. Both are rated CVSS v4.0 9.2, and Slovakia's SK-CERT says they are exploitable in every PHP version from 5.0 onward that does not yet carry the fix.
GLPI runs on PHP. That alone makes this every operator's problem.
The flaw is not in GLPI, the server is vulnerable anyway
The GLPI project published a statement the same day: the GLPI core does not contain these flaws. The server hosting GLPI stays vulnerable until PHP itself is patched, whatever GLPI version you run. Updating GLPI does not solve it.
For self-hosted instances:
- Find the PHP version your web server actually uses — in GLPI under Setup → General → System. The
php -vcommand shows only the CLI build, which is often not the one PHP-FPM runs. - Update the PHP package. Distributions frequently backport the fix without bumping the version number, so follow your distribution's advisory rather than the release number alone.
- Restart Apache, Nginx or the PHP-FPM pool. Without a restart the old binary keeps serving requests.
The official GLPI Docker images were rebuilt with patched PHP for the main, 12, 11 and 10 branches. Restarting a container keeps the old image — you need docker compose pull followed by docker compose up -d; data in volumes is preserved. GLPI Network Cloud customers need do nothing, as the project says the platform was patched at disclosure time.
Older installations are in the worst position
The fixed branches are 8.2 through 8.5. PHP 8.1 and older no longer receive updates from the project; all that exists are minimal source backports for 7.4, 8.0 and 8.1, plus fixes from distributions and LTS vendors.
GLPI's minimum requirements are PHP 7.4 for the 10.0.x branch, 8.2 for 11.0.x and 8.3 for GLPI 12. A GLPI 10 instance on PHP 7.4, 8.0 or 8.1 is not left relying on its distributor, though: GLPI 10.0.28 runs on PHP up to 8.5, so moving to a patched 8.2 to 8.5 branch does not mean leaving GLPI 10. And anyone who patched to 8.2.35 has security support for that branch until 31 December 2026 — two months, not two years.
The second notice, on 23 October
Two days after the fix, the PHP team added an informational advisory about session upload progress, tracked as CVE-2026-115560. The recommendation is to set session.upload_progress.enabled=0 until the next regular bugfix release; it is being handled in the normal release cycle, not as another emergency release. The issue only arises in an unusual combination: the application sets session.serialize_handler to php_binary or php_serialize, switches it to php at runtime with ini_set() before session_start(), and still has upload progress enabled. If you applied that setting as a mitigation on 21 October, leave it in place and do nothing else.
If you cannot patch immediately
SK-CERT recommends inventorying every PHP deployment, including third-party products, containers and appliances, and taking unpatched internet-facing services offline or isolating them. WAF rules are not a substitute for the fix. PHP.net says the same about partial measures — memory_limit=-1 via php_admin_value, a lower post_max_size, upload progress disabled, and on PHP 8.5 also fatal_error_backtraces=0: they reduce exposure without making an installation safe.
Honeypot networks picked up exploitation attempts on the day of disclosure. Amazon reports an attempt on 17 October, four days earlier, so a log review is worth extending back past 21 October. The Slovak Ministry of Interior took minv.sk offline on 21 October as a precaution and restored it a few hours later.