PHP flaws enter CISA’s exploited-vulnerability list: check when fixes took effect

A vulnerability is a weakness in a program; a patch changes the program to fix it. KEV inclusion is an operational signal that evidence of exploitation exists, beyond a description of a possible weakness. The catalog does not disclose every attack method or affected organization.

The two flaws involve mishandling memory or internal state left by an earlier request. If attacker-influenced requests reach an affected path, code can run with the PHP server process’s privileges. Reachability depends on configuration and processing paths. Out-of-memory handling flaw · Stale internal-state flaw

Consider a fictional site at hosting provider A running vulnerable PHP. If an attacker’s web request reaches the conditions that trigger a flaw, commands the site operator did not intend could run with PHP’s permissions. Files those permissions allow it to read or change can face disclosure or tampering, and the site may stop working. This illustrates possible harm from remote code execution; it does not imply control over every file or account on every server.

PHP performs server-side work for sites such as WordPress. A worker is a running unit that handles requests. Downloading a package does not establish application if existing workers still run the old program.

The diagram connects records needed to establish patch application. It does not show any provider or site’s current completion status.

%% Evidence of patch application · roles of the PHP project and operators
flowchart TD
  A["Project: release fix"] --> B["Supplier: provide package"]
  B --> C["Operator: apply to web PHP"]
  C --> D["Record version and time"]

These were the first official fixed releases for the two CVEs. For later releases or supplier backports, check the distribution’s evidence that both fixes are included. Official PHP ChangeLog

A backport brings a fix into an existing package branch. Identical displayed version numbers can hide different package revisions, so examine the supplier’s fix history and the running web environment together. Updating WordPress or its plugins does not replace the server’s PHP package. Plan the replacement with the operator: secure a backup, check theme and plugin compatibility in a test environment, and verify login and key features after application. WordPress guidance on server PHP updates

Applying a fix helps block later attacks through the same weakness. Investigating what happened before that requires historical operating records. CISA advises prioritizing internet-facing systems and looking for suspicious behavior such as PHP processes spawning shells or downloading tools.

Connect the period when the site was exposed to the internet with when fixed web PHP actually began serving requests. The reference point below is verified application at that site, rather than a release announcement or package download. Each period shows the records to examine.

A clean log does not cover paths or periods that were never collected. The PHP advisory also warns against inferring safety from the absence of logged errors. Suspicious signs call for preserving records and agreeing an investigation scope with the security team or hosting support.