Fragnesia on KEV: Linux CVE-2026-46300 after PHP2Shell, not instead of it

On 28 Oct 2026, CISA added CVE-2026-46300 to the Known Exploited Vulnerabilities catalog: a Linux kernel missing-initialization bug (CWE-456) in ESP / socket-buffer coalescing — industry nickname Fragnesia. CISA’s KEV text is explicit: it can be chained with PHP2Shell CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root. Forensic triage is flagged under BOD 26-04.

This is not a second write-up of PHP2Shell. PHP gets you the unauthenticated web foothold on vulnerable runtimes. Fragnesia is the local privilege-escalation half that turns “PHP worker” into “root on the box” when the kernel is still vulnerable.

Use your distro advisory / running kernel package for the authoritative fix. Stable trains commonly cited after the May 2026 disclosure window include builds such as 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 — distributions backport; inventory the installed kernel package, not a vibes-based version string.

Snapshot

Secondary reporting (e.g. Dream Security via press) describes custom PHP2Shell + Fragnesia weaponization against internet-facing appliances. Attribute those victim counts to the reporters. Do not paste them as engagement findings.

Why the chain is the finding, not either CVE alone

On authorized mid-engagement work:

• Patching PHP without kernel updates leaves a rooted path open if the foothold returns (or was already used)
• Patching the kernel alone does not close unauthenticated PHP RCE on still-vulnerable interpreters
• “We blocked PHP2Shell at the WAF” does not answer whether Fragnesia already ran under a prior shell

Industry noise says “another Linux KEV.” Engagement state asks: PHP train, kernel package, and whether webshell/root artifacts already exist.

Triage questions

1. In ROE? Linux hosts that run PHP (or where you already hold low-priv code exec) authorized?
2. PHP side closed? Against fixed PHP trains from the PHP2Shell operator notes — 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (verify current vendor)?
3. Kernel side closed? Distro package / running uname -r against the advisory that actually shipped to this host.
4. Already rooted? Unexpected root cron, new SUID, webshells outside the webroot story, kernel module load surprises — IR-shaped if authorized.
5. What do you pause? Do not abandon unfinished AD/web paths because CISA shortened a federal due date.

Operator path

Evidence worth capturing

• Exact PHP version(s) and how PHP is served (mod_php / FPM / cgi) — from the PHP2Shell playbook
• Running kernel package ID (uname -r + distro changelog / CVE mapping)
• Webshell paths, unexpected PHP under webroot, and post-root artifacts only with authorization and evidence
• Timeline: was the host internet-facing while both PHP and kernel were vulnerable?

Client-facing remediations (short)

• Patch PHP and the kernel; either alone is incomplete against the CISA-stated chain
• Temporary module blocks (esp4 / esp6 / rxrpc) appear in some write-ups as stop-gaps — they can break IPsec; treat as emergency only and verify against your distro guidance
• After patch: hunt webshells and root persistence — KEV + forensic-triage flag means patch ≠ proof of cleanliness (BOD-shaped notes)

What not to write

• “Fragnesia is unauthenticated RCE” — it is local LPE; PHP2Shell is the unauth web piece
• Bundling VMware ESX CVE-2026-41709 into the same finding because it shared the 28 Oct alert
• Reciting Dream/press victim counts as your measured compromise
• Completeness claims (“all Linux patched”) without package inventory
• Invented IPsec/ESP exploit steps not in your evidence

Primary sources: CISA KEV alert (28 Oct 2026), NVD CVE-2026-46300, and the CISA PHP2Shell alert. Re-verify fixed kernel packages on your distro before you file.