PHP project Ships 8.5.12, 8.4.27, 8.3.36 and 8.2.35: A Software Team Checklist for two RCE Fixes

If your organization ships or maintains web software that depends on a PHP runtime, this is a release you should treat as an operational security update rather than a routine version bump. The PHP project has published 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to address two vulnerabilities that could allow unauthenticated remote code execution. The practical point for software owners, IT support teams, and application operators is simple: identify every system that executes PHP web requests, confirm its runtime mode, and move it onto a patched release or a documented backported equivalent.

Release Summary for Software Operations

• Patched lines: 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• Why the update exists: two critical issues involving request handling and cleanup can lead to remote code execution without authentication.
• Exposure rule: any PHP installation that serves web requests is part of the affected surface, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
• Highest-risk configuration: mod_php, because the published information describes a demonstrated path in which an unauthenticated request can activate the issue before application code begins.
• Older-line status: the project update notice covers PHP versions older than 8.1 as no longer receiving project updates, while also providing patches for PHP 7.4, PHP 8.0 and PHP 8.1 for backport work.

For MyTechDailyNews readers who care about daily software updates, the useful conclusion is not the version number alone. The useful conclusion is where the runtime sits, what mode it uses, whether a patched package is available, and how quickly the team can prove the new release is live.

Which Running Modes Are Covered?

The release note is broad on the affected surface. If PHP is used to answer web requests, it should be considered exposed. That includes the common server integration models used in modern web delivery. The table below maps each named configuration to the operational takeaway that can be drawn from the update notice.

Affected PHP web-serving modes and the update response

Configuration	What the release information establishes	Software team action
PHP-FPM	It is an exposed web-serving PHP mode.	Confirm the active FPM runtime version and update to one of the patched PHP releases when the application compatibility check is complete.
Apache with mod_php	The note names Apache and mod_php together as a highest-risk arrangement because a demonstrated unauthenticated request path can occur before application code is executed.	Treat as urgent, patch the runtime, and validate the web front end and PHP module version after the update.
php-cgi	It is explicitly included in the list of exposed web-serving setups.	Update the CGI binary path, then test the request flow that invokes PHP through the web server.
FrankenPHP	The update notice includes FrankenPHP in the affected installation list.	Move the application image or runtime to a patched PHP release and record the change for release governance.
LiteSpeed	LiteSpeed appears in the exposed setup list.	Check the PHP handler used by LiteSpeed and replace the runtime with a patched release where supported.

The two Weakness Patterns in Practical Language

Two distinct failure patterns are described. They are both tied to request processing, which is why they matter to public-facing PHP stacks. One is connected to out-of-memory handling; the other is connected to global state that can remain after the memory behind it has been freed.

CVE-2026-109618 and GHSA-w8hw-w9fx-j79w: request data can be misread after an OOM interruption

The first issue, tracked as CVE-2026-109618 and GHSA-w8hw-w9fx-j79w, is about what can happen when PHP runs out of memory while request data is only partially initialized. The release explanation indicates that cleanup can then treat that invalid request data as if it were valid. For software operators, the important detail is that the failure is not just an application error message. The published impact includes a remote code execution possibility when the condition is reachable through web requests.

CVE-2026-109619 and GHSA-6wmf-4rv5-p3rp: stale state can be reused by a later worker

The second issue, tracked as CVE-2026-109619 and GHSA-6wmf-4rv5-p3rp, concerns internal state owned by a request. The update notice says that state can remain after the memory backing it is freed. A later request handled by the same worker may then use that stale state before normal initialization resets it. This is especially relevant for worker-based environments, because the dangerous state is carried through reuse rather than being created only once at process start.

Step-by-Step Update Workflow

1. Build an inventory of every PHP web runtime in your estate.
2. Record the current version and the serving mode for each entry: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed.
3. Prioritize environments that accept public web traffic and, especially, environments using mod_php because the release notice identifies the highest-risk demonstrated unauthenticated request path there.
4. Select the target release from the patched set: 8.5.12, 8.4.27, 8.3.36 or 8.2.35, using the version line closest to your supported stack.
5. If your environment is based on Linux packages, watch distribution and vendor feeds, because the announcement says Linux distributions and vendors received patches in advance and updated packages should be coming soon.
6. After upgrading, verify the runtime version in the actual request path, not only in a shell on a jump host.
7. Run functional smoke tests for pages, APIs, authentication flows, request handlers, and any component that may encounter memory pressure during request cleanup.
8. Document the change, including whether you applied the official release or a backported patch, and keep the mapping visible to security and operations teams.

What Teams Should Do With 7.4, 8.0 and 8.1

Older PHP lines need a different plan because the project update posture changes. The notice says PHP versions older than 8.1 will not receive updates from the project. It also says patches were provided for PHP 7.4, PHP 8.0 and PHP 8.1 to assist in creating backports. That means an organization running those lines can still get source material for a maintained patch, but the project release path should not be confused with a normal support channel.

A practical rule is: upgrade to a supported patched line when possible; when not possible, apply the provided backport material through a controlled process and document the exception, owner, and review date.

Common Misconceptions

• Myth: only one web server mode is affected. Reality: the notice names PHP-FPM, Apache, mod_php, php-cgi, FrankenPHP and LiteSpeed as exposed web-serving PHP setups.
• Myth: mod_php risk is only theoretical. Reality: the update describes a demonstrated unauthenticated request path before application code is run.
• Myth: old PHP versions are automatically safe because they cannot get an update. Reality: the patch material for PHP 7.4, PHP 8.0 and PHP 8.1 exists for backporting, but teams need a controlled way to apply it.
• Myth: checking the version string once proves the environment is fixed. Reality: in web stacks the serving layer, runtime, and worker pool can differ, so the release path and request path should both be verified.

FAQ

Which PHP releases fix the issues?

The patched releases named by the update are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Does an application have to be vulnerable for the runtime to be exposed?

The release information frames the exposure at the PHP installation level: if PHP serves web requests, it is included in the affected list. The mod_php case is singled out because the demonstrated path can occur before application code runs.

What are the tracked identifiers?

The two reported issues are CVE-2026-109618 with GHSA-w8hw-w9fx-j79w and CVE-2026-109619 with GHSA-6wmf-4rv5-p3rp.

Is there a path for older installations?

Yes, but it is narrower. The notice says updates from the project are not available for PHP versions older than 8.1. Patches were nevertheless provided for PHP 7.4, PHP 8.0 and PHP 8.1 to help create backports.

When will Linux package updates arrive?

The announcement says Linux distributions and vendors received patches in advance, so updated packages should be coming soon.

Action Suggestions

• Make the patched list visible in release notes: 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• Give public-facing PHP web routes the shortest patch queue, especially mod_php environments.
• Keep CVE-2026-109618, GHSA-w8hw-w9fx-j79w, CVE-2026-109619 and GHSA-6wmf-4rv5-p3rp in the change ticket so security reporting can link the runtime upgrade to the published identifiers.
• For Linux hosts, prepare a package update plan because distribution and vendor packages are expected to follow the advance patch notice.
• For PHP 7.4, PHP 8.0 and PHP 8.1 estates, schedule either an upgrade to the patched newer lines or a documented backport review.

Software teams that treat this as a release-management task rather than a version-number task will have a clearer audit trail: the affected modes are named, the identifiers are recorded, the patched releases are selected, and the request-serving path is verified after the update.