Skip to content
Exploit for Improperly Controlled Sequential Memory Allocation in Php

Exploit for Improperly Controlled Sequential Memory Allocation in Php

Sploitus • October 22, 2026

A public "Am I vulnerable?" page for **PHP2Shell** (CVE-2026-109618 / CVE-2026-109619) by [Securin](

Visitors enter a domain or URL. A small Cloudflare Worker sends one passive `GET /` and returns the `X-Powered-By` header, and the page applies the version rules from the ProjectDiscovery nuclei template [`CVE-2026-109618.yaml`]( Nothing is exploited and nothing is stored.

| Likely vulnerable | Version is in an affected range, or is a dev/alpha/beta/RC build of a fixed release |

| Not affected by version | At or above 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 |

| Can't tell | No header, no PHP version, or a version that was never released (e.g. `PHP/6.0.8`) |

| Outside the advisory's ranges | Older than 5.4 — end-of-life, upgrade anyway |

It is a version check only: OS vendor packages may carry backported fixes, and many servers hide the header.

docs/ GitHub Pages site (static, no build step)

js/php2shell.js version logic — shared by the page and the Worker

js/config.js checker URL (rewritten at deploy from the CHECKER_API_URL variable)

worker/ Cloudflare Worker: GET /check?target=

src/guard.js input normalisation + SSRF guards

test/ node:test unit tests

- http/https on ports 80 and 443 only; no credentials in URLs

- Private, loopback, link-local, CGNAT, metadata and reserved IPs blocked, both as literals and after DNS resolution; IPv6 limited to global unicast, excluding 6to4/Teredo/NAT64

- DNS checks are defence in depth (Workers can't pin `fetch()` to a resolved IP, so rebinding races are possible); the hard boundary is that Worker egress originates from Cloudflare's edge, which cannot reach private networks

- Each redirect hop is re-validated (max 2, as in the template)

- 8 s timeout, response bodies are discarded

- CORS limited to `ALLOWED_ORIGINS`; 10 checks per minute per client IP

- No logging or storage of targets or results

1. **Cloudflare:** create an API token with the *Edit Cloudflare Workers* template.

2. **Repo secrets:** `CLOUDFLARE_API_TOKEN` and `CLOUDFLARE_ACCOUNT_ID`.

3. Run the **Deploy checker Worker** workflow. Note the `*.workers.dev` URL it prints.

4. **Repo variable:** `CHECKER_API_URL` = that URL, then run **Deploy site to GitHub Pages**.

npm run dev:worker #

npm run dev:site # (talks to the local Worker)

Extracted Entities