Research collected from outside sources and what this site derives from them; every fact links to a saved copy of its source Research or story?
Risks / R01 Remote code execution on internet-facing PHP servers / R01-1
R01-1: Default Apache mod_php installations exploited before application code runs
Because the flaw is reached over HTTP before any application code runs, every mod_php site is exposed whatever application it serves, resulting in compromise without any application weakness.
Rating 15 high · Likelihood 3 Possible · Impact 5 Severe · Kind Security · Acceptance not recorded
Basis. Confirmed mechanism on the most common shared-hosting setup; no confirmed compromise yet.
The path
Who carries it
One risk, assigned to every stakeholder that carries part of it, with the part each plays.
| Stakeholder | Part | Why | Its register |
|---|---|---|---|
| Shared and self-service hosting | owner | mod_php is the shared-hosting default; the host controls the runtime. | 1 risk |
| Website owner | bearer | Has a site on the host and no control of its PHP. | 2 risks |
| Platform engineers and developers | treater | Find and upgrade every mod_php runtime they run. | 4 risks |
What it arises from
- The allocator's longjmp-based bailout on out-of-memory. An out-of-memory error unwinds by longjmp and can leave request memory in a state that cleanup later reads.
The evidence
| Claim | Status | Fact-check | Sources |
|---|---|---|---|
| Unauthenticated RCE over HTTP against Apache mod_php with default settings, before any application code runs | confirmed | A6 Established●●●●●● | PHP oss-security php.net |
| Both bugs are in the C engine, not in PHP code: the allocator's longjmp-based bailout on out-of-memory, and request globals that survive a failed request | confirmed | A6 Established●●●●●● | php/php-src, read from a clone PHP PHP |
Treatments
| Treatment | Status | Where |
|---|---|---|
| Update PHP; the configuration measures reduce exposure and do not make an installation safe | in place | If you run PHP: the steps, in order, with their sources |
The standards that govern it
| Framework | Control | What it asks | Family |
|---|---|---|---|
| ISO/IEC 27001 | A.8.8 | Management of technical vulnerabilities | Management-system standards |
| CIS Controls | 7.4 | Perform automated application patch management | Frameworks and control catalogues |
| Cyber Essentials | SUM | Security update management: high and critical updates within 14 days of release; unsupported software removed | Frameworks and control catalogues |
| PCI DSS | 6.3.3 | Critical security patches are installed within one month of release | Management-system standards |
The stories that tell it
- Why can't every version of PHP just be patched?
- Where php2shell stands: many sites dark, millions of attempts, no confirmed breach (through Remote code execution on internet-facing PHP servers)
- Patch at the speed of Metasploit: where php2shell sits on the weaponisation ladder, and the attacks that come second and third (through Remote code execution on internet-facing PHP servers)
On this site: Affected systems: versions, deployments, applications, inventory · If you run PHP: the steps, in order, with their sources