On 21 October 2026 the PHP security team shipped an out-of-band release. Two critical flaws — CVE-2026-109618 and CVE-2026-109619 — live in the PHP interpreter itself, the runtime that powers roughly 40 % of the web. Both allow unauthenticated remote code execution (RCE) and carry a CVSS v4.0 score of 9.2. Fixes landed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, but millions of servers remain unpatched. Researchers report that exploitation attempts against WordPress sites began within hours of the public proof-of-concept release. 1 2
Shortly before this PHP crisis, in September 2026, CISA added CVE-2026-87902 in WordPress core to its Known Exploited Vulnerabilities catalogue. 3 4 This remote file inclusion flaw, affecting WordPress 4.7.0–7.1.1, also scores CVSS 9.2; active exploitation began within hours of the patch. In addition, a CVSS 10.0 flaw in the Bricksforge plugin (October 2026) was weaponised almost immediately. 5
All of this raises a single question: how secure is the server software itself, independent of the language it runs?
The Root Cause of PHP Vulnerabilities: The Interpreter Layer
CVE-2026-109618 and CVE-2026-109619 exploit two separate scenarios in which PHP leaves its internal request-handling data structures partially initialised, or allows previously freed memory to be used again. At the core of both flaws are subtle memory-management bugs in a C-written interpreter.
PHP's design is structurally open to this class of risk. Every HTTP request launches the PHP interpreter, which reads, compiles, and executes the application's source code. That multi-layer architecture doubles the attack surface: flaws in application code (WordPress, plugins) and flaws in the interpreter core are equally viable entry points. The October 2026 crisis found a bug not in WordPress's code but in PHP itself — and every WordPress site was exposed. 6
The Security Case for Building FFS in C++
FFS is deliberately grounded in a different model than PHP's interpreter approach.
No interpreter layer. FFS is a single executable, written in C++23, running natively on Linux. When an HTTP request arrives, no PHP, Python, or Ruby interpreter is launched and no source code is read. The running code is machine code produced at compile time and verified by the type system. There is no path by which interpreter-layer flaws such as CVE-2026-109618 and CVE-2026-109619 can reach FFS.
Memory safety enforced at compile time. Use-after-free and partially-initialised buffer errors in PHP surface at runtime. FFS uses modern C++ semantics — RAII, smart pointers, move semantics — to eliminate this error class largely at compile time. Object lifetimes are tracked by the compiler; memory is released deterministically when it goes out of scope.
Component isolation limits the blast radius. Each page is loaded independently as a .so shared library. Even if one component contained a flaw, the core server process would remain unaffected. In WordPress, a plugin flaw executes in the same runtime context as the whole application.
One dependency chain, one attack surface. WordPress depends on an ecosystem of more than 55,000 plugins and countless PHP libraries. FFS's runtime dependencies are tracked in a single manifest; every dependency is package-verified with a SHA digest.
Real-World Evidence: ~300 Attack Probes per Day on fedem.eu
Beyond theoretical security assessments, fedem.eu experiences real attack traffic every day. Logs consistently record approximately 300 unique IPs launching automated scans and exploitation attempts. The most frequent probes include:
/wp-admin,/wp-login,/wp-config.php— scanners targeting WordPress vulnerabilities- Any
.phpfile request — attempts to reach a PHP interpreter or trigger remote file inclusion /phpmyadmin,/pma— database management panel discoveryeval-stdin.php,phpunit— PHPUnit RCE exploits/.env,/.git/config,private.key— credential exfiltration attempts- JNDI injection (
${jndi:...}) — residual Log4Shell attacks ../path traversal and/etc/passwdprobes — filesystem reconnaissance
Every one of these attack vectors means nothing in an FFS deployment: no PHP interpreter runs on the server, no WordPress, no database management panel, no .php files. The scanners do not know this and send hundreds of probes in seconds regardless.
FFS Guard: Block at the First Request
FFS's built-in Guard module does not simply respond to threats one by one; it analyses behaviour and places the IP on the blacklist.
Path and Pattern Analysis
Guard operates on two rule layers:
Banned paths (banned-paths.txt) — covers paths that never exist in FFS: WordPress, Joomla, Drupal, phpMyAdmin, /cgi-bin, /admin, Git/SVN metadata directories, and Linux system directories. A request matching any of these receives an HTTP 404 immediately, before a Wt session is ever created; the greylisting counter is incremented.
Pattern analysis (banned-patterns.txt) — a regex second layer that inspects path and query string after URL-decoding. Any .php request, eval-stdin, JNDI ${...} patterns, path traversal sequences (../), and sensitive file names (.env, id_rsa, .git-credentials) all match here. A match increments the greylist counter; once the threshold is crossed, the IP is promoted to the automatic blacklist.
Honeypot Mechanism
One of Guard's most powerful features is its honeypot paths: fake paths registered with the server that are never linked from any page, never listed in any sitemap, and never referenced anywhere. No legitimate visitor or well-behaved bot can discover them. An IP that requests one is promoted to the permanent blacklist instantly, bypassing the greylist threshold entirely — conclusive evidence of automated scanning.
Graduated Response
Once an IP crosses the greylist threshold it is automatically blacklisted. Certain signals — a honeypot hit, specific critical patterns — trigger immediate promotion. The entire decision is protected by a whitelist filter that loads its rules before the server starts: a whitelisted IP can never fall into the blacklist.
The critical property of this design is that attacks are cut off at the HTTP layer, before a Wt session is created. In PHP-based systems, every /wp-admin request launches an interpreter, creates a session, and allocates memory. In FFS, that cost is zero.
PHP vs C++: The Numbers
| Criterion | PHP / WordPress | FFS (C++) |
|---|---|---|
| Interpreter layer | Present — on every request | None |
| October 2026 PHP RCE (CVE-2026-109618/19) | Directly affected | Unaffected |
| CVE-2026-87902 (WordPress RCE) | Directly affected | Unaffected |
| Dependency surface | 55,000+ plugin ecosystem | Single, SHA-verified manifest |
| Memory management | Runtime GC, use-after-free risk | RAII, compile-time lifetime tracking |
| Attack detection | Depends on third-party plugin | Built-in Guard module |
| HTTP-layer blocking | None | HTTP 404 before Wt session opens |
Conclusion
The PHP/WordPress community is once again in an emergency patch cycle. This time the problem is not in application code but in the runtime itself; exploitation attempts have been ongoing since September even as patches are applied.
FFS is not part of this conversation. Because the server runs no PHP interpreter, PHP vulnerabilities are out of scope; because there is no WordPress plugin ecosystem, CVE-2026-87902-style chains cannot be constructed. Security is not delegated to a third-party plugin — it is built into the core.
fedem.eu's ~300 daily attack IPs are not a problem; they are a measurement of Guard's health. Those same numbers would carry a very different meaning on a system built on an open-source PHP interpreter and a 55,000-plugin ecosystem.
To discuss architecture-based security and FFS, get in touch.
References
- OX Security — CVE-2026-109618 & CVE-2026-109619: Two Vulnerabilities Allow Unauthenticated RCE in PHP ↩
- Patchstack — Major security alert: PHP vulnerable to critical RCE, attacks ongoing ↩
- The Hacker News — Attackers Exploit WordPress CVE-2026-87902 Within Hours of Disclosure ↩
- CISA — CISA Adds One Known Exploited Vulnerability to Catalog (2026-09-25) ↩
- The Hacker News — Attackers Exploit CVSS 10.0 Bricksforge WordPress Flaw Enabling Unauthenticated RCE ↩
- Diamatix — Critical PHP Vulnerabilities Affect WordPress and Other Web Applications: CMS Updates Alone Are Not Enough ↩
