Critical PHP security update: two infrastructures, one important lesson

Situation

Some engineering days result in a new feature, a redesigned page or a visible performance improvement. On other days, success means that users barely notice anything at all. October 22 was one of those days. On October 21, 2026, the PHP project disclosed fixes for two critical vulnerabilities in the runtime itself, rather than in a particular website or plugin. Because both the Columbia Games commerce environment and infrastructure supporting KampányMűvek use PHP in different ways, we audited the affected layers and carried out focused security maintenance. We wanted to establish which versions actually ran in production, which security fixes were present, what needed updating, and whether service availability could be preserved. This was not an excuse for an unrelated platform migration or a sweeping rewrite.

Approach

We treated the three environments independently: the CCM v2 PHP API, the separate WordPress Apache container, and a shared Ubuntu 24.04 LTS web host. We checked actual package and runtime versions against the PHP project's advisories and Canonical's security notice. Where an upstream runtime update was required, we changed only the affected container; where Ubuntu had already backported the fix, we verified the installed package and its installation history. Backups and rollback preparation preceded the changes. Afterwards we checked Apache configuration, application health endpoints, database connectivity, container logs and HTTP responses. The advisory links below lead directly to the official vulnerability reports and Ubuntu notice.

1. Two CVEs that could not be ignored

CVE-2026-109618 concerns memory corruption triggered while handling out-of-memory conditions. CVE-2026-109619 concerns stale internal state that may reference memory already freed between requests. Both received critical 9.2 scores under CVSS v4.0. In certain vulnerable configurations, an attacker may achieve remote code execution without authenticating first. That does not mean every PHP site can automatically be compromised: exploitability depends on the actual server configuration and conditions. However, the possible consequences are severe. The official PHP advisory pays particular attention to Apache mod_php, where exploitation may occur before an application's own PHP code executes. Secure business logic cannot repair a flaw in the interpreter underneath it. The remediation must therefore reach the affected runtime itself, not just application-level checks.

2. Why this matters to ordinary visitors

A visitor sees a catalog, a login screen or a contact form, not the runtime executing in the background. The server code processes requests, queries databases, verifies permissions and handles business data. If the runtime is vulnerable, confidentiality, integrity and availability can all be at risk, depending on the configuration and the process privileges. A security patch does not introduce a new button or a more impressive interface. It closes a known avenue of attack. The most useful outcome is often invisible: the site continues to behave as it did before, but with a materially lower known risk. For users, nothing needs to change. For the people responsible for production, there is a substantial verification job behind that apparently uneventful experience.

3. Columbia Games: upgrading the CCM v2 API

The CCM v2 commerce platform handles catalog data, customer flows, digital products, retailer-specific business rules and orders. A change to its PHP runtime therefore needs a tightly controlled scope. We upgraded the production API runtime to the patched PHP 8.3.36 release without bundling in unrelated commerce functionality. After deployment, we verified the application health endpoint and database connectivity. The /api/health route returned a successful response, and all three checked database connections were available. These checks are evidence that critical application paths remained healthy; they are not a claim that every purchasing scenario received fresh manual end-to-end testing. The scope of this release was to remove a known PHP security exposure while retaining existing behavior.

4. Columbia Games WordPress: its own container, its own checks

The legacy WordPress website runs in a separate Docker environment using Apache with PHP. Its previous runtime was PHP 8.4.21. Because the advisory explicitly highlights mod_php configurations, we treated this environment as a distinct production task. We prepared backups of the database and uploaded assets, verified the backups and established a rollback option before replacing the application container. The new image uses PHP 8.4.27, and the MariaDB database was left unchanged. Post-update validation included a successful apache2ctl configuration check, php -v confirming 8.4.27, inspection of recent container logs without new PHP fatal errors, and successful internal and public HTTP responses. A successful image build would not have been enough: the result needed to be checked at runtime and through the actual service endpoints.

5. KampányMűvek: an older-looking version can still be patched

The Ubuntu 24.04.5 LTS server supporting KampányMűvek presented a different situation. Canonical's fixed package is 8.3.6-0ubuntu0.24.04.13, which can look older than upstream PHP 8.3.36 until you understand distribution backports. Ubuntu may apply security fixes to its maintained package without moving its upstream base-version string to the latest PHP release. The full distribution package version and the official Canonical advisory, USN-8948-1, are therefore the relevant evidence. Installation records showed that the fixed PHP security package had already been installed by unattended security maintenance on October 20. On October 22, our job was to verify that state and complete additional hardening, not to pretend the PHP package first became secure that day.

6. Turning off unnecessary PHP handling

Updating software is essential, but so is limiting what services are allowed to do. We reviewed 1,067 files on the shared web host and found no PHP source files in the examined web assets. Those sites did not require general-purpose Apache PHP execution. We therefore removed the global Apache-to-PHP-FPM handler and tightened direct HTTP access to PHP source files. This is an example of reducing the attack surface rather than merely reacting to a single CVE. It does not guarantee immunity against future vulnerabilities; it simply removes unnecessary capabilities from the exposed configuration. A useful operational rule is to disable what a service does not actually need and to verify that the remaining applications continue to work.

7. Additional packages and deliberate change boundaries

The maintenance also included updates to 14 additional APT packages on the Ubuntu host. We reviewed the planned package operations before applying them; the update did not require removing packages or rebooting the entire server. We intentionally kept Ubuntu 24.04.5 LTS instead of combining the urgent vulnerability response with a major operating-system upgrade. A full distribution upgrade requires a different compatibility analysis, test plan and rollback strategy. The objective today was to address the defined security risk through the smallest justified set of changes, rather than chase every newest upstream version at once.

8. A deployment is not complete until it is verified

A green terminal message or a single HTTP 200 status code is useful, but insufficient as proof of a healthy production release. For Columbia Games, we checked runtime versions, Apache configuration, container logs, API health and database connectivity. On the shared web host, we compared the HTTP behavior of seven HTTPS endpoints against their known prior states; all seven preserved their expected status behavior, including intentional redirects. The checked configurations and service responses were satisfactory. These are targeted smoke and operational checks, not unrestricted penetration testing or a promise that every business interaction was re-tested. Recoverable backups and a rollback plan were also part of limiting risk if an unexpected regression emerged.

9. Invisible work is still engineering work

No new button appeared today. No product page was redesigned, and no new commerce feature was shipped. Instead, two Columbia Games PHP runtimes were moved to patched releases, Canonical's already installed backport was verified on the Ubuntu infrastructure supporting KampányMűvek, further packages were updated, and unnecessary PHP handling was restricted. The examined production services remained reachable. That may not make an exciting before-and-after screenshot, but it is essential to operating dependable software over time. A production service should not merely work today; it should continue working tomorrow with fewer known weaknesses, clear evidence of what changed, and a realistic path to recovery.

Outcome

The Columbia Games CCM v2 API is running on patched PHP 8.3.36, while its separate WordPress Apache container moved from PHP 8.4.21 to PHP 8.4.27. On the Ubuntu infrastructure also serving KampányMűvek, we verified Canonical's fixed package installed on October 20, updated 14 additional system packages, and tightened unnecessary PHP exposure. The relevant health checks, configuration validation, log review and HTTP smoke tests supported continued operation of the checked services. This is not presented as a comprehensive penetration test or full user acceptance test; the claims are limited to the verified paths and changes.