Default PHP upload progress flaws can enable unauthenticated RCE

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Upwind's blog post: Two PHP memory-corruption flaws in session upload progress handling can lead to unauthenticated remote code execution on default configurations.

Why it matters: PHP remains deeply embedded in internet-facing applications, so a flaw in a default request path quickly becomes a fleet-wide exposure and patch-priority issue for platform, app, and hosting teams.

By the numbers:

• PHP has released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix both critical flaws.

Context

PHP session upload progress is a request-handling feature that tracks multipart upload state while a file transfer is in flight. When that state is mishandled, the result is not just a crash risk but a path to code execution in the web runtime that many applications inherit by default.

The governance gap is simple: organisations often inventory application code but not the runtime features and deployment modes that make a default PHP build exploitable. In shared hosting, control panels, and bundled PHP stacks, that omission turns a language-level defect into an estate-wide exposure.

Key questions

Q: What should teams do first when PHP upload progress is exploited?

A: The first step is to contain the exposed runtime, disable upload-progress handling if it is not required, and move traffic away from the affected PHP instance. Teams should then confirm whether the worker crashed, whether the supported branch is patched, and whether any internet-facing endpoint still runs an affected version.

Q: Why does a PHP use-after-free become remote code execution?

A: A PHP use-after-free can become remote code execution when an attacker triggers a freed object or buffer and then shapes the heap so the stale pointer is reused as attacker-controlled data or a function pointer. The usual failure mode is memory corruption in the Zend engine or an extension, which can redirect control flow without a sandbox, memory protection, or object lifetime checks.

Q: How do multipart parser quirks affect exploit detection?

A: Multipart parser quirks affect exploit detection by changing how boundaries, headers, line endings, and nested parts are normalised before inspection. If a WAF, proxy, or IDS parses the body differently from the application, an exploit payload can be split, reordered, or hidden in a part that the security control does not reconstruct the same way.

Q: What is the safest way to govern PHP runtime features in production?

A: The safest way to govern PHP runtime features in production is to minimise enabled modules, disable dangerous functions, and keep php.ini settings identical across web and CLI environments. Use configuration baselines, change control, and file integrity checks so the runtime configuration matches the approved security posture, especially for file access, process execution, and deserialisation settings.

Technical breakdown

How the upload-progress path becomes memory corruption

The flaw sits in PHP’s session upload progress callback, where request-state pointers are cached while multipart form data is processed. A later request can trigger re-reading and HashTable updates that destroy the underlying structure, leaving stale pointers behind. That is a classic use-after-free pattern: memory is freed, then later reused while code still believes it is valid. The exploit path matters because it runs in a common request flow, not an obscure extension path, so a stock configuration can be enough for exposure. See the PHP and WordPress Security Guide.

Practical implication: Treat request-path features as attack surface and disable upload-progress handling where it is not operationally required.

Why the exploit depends on heap control and build-specific offsets

After the free, an attacker needs to reclaim the same memory with controlled structures so the dangling pointer resolves into function-call metadata. That is why the exploit chain is not just corruption, but controlled corruption: the attacker must win a timing race and match offsets that differ by PHP build. When the offset is wrong, the worker usually crashes; when it is right, the call can be redirected toward arbitrary command execution. This is why reliable detection should watch both malformed upload-progress requests and the crash pattern that follows. See the Memory Corruption Vulnerabilities Guide.

Practical implication: Prioritise versions and deployments where the worker crash pattern is observable, because that often marks attempted exploitation.

Why default php.ini settings matter for exposed web stacks

The vulnerability is especially dangerous because the relevant session upload-progress feature is enabled by default in common PHP builds. That means exposure is not limited to specially configured applications; it extends to web stacks that simply inherit the runtime defaults. In practice, the attack surface follows the deployment model: php-fpm behind a reverse proxy, mod_php, control panels, and bundled distributions all need to be checked separately because each may expose different combinations of versions, handlers, and mitigations.

Practical implication: Inventory every PHP runtime and disable the feature at the configuration layer wherever patching is delayed.

Threat narrative

Attacker objective: The attacker wants arbitrary command execution on an exposed PHP worker, ideally without authentication and with enough reliability to run payloads on internet-facing services.

1. Entry occurs through a multipart POST that reaches the session upload-progress path in a default PHP deployment.
2. Credential access is not required; instead, the attacker abuses stale memory after a use-after-free to place controlled function metadata at the reclaimed address.
3. Escalation happens when the dangling pointer is driven into function dispatch and the worker follows attacker-influenced control flow.
4. Impact is remote code execution as the PHP process user, with worker crashes serving as a common failed-exploit signal.

Breaches seen in the wild

• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

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

Default runtime features create governance debt: The core issue is not just a bug in PHP, but the assumption that default runtime settings are safe until an application team explicitly changes them. In web estates with shared hosting, control panels, or bundled stacks, that assumption fails because the runtime itself becomes the attack surface. The practical lesson is that application governance has to include runtime feature governance, not just package patching.

Use-after-free in request handling is a control-plane problem: The dangerous part of this flaw is that it sits inside a normal request path, where state is created, freed, and later reused across requests. That makes it a governance issue for memory corruption vulnerabilities as well as an exploitability issue for exposed web services. If the platform cannot prove that the runtime is not carrying stale request state, the worker is already in an unsafe condition.

Patch urgency is driven by exposure, not just severity: CVSS alone understates the operational decision because the exploit path is reachable on default configurations and can be present across large PHP estates. The real risk lens is exposure plus ubiquity, especially for internet-facing applications that process file uploads. Practitioners should treat internet reachability and upload handling as the priority triage variables, not the version string in isolation.

Detection must model both exploit attempt and worker failure: Simple signature checks miss this class of attack because PHP’s multipart parser accepts malformed header variants and the exploit can be shaped to evade naïve field matching. A better governance model correlates upload-progress request patterns with abrupt 5xx responses or worker exits. That shifts detection from string matching to behavioural evidence, which is the right control posture for exploitable runtime memory bugs.

What this signals

Runtime attack surface management: This flaw shows why organisations need a runtime inventory that goes beyond package names and version numbers. The real exposure sits in enabled features, request paths, handler types, and deployment wrappers, so patch programs should be tied to runtime configuration drift rather than release notes alone.

Upload-path exploitation creates a distinct detection pattern: When a file-upload feature can be abused for code execution, the signal often appears first as a malformed multipart request followed by a worker crash or 5xx burst. That is a useful operational marker for teams that need to distinguish probing from successful exploit attempts.

Feature disablement is a valid control, not a workaround: In cases like this, turning off optional request features is a legitimate risk-reduction control because the vulnerable path is part of the feature itself. That matters for exposed PHP estates where patching lags behind disclosure and internet reachability amplifies the blast radius.

For practitioners

• Disable upload-progress handling where it is unnecessary Set session.upload_progress.enabled=0 in php.ini, .user.ini, or .htaccess on every exposed PHP runtime that does not need the feature.
• Patch supported PHP branches immediately Move production systems to the fixed versions for the supported branches and treat older supported installs as emergency maintenance until they are upgraded.
• Inventory every PHP runtime and handler Map php-fpm, php-cgi, mod_php, control-panel deployments, Windows bundles, and application-bundled PHP so no exposed instance is missed.
• Hunt for exploit-shaped multipart requests Look for POST traffic containing the upload-progress field, including malformed or folded header variants, and correlate it with sudden 5xx responses from PHP workers.
• Isolate end-of-life PHP from internet exposure Remove or segment PHP 8.1 and older from public-facing paths because unsupported branches will not receive official fixes for these flaws.

Key takeaways

• PHP’s upload-progress handling turns a default request feature into a remote code execution path when memory corruption is reachable from the network.
• The article’s evidence shows that supported branches received emergency fixes, while older PHP versions remain a persistent exposure for exposed web stacks.
• Disabling session.upload_progress and patching supported builds are the decisive controls, because detection alone cannot close a use-after-free path.

Related NHI Mgmt Group resources: PHP2Shell · PHP and WordPress Security Guide · Vulnerability Management Guide · Memory Corruption Vulnerabilities Guide

Key terms

• PHP2Shell: PHP2Shell is the name given to two critical use-after-free flaws in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, published in October 2026. They let an unauthenticated attacker run arbitrary code on servers running vulnerable PHP versions, with Apache mod_php seen as the highest-risk setup. Both are confirmed as exploited in the wild.
• Use-after-free: A use-after-free occurs when code continues to read or write memory after it has already been released. In kernel networking paths, this often becomes a security issue because stale pointers can expose secrets, corrupt control flow, or crash the system under the right timing conditions.
• Memory Corruption: Memory corruption is a software failure where data in memory is overwritten, misplaced, or read incorrectly, causing crashes, unexpected behavior, or security exposure. In security terms, it often enables code execution, privilege abuse, or data leakage when an application mishandles buffers, pointers, or object lifetimes.
• Multipart Upload Request: An HTTP request format commonly used when a browser or client sends files to a web application. Security teams care about it because attackers also use multipart requests to deliver malicious uploads or probe weak endpoints. Inspection and filtering of these requests can help detect abuse and reduce exposure.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, secrets management, and workload identity through the industry's only accredited NHI security programme. It helps practitioners connect runtime exposure to the identity and access controls their programmes already manage.