How Pantheon’s Layered Security Response Helps Reduce Risk During Critical PHP Vulnerabilities

Two critical PHP vulnerabilities are prompting some web teams to consider taking their sites offline while patches are deployed. The response illustrates an important security principle: reducing exposure requires multiple controls working together, not a single architectural feature.

KrebsOnSecurity reports that experts say working exploits exist for CVE-2026-109618 and CVE-2026-109619. Pantheon’s public status page reports active mitigation and a staged patch rollout. It does not report fleet-wide completion or confirm exploitation against Pantheon sites.

Our position is straightforward: managed patching, runtime and network mitigations, immutable deployments, and customer-side investigation each address a different part of the risk.

What Immutable Deployments Help, and Where They Stop

Immutable deployments constrain changes to the deployed application code. They help prevent an attacker from turning a runtime exploit into a persistent modification of that deployed codebase.

That is vital defense in depth. It prevents common persistence, cryptomining, and web-shell techniques through the deployed code path, which is the most common avenue for exploit, while preserving a clear distinction between approved deployments and runtime activity.

It is not a guarantee that a compromised site is clean. Immutable deployment controls do not cover every writable surface. Uploads and other writable directories, database content, rogue administrator accounts, injected configuration or scheduled tasks, credentials, and Dev or Multidev environments can all require separate investigation and remediation.

For that reason, a security response cannot stop at “the code is immutable.” Teams must still review relevant logs, recent code and configuration changes, files, database state, credentials, and administrative activity when compromise is suspected. Code rollback alone does not necessarily remove database changes, uploaded files, planted accounts, or other external state.

Patching and Mitigation Are the Frontline Response

The first responsibility is to deploy the vendor’s fixed PHP releases. On Pantheon, the platform-managed rollout is in progress across supported and legacy branches. The Pantheon incident update is the source of truth for rollout progress, current mitigations, and any further customer guidance.

As of October 21, 2026, 20:55 UTC, the status page reports that Pantheon is actively mitigating the vulnerabilities, has deployed runtime configuration changes, and has implemented network-level mitigations while patching progresses. It does not yet state that the rollout is complete across the fleet.

The platform patch itself requires no customer deployment or pantheon.yml change. Customers with custom PHP or self-managed components, or customers seeing suspicious activity, should review logs and recent code changes and contact Pantheon Support. Patching a vulnerable runtime does not, by itself, investigate or remediate a prior compromise.

Customers running PHP versions that have reached End of Sale should also plan to move to a PHP version fully supported by the PHP community, which receives patches faster than those relying on LTS support, which only begins its process when the main vulnerability is disclosed. Teams can review their configured PHP version in the Pantheon documentation.

How the Layers Fit Together

Pantheon’s response combines controls with different jobs:

• Managed PHP security updates address the vulnerable runtime and reduce the operational burden of coordinating a fleet-wide rollout.
• Runtime configuration changes and platform-level network mitigations reduce exposure while patching progresses.
• Immutable deployments help constrain unauthorized changes to deployed application code.
• Controlled deployment workflows improve visibility into code changes and can support rollback of code to a known-good version. They do not, by themselves, revert database records, uploaded files, credentials, or other external state.
• Global CDN and WAF capabilities may provide an additional edge control point where available under a customer’s plan and configuration. These are distinct from the platform-level network mitigations described in the incident update. Customer-configured WAF rules should not be assumed to block these vulnerabilities.

No individual layer is sufficient. Patching removes the vulnerable condition. Runtime and network controls help reduce exposure during the response window. Immutable deployment controls limit one class of persistence. Investigation and recovery address the possibility that an attacker acted before or during patching.

What Customers Should Do Now

Customers should monitor the Pantheon status page for rollout updates and follow any customer-specific guidance from Support. The practical lesson is not that any one platform control makes a site immune to a vulnerability. It is that layered controls can help reduce risk, shorten the path to mitigation, and give security teams more reliable options while the response is underway.

For more on Pantheon’s security and compliance program, visit the Pantheon Trust Center.