Back Sploitus Exploit for Improperly Controlled Sequential Memory Allocation in Php
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)
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
