On October 26, 2026, CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog. The entry classifies both PHP flaws as known exploited vulnerabilities. In Argentina, former CERT coordinator Ariel Cessario separately described measures taken by three named public-sector organizations; a reported scan counted signs of PHP use across part of the gob.ar site inventory.
What CISA’s KEV listing says
CISA’s October 26 notice lists both CVEs in the KEV catalog, which identifies vulnerabilities known to be exploited. The entry classifies the flaws; it does not name an Argentine incident. CISA’s notice gives the catalog action and its date.
The two PHP flaws use different failure paths
The PHP Foundation describes CVE-2026-109618 as remote code execution through memory corruption associated with an out-of-memory condition. Under a specified condition, partially initialized internal data can later be treated as valid. The Foundation says an unauthenticated request can trigger the flaw on Apache with mod_php before application code runs; it also reports demonstrated remote code execution with default settings and through PHP-FPM application-level paths.
CVE-2026-109619 involves stale internal request state. A fatal error can leave state pointing to memory from an earlier request, and a later request handled by the same worker can use that freed memory. The PHP Foundation reports a confirmed use-after-free and worker crash, along with a remote-code-execution demonstration against a real-world Apache/mod_php application. The Foundation’s technical account describes both flaws and their conditions.
Both vulnerabilities concern PHP running on servers. They do not mean that a website visitor’s device runs the vulnerable server-side PHP code.
Which PHP versions contain the fixes
The PHP project released fixes on October 21, 2026, in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Use the release corresponding to the branch running on the server. The PHP Foundation’s release account lists the corrected versions.
Buenos Aires City’s BA-CSIRT advisory says PHP 8.1 and earlier are outside the PHP project’s official support and do not have an equivalent new official release addressing these flaws. It advises moving to a supported branch or applying a security update from the relevant provider or software distribution. The BA-CSIRT advisory provides its administrator guidance. NeoTeo’s earlier coverage of the PHP fixes and next steps gives readers related background.
What the Argentina reporting says about agencies and sites
Ariel Cessario, former coordinator of Argentina’s CERT, told Clarín that Argentina.gob.ar and the Health and Economy ministries had carried out recommended measures by October 22. He said he could not confirm the response of other agencies.
A separate Segu-info scan, reported by Clarín, had analyzed 13,977 of 35,847 inventoried gob.ar sites in a snapshot taken at 1:53 p.m. on October 29. It found signs of PHP use on 4,758 sites: 2,354 with explicit evidence and 2,404 where PHP use was inferred from detected applications. Those figures count PHP-use signals, not vulnerable or compromised sites.
Among roughly 2,350 sites where the scan could identify a version, the report said 47% used PHP 4, 5, or 7, and 9% used PHP 8.0 or 8.1. The numbers describe that partial scan snapshot, not a confirmed tally of affected government systems.
BA-CSIRT’s checks for PHP administrators
BA-CSIRT advises administrators to check the PHP version, apply a corrected release or a security package from the relevant provider or distribution, and check every PHP environment. If someone else manages the server, contact the hosting provider or responsible technical team. The advisory says temporary mitigations do not replace an update.
Compatibility testing, maintenance windows, and service restarts can delay deployment, Aamir Lakhani of Fortinet told Clarín. Those operational steps make it important to check not just a main website server but also other environments where PHP is running.
