“It is managed by the cloud provider” sounds reassuring until a security fix reaches the boundary between the platform and the application. Google Cloud’s latest security bulletin is a useful example of that boundary in action: Google has updated managed components and runtime images, but some customer-owned PHP workloads still depend on a rebuild and redeploy.
On October 24, 2026, Google published security bulletin GCP-2026-072 for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which Google says are also known as “PHP2Shell.” The bulletin says fixed PHP releases are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. It also says no fixed release exists for PHP 8.1 or earlier.
The interesting lesson is broader than one PHP release. Cloud responsibility is not a single switch. It is a line that moves depending on whether a service, runtime, container image, operating system, or application dependency is controlled by the provider or by the customer.
The platform may be patched while your application stays unchanged
Google’s security bulletin says the Google Cloud platform itself is not vulnerable to the PHP flaw. The exposure is in customer workloads that run affected PHP versions. That distinction is easy to miss when an application is hosted on a managed service: the provider can secure its own infrastructure without changing the code or image that a customer uploaded.
For a team running a standard managed runtime with automatic updates enabled, the provider may roll out a corrected runtime as part of the service. For a team that builds a container image, pins a PHP package, or carries its own operating system layer, the customer controls more of the update path. The same cloud product can therefore contain workloads with very different maintenance responsibilities.
This is why “the cloud is patched” is not precise enough. The more useful question is: which layer was patched, and which layer is still running from a customer-selected artifact?
What Google says is changing
Google’s October 24 release notes list updated language versions across App Engine and Cloud Run environments. They include PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12, alongside updated versions of Go, Node.js, Java, Python, Ruby, and .NET. The notes repeatedly say that affected resources should be rebuilt and redeployed with updated dependencies.
That wording matters. A running service does not necessarily begin using a new dependency merely because the provider has published a patched version. A deployment may still reference an older container digest, an older buildpack output, or a lockfile that resolves to a vulnerable package. A rebuild creates a new artifact; a redeploy puts that artifact into service.
Google also notes that some App Engine Standard and Cloud Run or Cloud Run functions workloads may be automatically patched when automatic updates are enabled. That does not make every PHP workload equivalent. Automatic runtime updates and customer-controlled images are different operating models, with different expectations for testing, rollout, and verification.
Why container ownership changes the answer
Containers make the responsibility boundary more visible. A provider can secure the host, orchestration layer, and managed control plane, but the application image may still contain its own PHP binary, system libraries, and dependency files. If the image was built before the fixed PHP release became available, it can continue to be deployed repeatedly even after the platform has been updated.
The same pattern applies beyond PHP. A base image can be current while an application layer pins an older library. A runtime can be patched while a build pipeline recreates an outdated artifact. A serverless product can be maintained while a customer’s deployment configuration keeps selecting a previously built image.
For developers, the important capability is not merely “we use a managed service.” It is knowing where the application’s runtime comes from, how it is versioned, and whether a new build actually replaced the old artifact. Those details make the difference between a platform update that is relevant to a workload and one that is only relevant to the provider’s own layer.
The practical signal is in the deployment pipeline
A useful way to understand the update is to trace one request from source code to production. Start with the PHP version declared in the project. Then identify the lockfile, buildpack, base image, package manager, container registry, deployment target, and runtime configuration. The goal is to map the exact path by which a version reaches a live request.
This also reveals the places where teams can accidentally create a false sense of completion. A security scanner may report that a new image is clean while production is still running the previous image. A deployment can succeed while an old revision continues receiving traffic. A runtime dashboard can show a platform version while the application loads a separate PHP binary from its image.
Google’s release notes are therefore more than a list of versions. They are a reminder to connect release information with deployment evidence: build logs, image digests, revision history, runtime metadata, and the traffic path that serves users. Without that connection, an update can be technically available but operationally absent.
What smaller teams should take from this
Small businesses and lean development teams do not need a complex platform program to understand this issue. They need a clear answer to a few ownership questions: who supplies PHP, who builds the image, who selects the deployed revision, and how the live version can be checked after a release?
Those answers are especially important when a hosting provider, managed WordPress service, serverless platform, and custom deployment process are mixed together. The provider may handle one layer while the site owner or developer handles another. The article’s central point is not that managed hosting is unsafe; it is that “managed” must be tied to a specific layer and a specific update mechanism.
The bigger cloud lesson
Cloud platforms reduce infrastructure work, but they do not erase the supply chain between source code and a running application. Current runtime releases, image rebuilds, dependency resolution, and deployment verification remain connected parts of that chain.
The PHP bulletin makes the boundary visible at a moment when the fixed releases are clearly named and Google has documented which environments may receive automatic updates. The durable lesson is to treat every deployment artifact as a time-stamped decision. When a provider announces a fix, the next question should be whether the production artifact was rebuilt from the fixed components and whether the live service is actually using it.
Sources: Google Cloud Security Bulletin GCP-2026-072 and Google Cloud release notes for October 24, 2026.
Editorial note: This article is a general information summary based on the cited public sources. It is not legal, cybersecurity, or compliance advice.
Related Articles
