PHP RCE flaws expose runtime memory and API keys

At a glance

What this is: This is a security advisory on two critical PHP vulnerabilities that can lead to unauthenticated remote code execution and, in some cases, memory disclosure of credentials and API keys.

Why it matters: It matters because IAM and NHI teams need to treat exposed PHP runtimes as a credential-risk issue as well as an application vulnerability, especially where tokens and API keys may be resident in process memory.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.

Context

PHP runtime exposure is a control problem, not just a patching problem. If the serving process can be reached before application logic runs, then conventional application hardening does not stop exploitation at the point that matters most. This is a runtime governance issue for teams that own web platforms, hosting, and identity-bearing secrets.

The article also shows why PHP incidents belong in identity conversations: memory disclosure can surface passwords, tokens, and API keys, turning a web vulnerability into credential exposure. In practice, that makes runtime inventory, ownership, and reachability more important than simply knowing whether a package exists. That is typical of modern internet-facing PHP estates.

Treat API key management as part of remediation, not an adjacent task.

Key questions

Q: What should teams do first when a PHP runtime is exposed to unauthenticated RCE?

A: First, identify which PHP workers are actually serving public or business-critical traffic, because installed packages do not prove exposure. Then patch the serving runtime, restart the affected workers, and only use temporary network restrictions as a short-term bridge while you verify that old instances are gone.

Q: Why does a PHP engine flaw create credential risk as well as server compromise?

A: Because the PHP process may hold passwords, tokens and API keys in memory at the moment exploitation or disclosure occurs. Once those secrets are exposed, the attacker can pivot into other systems even if the original web application is later patched. That is why credential review belongs in containment.

Q: What breaks when teams rely on CMS patching but leave the PHP runtime exposed?

A: The assumption that application-layer hardening is enough breaks down. These flaws operate in the engine before application code runs, so a secure CMS does not protect a vulnerable runtime. If the runtime is reachable, the vulnerable process remains the control failure.

Q: Should organisations use WAF rules or temporary access restrictions instead of patching PHP?

A: No. Temporary controls can reduce exposure to specific request paths, but they do not remove the vulnerability in the engine. They are useful only as a bridge while you patch, restart affected workers, and confirm that every exposed instance is remediated.

Technical breakdown

Why the PHP serving runtime matters more than the application layer

The vulnerability sits in the PHP engine, which means the execution context itself is the issue. If a deployment uses mod_php, PHP-FPM, php-cgi, FrankenPHP, or LiteSpeed, the attack surface depends on how requests are handed to the runtime and whether the vulnerable process is exposed before the application receives control. That is why a secure CMS or hardened application code does not remove the risk. Practical verification has to answer where PHP is actually serving traffic, not just where the package is installed.

Practical implication: Validate the live serving runtime and exposure path before assuming any web application is protected.

How memory corruption and stale state create unauthenticated RCE

The first flaw exploits out-of-memory corruption. When PHP exhausts memory while request data is partially initialised, cleanup can operate on invalid state and create a code execution path. The second flaw relies on stale global state, where a worker retains references to freed memory and later requests can consume that stale data. These are process-lifecycle failures, not application-authentication failures. The important architectural point is that worker reuse, request parsing, and memory handling can become exploitable even when no login or valid session exists.

Practical implication: Prioritise fixes for worker-based runtimes where memory reuse and request lifecycle behaviour can be abused.

Why process memory disclosure changes the incident scope

Wiz showed that sensitive PHP process memory can disclose passwords, tokens, and API keys. That means exploitation does not need to stop at code execution. The attacker may gain credentials that extend the compromise into other systems, services, or cloud control planes. For identity teams, this is the critical bridge: a web runtime flaw can become an NHI exposure event if long-lived secrets or cached tokens sit in memory. The response therefore has to include both patching and credential review. Read the Ultimate Guide to NHIs: What are Non-Human Identities.

Practical implication: Assume exposed PHP workers may have leaked secrets and rotate affected credentials immediately after containment.

Threat narrative

Attacker objective: Gain unauthenticated code execution on exposed PHP systems and extract sensitive runtime secrets for broader compromise.

1. Entry occurs through an externally reachable PHP runtime where the vulnerable engine processes requests before application controls can intervene.
2. Credential and memory exposure follow when the process handles malformed or specially crafted requests that trigger corruption or stale-state disclosure.
3. Escalation to unauthenticated remote code execution becomes possible, and in some cases the attacker can harvest passwords, tokens, or API keys from process memory.
4. Impact includes server compromise, exposed credentials, and potential downstream access to connected applications or cloud services.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime exposure has become the real control boundary for PHP security: the article makes clear that package presence is not the same as reachable risk. The serving workload, not the inventory entry, determines whether exploitation is possible. For practitioners, this shifts governance from software cataloguing to live runtime ownership and reachability.

This is a credential exposure problem as much as a code execution problem: when PHP worker memory can reveal passwords, tokens, and API keys, the incident crosses into NHI governance. Secrets sitting inside application processes become part of the blast radius, which means API key management is directly relevant to response planning. Practitioners should treat runtime memory as a potential secret storage surface.

Standing trust in web application hardening is insufficient when the engine itself is vulnerable: secure code, a patched CMS, or a front-door login page does not protect pre-application execution paths. That failure mode is especially important for public services and business-critical workloads. The practitioner lesson is to govern the runtime before the application stack.

PHP worker reuse creates a durable failure mode that defenders often underestimate: stale global state and cleanup behaviour can turn one request into a later compromise opportunity. That means remediation is not just a binary patch decision but a question of worker lifecycle, restart discipline, and exposure validation. Teams should align patching with runtime restart and secret review.

Memory disclosure widens the incident from a host problem to an identity-system problem: once tokens or keys leave process memory, the attacker may pivot beyond the original server into cloud, SaaS, or internal services. This is the point where identity governance and infrastructure response converge. Practitioners should assume credential review is part of containment, not an optional follow-up.

From our research library:

• DeepSeek alone generated 113,000 new exposed API keys in 2025, illustrating how new AI providers create credential exposure before security guardrails catch up, according to the State of Secrets Sprawl 2026.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: API Key Management Guide

What this signals

Runtime governance is now part of identity governance: when a web engine can leak tokens and API keys, the team responsible for IAM cannot treat application compromise as separate from secret exposure. The practical shift is toward faster secret revocation, shorter-lived credentials, and tighter ownership of where runtime-held secrets can exist.

PHP exposure creates a detectable trust gap between what is installed and what is actually running: inventory alone does not tell you which instance is serving traffic or which instance still holds stale secrets. That gap is where exposure persists, so practitioners need operational verification rather than asset lists.

Secret exposure in process memory is a control boundary failure, not an edge case: once credentials can be recovered from runtime memory, patching and rotation become linked activities. Teams should expect incident response to include both system recovery and identity remediation.

For practitioners

• Prioritise externally reachable PHP runtimes Start with public services and business-critical applications, then trace CDN, WAF, gateway and load-balancer paths to the serving workload so you fix what is actually exposed.
• Patch the serving runtime, not only the application Update packages or rebuild images, replace old replicas, and confirm the runtime version that is handling web traffic rather than the CLI version present on the host.
• Rotate credentials that may have lived in process memory Treat passwords, tokens and API keys as potentially exposed if the vulnerable runtime processed traffic, then revoke or replace them after containment and before restoring full trust.
• Keep temporary controls narrow and explicitly time-bound Use gateway allowlists, VPN access, authenticated proxies, conservative request-size limits and worker restarts only as interim controls while the complete fix is deployed.
• Preserve logs for parallel compromise triage Retain web, proxy, WAF, PHP and endpoint logs, and review suspicious child processes, new executables and unusual outbound connections for evidence of post-exploitation activity.

Key takeaways

• The core risk is not only remote code execution but also exposure of runtime-held passwords, tokens and API keys.
• The article shows that public and business-critical PHP deployments are the highest priority because reachability drives exploitability.
• Patching the serving runtime, restarting affected workers and rotating potentially exposed secrets are the controls that change the outcome.

Related NHI Mgmt Group resources: API Key Management Guide · NHI Authentication Guide · Guide to the Secret Sprawl Challenge · Dropbox Sign breach 2024

Key terms

• Runtime exposure management: A security approach that prioritises what is actually exploitable in live environments rather than treating every finding as equally urgent. It combines runtime context, asset criticality, and control enforcement so teams can focus on exposure that changes production risk.
• Memory Disclosure Vulnerability: A memory disclosure vulnerability allows an attacker to read data that should remain inside process memory. In practice, this can expose credentials, session material, or application data when input handling fails and the program returns sensitive bytes instead of rejecting the request cleanly.
• Stale global state: A condition where a worker process retains references or data from a previous request after that data should no longer exist. In PHP and similar environments, stale state can create cross-request security failures and enable disclosure or execution paths that should not exist.
• Serving runtime: The component actually processing live web requests, such as PHP-FPM, mod_php or another web-facing execution layer. The serving runtime is the control point that matters for exploitability, because it may differ from the version seen in administrative or command-line checks.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management and identity lifecycle control. It helps practitioners connect runtime exposure to the identity controls that contain it.