PHP Security Update: Patch First, Then Review Secrets and Access

On 21 October 2026, PHP released 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix CVE-2026-109618 and CVE-2026-109619, critical vulnerabilities that can allow unauthenticated remote code execution. The official announcement identifies web-serving installations as at risk, including PHP-FPM and Apache mod_php. Updating is the complete fix; temporary mitigations are not equivalent.

A vulnerable installation is not proof of compromise. Treat patching, investigation, and credential recovery as related tasks, with decisions based on your environment and evidence.

Confirm what actually serves requests

Inventory public websites, internal services, containers, and hosting accounts that run PHP. Confirm the version and patch status of the runtime handling web requests; a command-line version alone may describe a different installation.

For managed hosting, ask the operator to confirm the applied package, affected service, and restart or rollout. Distribution vendors may backport fixes, so obtain their patch confirmation rather than judging only the visible upstream version. Use the PHP team's advisories to check scope with the operator. Avoid publishing a diagnostic page that exposes server configuration.

Contain exposure and restore a trusted environment

Coordinate the update promptly with the hosting or operations team. Restrict exposure or isolate affected systems where the incident assessment requires it, while preserving relevant evidence. Do not delay urgent containment just to finish collecting logs.

Review the exposure window, web and system logs, unexpected files or processes, and relevant provider audit events. Missing alerts or clean-looking logs do not prove the host was untouched.

If compromise is established or reasonably suspected, follow your incident process to rebuild or restore from a trusted source. Patching does not remove an attacker's persistence. Do not use an untrusted host or device to generate, receive, or install replacement secrets.

Assess credentials before rotating them

List credentials the affected process could access: application configuration, environment variables, deployment tokens, database credentials, and provider API keys. Determine their permissions, scope, and possible exposure. The announcement alone does not show that every credential in your organization leaked.

For potentially exposed credentials, coordinate replacement and revocation at the issuing provider from a trusted administrator device. Install replacements in the trusted rebuilt environment and verify legitimate integrations. Choose the sequence according to active abuse, provider capabilities, and service dependencies; do not promise uninterrupted service or leave an exposed key active indefinitely for convenience.

Review sessions and recovery access as appropriate, and document who owns each change. Never put raw secrets into the incident ticket or log. OWASP

Close emergency access when the work ends

Give responders individual, narrowly scoped accounts with an agreed end time. Review temporary roles, sessions, deployment access, and shared handoff links after recovery. Remove retained access that is no longer necessary, and confirm the results at the relevant service rather than relying on a calendar reminder alone.

Keep three different controls separate

Control	What it changes	What it does not do
Handoff-link expiration	Later access through that link	Revoke the provider credential
Provider-key revocation	Whether that key is accepted by the provider	Erase saved copies or repair a compromised host
Deleting a message or note	The item's availability in that system	Recall downloads, screenshots, or copied text

Use a temporary handoff only after trust is restored

If your process permits it, create a password-protected memo from a trusted system for the minimum information a verified recipient needs. Send its password separately and use expiration or access limits where your plan supports them. Do not place wallet recovery phrases or private keys in the handoff.

LOCK.PUB is a limited handoff tool: it cannot patch PHP, repair infected devices, revoke a provider key, or recall copies. It does not replace your secret manager, identity controls, or incident response.

Frequently asked questions

Does installing the PHP update finish the investigation?

No. It addresses the vulnerability, while evidence and exposure determine the investigation, recovery, and credential actions still needed.

Can expiring the memo disable the API key it contained?

No. Revoke or replace that key at its provider. A copied credential remains separate from the link that delivered it.