IT adminsServers & enterprise softwareKnown exploited (CISA KEV)

PHP Memory Corruption Flaws: Fixes and Exploitation

Published · PHP · 2 CVEs · NVD and CISA KEV checked October 30, 2026

Illustration of a server rack and a database with a shield

In short PHP has critical memory corruption flaws known to be exploited. Learn which releases are affected and how to verify an update.

What happened

PHP has addressed memory corruption vulnerabilities in PHP 8.2, PHP 8.3, PHP 8.4 and PHP 8.5. Think of request memory as a workspace that should be cleared between customers: these flaws can leave PHP consulting information that was never prepared correctly or has already been discarded. Under the conditions described by NVD, that mishandling can lead to remote code execution, meaning an attacker can cause the affected server to execute code.

The vulnerabilities are CVE-2026-109618 and CVE-2026-109619. NVD published both records on 2026-10-21 and assigns each a CVSS 4.0 score of 9.2, rated CRITICAL. The vendor's advisory identifies corrected releases for every listed PHP branch. KISA, Korea's Internet & Security Agency, also published an advisory on 2026-10-21.

Both vulnerabilities are known to be exploited. CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog on 2026-10-26, with a listed due date of 2026-10-29. The catalog records known ransomware use as Unknown for each vulnerability; that does not establish whether ransomware operators have used them.

Technical details

These are memory corruption vulnerabilities: PHP can use memory whose contents or lifetime no longer match what the runtime expects. NVD associates both vulnerabilities with CWE-1325, Improperly Controlled Sequential Memory Allocation; CWE-416, Use After Free; CWE-755, Improper Handling of Exceptional Conditions; and CWE-824, Access of Uninitialized Pointer. Together, these classifications describe problems involving memory allocation, error handling and references to memory that is unprepared or no longer valid.

CVE-2026-109618 concerns PHP's response to an out-of-memory condition, when it cannot obtain memory needed for processing. PHP uses longjmp() to leave the current execution context and stop processing the request. Some contexts do not fully accommodate that exit, allowing memory used during request handling to remain uninitialized. Cleanup can then consult those unprepared contents when reading data or deciding what to do next. NVD describes multiple ways to trigger this condition through out-of-memory behavior, with remote code execution as a possible result.

CVE-2026-109619 involves global state, information retained by the runtime that can temporarily reference memory belonging to a request. Those references may survive a reset or be restored afterward. Once the referenced request memory has been freed, the references become stale. Later requests can consult that stale state before it has been properly initialized. NVD describes multiple ways to trigger this condition and achieve remote code execution.

The described attack conditions involve reaching the affected memory-handling behavior: an out-of-memory error path for CVE-2026-109618, or stale references to freed request memory for CVE-2026-109619. The descriptions do not establish a particular application feature, authentication requirement or request format. CVSS, the Common Vulnerability Scoring System, rates the technical severity of a vulnerability. The 9.2 CRITICAL rating indicates serious potential impact; it is not a probability that a particular server will be compromised. CISA's exploitation listing provides separate evidence that exploitation is occurring.

Weakness types: Memory corruption

Who is affected

Everyday users

For everyday users, the main concern is a service running an affected PHP release. The described code execution happens on the server processing requests. If you only visit a PHP-powered service, the server operator is responsible for updating its PHP runtime.

If you manage your own hosted site, ask the hosting provider or site administrator to confirm the PHP release actually serving it. An application that appears to work normally does not demonstrate that its underlying PHP runtime has been corrected.

Developers

Developers should treat this as a PHP runtime update. The described defects concern PHP's internal memory handling, so reviewing application code alone does not establish that the problem is resolved. Check the runtime used by each deployed application and coordinate the update with whoever maintains that environment.

Pay particular attention to the distinction between the PHP executable you check from a terminal and the runtime serving application requests. Confirm the deployed environment, then exercise representative application behavior after the update. Avoid drawing conclusions about exploitability from the absence of a particular application feature, since the descriptions do not identify a single required feature.

Server and IT admins

For server and IT administrators, the affected ranges are PHP 8.2 earlier than 8.2.35, PHP 8.3 earlier than 8.3.36, PHP 8.4 earlier than 8.4.27 and PHP 8.5 earlier than 8.5.12. Both CVE-2026-109618 and CVE-2026-109619 have the same affected and fixed release boundaries within each branch.

Prioritize affected deployments because CISA KEV confirms known exploitation. Its listed due date of 2026-10-29 should be kept distinct from the technical fix: remediation means deploying a corrected runtime and confirming that the application uses it. A successful package update by itself does not establish which PHP release is handling requests.

What to do now

  1. Identify the PHP branch and release used by each application. Use the version-check command where appropriate, and confirm which runtime actually serves requests.
  2. For PHP 8.2, update to 8.2.35 and later. For PHP 8.3, update to 8.3.36 and later.
  3. For PHP 8.4, update to 8.4.27 and later. For PHP 8.5, update to 8.5.12 and later. These release boundaries address both listed vulnerabilities.
  4. Follow the update steps in the vendor's advisory. If your environment uses operating-system packages, use the package update command appropriate to that environment and check the resulting PHP release.
  5. For provider-managed hosting, have the provider confirm that the PHP runtime serving your application has been updated to a corrected release.
  6. After updating, confirm the active runtime and check normal application behavior. Record the resulting PHP release against both CVE-2026-109618 and CVE-2026-109619.

Check the PHP version · official docs

php -v

Update packages (Debian/Ubuntu) · official docs

sudo apt update && sudo apt upgrade

Update packages (RHEL/Rocky/Alma) · official docs

sudo dnf upgrade

If you can't update yet

  • Check the vendor advisory for interim guidance on restricting access to affected deployments and reducing their internet exposure while an update is pending. Treat these as exposure-reduction measures, not confirmation that the memory corruption flaws are fixed.

How to confirm the fix

  • Check the resulting release against the corrected boundary for its branch: PHP 8.2 requires 8.2.35 and later; PHP 8.3 requires 8.3.36 and later; PHP 8.4 requires 8.4.27 and later; PHP 8.5 requires 8.5.12 and later.
  • Confirm that the runtime serving application requests is the corrected release. A terminal version check alone may not establish the version used by the deployed application.
  • Check representative application requests after the update to confirm normal operation. Functional success is useful operational validation, but the corrected runtime release is the relevant evidence of remediation.
  • For managed environments, obtain confirmation of the active PHP release from the hosting provider or administrator and retain it with the remediation record.

NVD scores and CISA KEV status

Listed in CISA's Known Exploited Vulnerabilities catalog: CVE-2026-109618 (added October 26, 2026), CVE-2026-109619 (added October 26, 2026). CISA adds a CVE only when it has evidence of exploitation in the real world.

CVECVSSSeverityWeakness (CWE)KEV
CVE-2026-1096189.2 (v4.0)CriticalCWE-1325, CWE-416, CWE-755, CWE-824Listed
CVE-2026-1096199.2 (v4.0)CriticalCWE-1325, CWE-416, CWE-755, CWE-824Listed

Affected products and fixed versions 8 rows

ProductAffected versionsFixed version / actionCVE
PHP 8.2earlier than 8.2.358.2.35 and laterCVE-2026-109618
PHP 8.3earlier than 8.3.368.3.36 and laterCVE-2026-109618
PHP 8.4earlier than 8.4.278.4.27 and laterCVE-2026-109618
PHP 8.5earlier than 8.5.128.5.12 and laterCVE-2026-109618
PHP 8.2earlier than 8.2.358.2.35 and laterCVE-2026-109619
PHP 8.3earlier than 8.3.368.3.36 and laterCVE-2026-109619
PHP 8.4earlier than 8.4.278.4.27 and laterCVE-2026-109619
PHP 8.5earlier than 8.5.128.5.12 and laterCVE-2026-109619

The vendor's advisory is the authority on affected and fixed versions. If a cell says “See the vendor advisory”, check it there.

Frequently asked questions

Are these vulnerabilities known to be exploited?

Yes. CISA added both CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog on 2026-10-26. The catalog lists known ransomware use as Unknown for each; it does not identify an attacker or explain the exploitation method.

Does the same PHP update address both vulnerabilities?

Yes. Both vulnerabilities share the same corrected release boundaries: PHP 8.2 at 8.2.35 and later, PHP 8.3 at 8.3.36 and later, PHP 8.4 at 8.4.27 and later, and PHP 8.5 at 8.5.12 and later.

Does a working application mean the server is safe?

No. These flaws involve internal memory handling under specific conditions, so ordinary requests can succeed on an affected runtime. Confirm the PHP release actually serving the application and follow the update steps in the vendor's advisory.

References

How this page is made: versions and CVE IDs come from the vendor advisory table; CVSS scores and weakness types from NVD; exploitation status only from CISA KEV. The explainer is written with AI from those facts and published only after an automated check matches every version, CVE, score and command against the sources. Commands are limited to ones in official documentation. Always follow the vendor's advisory. Read in Korean.

More security advisories