A look back at 21–23 October 2026. This article records SITsolutions’ PHP security briefing from that period. It is no longer maintained as a live alert and does not describe today’s threat landscape. Moving the briefing into this retrospective does not mean that unpatched systems are safe.
Two critical vulnerabilities and available updates
On 21 October 2026, the PHP project released fixes for CVE-2026-109618 and CVE-2026-109619. The corrected versions announced at the time were PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Under suitable conditions, the flaws could allow unauthenticated remote code execution. PHP installations serving web requests were affected, including PHP-FPM and Apache mod_php. The PHP team considered mod_php the highest-risk configuration.
The advisories described memory corruption during out-of-memory handling and internal state surviving between requests. They documented successful code execution in tests against mod_php and, under specific application conditions, PHP-FPM. With mod_php, vulnerable processing could be reached before application code ran, so an application login did not reliably protect that path.
How the situation was assessed at the time
In its notice dated 21 October 2026, version 1.1, Germany’s BSI assigned Orange severity, level 3 of 4. It called for immediate measures and expected exploitation soon. Reports of initial attack attempts had not been verified by the BSI at the time of that notice. CERT-EU highlighted publicly discussed technical details and circulating proofs of concept.
Demonstrated exploitation in tests, an increased likelihood of attacks and a confirmed attack campaign needed to be distinguished. The briefing did not establish that particular portals had been compromised. Precautionary shutdowns could also explain unavailable services.
What operators were advised to do
The main recommendation was to update the underlying PHP runtime immediately and restart PHP workers. Updating a CMS alone was insufficient. Container images might need rebuilding and redeploying; appliances required the manufacturer’s guidance. Operators of older PHP branches needed a supported upgrade or a verified vendor fix.
Configuration changes and web application firewalls were regarded as limited measures, rather than replacements for complete security updates. Where prompt patching was impossible, the BSI recommended considering temporary disconnection of affected services from the internet.
For incident checks, a lack of suspicious log entries did not establish safety. Configuration, application behaviour and system integrity also needed review. Patching alone would not remove access already established by an attacker.
Why visitors to familiar portals were included
A server compromise could have allowed attackers to change sign-in pages, steal submitted information or distribute malicious downloads at a familiar address. These were possible consequences, not evidence of specific incidents. Visiting a PHP website did not automatically infect a device. HTTPS protected the connection but could not guarantee trustworthy content on a compromised server.
SITsolutions therefore advised visitors to independently verify unexpected sign-in requests, changed payment details and software installation instructions, respect browser warnings and report suspicious activity to IT. This awareness remains a useful general precaution.
Sources and historical context
- PHP project: security announcement of 21 October 2026
- PHP Security Advisory for CVE-2026-109618
- PHP Security Advisory for CVE-2026-109619
- CERT-EU: Security Advisory 2026-018, version 1.1
- CERT.at: critical PHP vulnerabilities
- BSI security notice BITS-H 2026-297981-1132, version 1.1, 21 October 2026, TLP:CLEAR; independent summary by SITsolutions.
Published as a retrospective on 23 October 2026. Based on the briefing and source review of 23 October 2026 at 07:56 CEST. Later changes to linked sources are not automatically part of this account. Current vendor guidance should inform decisions today.