PHP CVE-2026-109618 and CVE-2026-109619 Added to CISA KEV: Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 Now

Two critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619, both CVSS v4.0 9.2) were added to CISA's Known Exploited Vulnerabilities (KEV) catalog on 26 October 2026. KEV lists vulnerabilities that have been exploited in the real world. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you have not updated yet, update now.

This follows our 21 October article. That article could not confirm whether attacks had started and noted that the flaws were not in KEV. That has changed. CISA added both to KEV on 26 October and set a remediation deadline of 29 October for US federal civilian agencies. CISA itself does not describe the exploitation (who, how many, by which route). Observations published by others (AWS, Sophos) are collected in "What others have published about the attacks." Known and unknown are kept apart.

Where the score comes from. 9.2 is the CVSS v4.0 score assigned by the CNA (the PHP Group), the same as in our earlier article. On 26 October NVD marked both records "Analyzed" and added its own CVSS v3.1 scores: 9.8 CRITICAL for CVE-2026-109618 and 8.1 HIGH for CVE-2026-109619 (checked through NVD's API). They differ because the versions differ. To stay comparable with the earlier article, this one uses the v4.0 score of 9.2.

What changed, with dates

• ▸17 October: AWS says its decoy systems recorded an attack attempt on this day, four days before disclosure (AWS)
• ▸21 October: PHP published the four fixed releases and its advisory. CISA and Japan's IPA issued alerts (CISA did not say the flaws were being exploited at that point). AWS and Sophos both say public exploit code began to circulate the same day
• ▸22 October: IPA published "Countermeasures for PHP vulnerabilities (PHP2shell)". IPA's page describes misuse only conditionally ("if exploited")
• ▸23 October: CISA updated its alert and added a SIGMA detection rule (CISA's update history). Separately, the UK NCSC's 21 October page does not say attacks have been observed
• ▸26 October: CISA added both CVEs to KEV. NVD's records also became "Analyzed" the same day
• ▸29 October: the deadline in the KEV entries for US federal civilian agencies (a US agency deadline; it does not bind organisations in Japan or elsewhere)

What "added to KEV" means

• ▸What it means: CISA judged that these two flaws have been exploited and put them in the catalog. The "no attacks confirmed" line in our earlier article no longer holds
• ▸What it does not mean: that your server was attacked. The number, timing and method of attacks are not given in CISA's alert or the KEV entries (others' observations are in the next section). Use in ransomware campaigns is listed as "Unknown" in KEV
• ▸A timing mismatch in NVD: the CISA assessment shown in NVD (SSVC, dated 21 October) still says exploitation: none. It predates the KEV addition of 26 October, so the older record does not reflect the current situation (our reading)

What others have published about the attacks

• ▸AWS (published 21 October): its decoy system (MadPot) recorded an attempt on 17 October, four days before disclosure. On 21 October there were also several attempts before the embargo lifted (14:00 UTC), and after the lift, exploit code was being used within hours. It suspects multiple actors, and also says it is unclear whether any attempt would have succeeded
• ▸Sophos (published 21 October, updated through 23 October): says proof-of-concept code is publicly available. What it observed was scanning and a small number of failed attempts, which tried to deliver a Mirai-derived payload and were blocked. It states there is no evidence of a successful compromise from these flaws. A 22 October note reporting one successful exploitation was later corrected
• ▸CISA's SIGMA rule: its references list several public exploit-code pages (CISA)
• ▸How to read this: each is a company describing its own telemetry. None shows damage in Japan or a count of successful attacks. But two separate sources say attempts began before disclosure and exploit code circulates after it

What to do now

• ✓★Check your PHP version. On the command line, `php -v`. The PHP your web server uses can differ from the command-line one, so also check from your control panel or phpinfo() (our addition). The guide below walks through it
• ✓Update to the fixed version. 8.5.12 for 8.5, 8.4.27 for 8.4, 8.3.36 for 8.3, 8.2.35 for 8.2 (PHP, CISA, IPA)
• ✓After updating, restart the PHP workers (processes) so the new version is actually running (our addition)
• ✓On hosting, managed services or containers, check what your provider or image has done. If you cannot update yourself you are waiting for the provider. PHP can be embedded in other products, so take stock of everything (CISA, NCSC)
• ✓PHP 8.1 and earlier get no regular fixed release. For people who build from source, the PHP team has published minimal source backports for 7.4, 8.0 and 8.1 on GitHub branches (see the earlier article). The main remedy is what IPA asks: move to a supported version or to a patched product or service. Until then, restrict access or, if needed, take the service offline (IPA, CISA)
• ✓If you updated after 17 October, review the period before the update too. AWS advises investigating from the earliest known attack, not the disclosure date. There is no need to assume a compromise, but if an unpatched PHP was serving traffic, check it against the signs below (AWS's advice and our addition)

To check versions and confirm the update took effect, use the environment-by-environment guide. Partial mitigations for when you cannot update yet (such as `memory_limit=-1`) are in the earlier article. The official advisory says updating is the only complete fix and the mitigations are partial.

Signs to look for (what has been published)

CISA's SIGMA rule (a detection definition) contains reported infrastructure and IoCs (indicators of compromise) and strings seen in public exploit code. But the rule is at "test" status and expects tuning for your environment. A match is not proof of compromise and false positives are possible. An absence in the logs is not proof of safety.

• ▸CISA: watch for PHP worker processes launching shells or downloading tools. CISA hosts a SIGMA detection rule on GitHub
• ▸Wiz (the researchers): unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID response cookies, and unexplained PHP worker churn. It adds that the issues run below the application layer, so application logs may hold little
• ▸AWS: look for POST requests that contain the string `PHP_SESSION_UPLOAD_PROGRESS` in form uploads. Review web server logs and check for unexpected process execution or file modification. The IP addresses AWS lists are shared anonymization infrastructure, not exclusive to this activity, so investigate hits rather than block them mechanically (the list is in AWS's post)
• ▸Sophos: watch for unusually long network sessions, misspelled process names and low-volume inbound traffic from low-reputation sources
• ▸NCSC (UK): if you cannot update or take the system offline right away, look for signs of compromise and backdoors, and use a specialist incident response provider if you lack the skills

What we could not confirm

• ▸How many attacks succeeded. CISA does not describe them. AWS says it is unclear whether any would have succeeded; Sophos says it has no evidence of success. This article cannot say either that there are or that there are not successful compromises
• ▸What the public exploit code does and how reliable it is. We confirmed that it is public from Sophos and CISA's references, but did not open the exploit pages themselves. Sophos says researchers' exploits may work only in lab conditions
• ▸Each IoC in CISA's SIGMA rule. We did not vet them one by one. Treat them as leads, since false positives are possible
• ▸Damage in Japan. IPA's page records none
• ▸The NSA advisory. CISA links to it, but it would not open for us, so we did not read it
• ▸Update status of distro packages, container images and hosts. We did not check them individually
• ▸The exact scope for 8.1 and earlier. NVD's records include versions from 7.3.0 (CVE-2026-109618) and 5.4.0 (CVE-2026-109619), while PHP's own table covers 8.2 to 8.5 only. The older versions get no regular fixed release, only the source backports

Three lines to share

• ▸Two critical PHP flaws (CVE-2026-109618 and CVE-2026-109619, CVSS v4.0 9.2) were added to CISA's exploited-vulnerability catalog (KEV) on 26 October. They allow unauthenticated remote code execution, and exploit code is public
• ▸★Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now and restart the PHP workers. Check your hosting provider too. On 8.1 or earlier, move to a supported version
• ▸Attempts began before disclosure (17 October). Whether any succeeded is unknown. If an unpatched PHP was serving traffic, review whether PHP workers launched shells and whether HTTP 500s repeated

Pages this article is based on