Critical PHP RCE fixes and Kafka security update

01

Item one — PHP web request runtimes: patch two critical paths to remote code execution

Item one — PHP web request runtimes: patch two critical paths to remote code execution. PHP is the server-side runtime that processes requests for many web applications. It may run behind PHP-FPM, inside Apache through mod_php, or through other web-serving setups such as php-cgi, FrankenPHP, and LiteSpeed. The PHP team’s October 23 release notice describes two critical vulnerabilities and urges users to update immediately. That is the publication date; the available evidence does not give a date for when exploitation began or establish that these flaws have been exploited in the wild.

The first flaw, CVE-2026-109618, involves out-of-memory handling. If memory exhaustion interrupts a request while PHP’s internal request data is only partly initialized, cleanup can treat invalid data as valid and corrupt memory. The second, CVE-2026-109619, is a use-after-free: a worker can retain a reference to request-owned state after that memory has been released, and a later request handled by that worker may use the stale reference before initialization resets it. In either case, specially crafted HTTP requests can potentially turn the memory error into remote code execution, meaning an unauthenticated network attacker could run code with the privileges of the PHP service. The actual reach beyond that process depends on the service account, host, and accessible credentials or services; the sources do not establish compromise of any particular deployment.

The upstream fixed releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12; earlier versions in those release lines are affected. PHP calls mod_php the highest-risk configuration and CERT/CC says a demonstrated exploit can trigger before application code runs. That makes ordinary application-level request checks a poor basis for ruling out exposure in that setup. Start with the web-service and container inventory, not only application dependency files: identify the PHP runtime actually serving requests, how it is connected to the web server, and whether it is network reachable.

For Linux distributions and long-term-support vendors, upstream version strings are not the whole answer: PHP says vendors received patches in advance and may backport fixes. Compare the installed package and vendor advisory with the running runtime; don’t label an older-looking package vulnerable or fixed from its version number alone. PHP 8.1 and older no longer receive updates from the PHP project, though vendors may provide backports; the PHP team also published limited source backports for PHP 7.4, 8.0, and 8.1. Confirm the exact supported vendor fix or plan an upgrade.

Patching is the complete fix. If that cannot happen immediately, PHP and CERT/CC describe temporary measures that reduce particular attack paths, not safety guarantees. For the out-of-memory flaw, the advice includes setting `memory_limit=-1` administratively so applications cannot override it, reducing `post_max_size` and setting upload limits appropriately, and enforcing request limits at a web server or proxy. The guidance warns against `RLIMIT_AS` and `RLIMIT_DATA`, which can themselves cause the allocation failure involved in the vulnerable path. For the stale-state flaw, disable `session.upload_progress.enabled` in configuration applied before request parsing, then restart every worker; on PHP 8.5, disabling fatal-error backtraces also blocks a confirmed path. These controls are narrower than a patch, so track them as interim exposure reduction, not closure.

For the practitioner handoff: record runtime, deployment mode, reachability, package source, and the evidence used to establish the patched build. After updating, verify the process actually serving requests and restart workers as required; a changed package on disk is not proof that old workers have exited. CERT/CC also recommends monitoring for unusual PHP process behavior or unexpected memory allocation patterns. Those are investigation leads, not guaranteed indicators, and the sources provide no finding that a clean alert history rules out prior exploitation. If you find suspicious process activity or cannot establish the running build, preserve available host and service evidence and escalate through your incident process.

02

Item two — Red Hat Streams for Apache Kafka: validate the 3.2.2 security replacement

Item two — Red Hat Streams for Apache Kafka: validate the 3.2.2 security replacement. Kafka provides a high-throughput data backbone that lets applications and services exchange event streams. Red Hat’s Streams distribution packages Kafka alongside supporting components, including operators and libraries. Red Hat issued its 3.2.2 advisory on October 21 as a replacement for 3.2.1, with security fixes, bug fixes, and enhancements. Its advisory labels the update’s overall security impact Moderate; it does not report active exploitation or give a count of affected deployments.

This is a bundle of distinct fixes, not one Kafka-broker flaw. The advisory lists issues in Cruise Control and the Console Operator, among others. Examples include an authentication bypass affecting Cruise Control administrative endpoints, risks involving Kafka client properties and service-account token exposure, and cross-namespace KafkaUser secret exposure. It also lists fixes in Netty, Jackson, Go, and other bundled dependencies, including vulnerabilities that can affect request handling, information exposure, or availability. These consequences are conditional on the affected component being present and the relevant code path, configuration, or attacker access being applicable; the advisory does not establish that every Streams installation exposes every listed path.

The direct scope identified by this source is Red Hat Streams for Apache Kafka 3.2.1, for which 3.2.2 is the replacement update. Don’t turn the long CVE and component list into a claim about all Apache Kafka distributions: this is Red Hat’s product advisory, and applicability depends on its packaged build and your deployment. Identify Streams installations and their deployed version through your package, operator, and cluster records, then compare the exact product and installed build with Red Hat’s advisory. If your inventory identifies another Kafka distribution, use that vendor’s own applicability guidance rather than assuming this erratum applies.

Why update? A component-level bug in a distributed application platform can matter even when the core broker itself is not the vulnerable component: operators and supporting libraries can hold credentials, administer resources, or process network and application input. Depending on the particular flaw and deployment conditions, the potential consequence could include administrative access, access to secrets, or service disruption. The advisory describes potential behavior; it does not show that any of those outcomes occurred in your environment.

For the practitioner response, assign an owner to confirm product and version, assess the vendor advisory’s listed fixes against your build, and schedule the 3.2.2 replacement update under your normal operational process. Verify the running distribution after rollout, including the deployed operator or workload where applicable, rather than relying only on a repository or desired-state declaration. If the affected build has been exposed to relevant networks or credentials, review available authentication, API, and cluster audit records for unusual administrative access or secret access; the supplied advisory does not give a specific detection rule or prove that a quiet log review excludes prior activity. Record which components and logs were actually checked, because a clean result is only as informative as the coverage.