Topic starter
11/11/2026 6:02 pm
TL;DR: Two memory-corruption flaws in PHP session upload progress handling can enable unauthenticated remote code execution on default configurations, according to Upwind. PHP workers that process multipart uploads now need patching, feature disablement, and crash-aware detection.
Editorial analysis by NHI Mgmt Group, based on content published by Upwind: “PHP2Shell: Two Critical Unpatched PHP RCEs (CVE-2026-109618 & CVE-2026-109619) – Update”.
By the numbers:
- PHP has released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix both critical flaws.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: PHP’s upload-progress handling turns a default request feature into a remote code execution path when memory corruption is reachable from the network.
Glossary terms: PHP2Shell, Use-after-free, Memory Corruption, Multipart Upload Request
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:07 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Default PHP upload progress flaws can enable unauthenticated RCE