Am 21. Oktober 2026 veröffentlichte das PHP-Sicherheitsteam ein außerplanmäßiges Update. Zwei kritische Schwachstellen — CVE-2026-109618 und CVE-2026-109619 — stecken im PHP-Interpreter selbst, der Laufzeit, auf der rund 40 % des Webs basiert. Beide ermöglichen unauthentifizierte Remote Code Execution (RCE) mit einem CVSS-v4.0-Score von 9,2. Korrekturen sind in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 enthalten; Millionen von Servern bleiben jedoch ungepatch. Sicherheitsforscher berichten, dass Ausnutzungsversuche gegen WordPress-Seiten innerhalb von Stunden nach der Veröffentlichung des Proof-of-Concept begannen. 1 2
Kurz vor dieser PHP-Krise, im September 2026, nahm die CISA CVE-2026-87902 im WordPress-Kern in ihren Katalog bekannter ausgenutzter Schwachstellen auf. 3 4 Diese Remote File Inclusion-Schwachstelle, die WordPress 4.7.0–7.1.1 betrifft, bewertet ebenfalls mit CVSS 9,2; aktive Ausnutzung begann wenige Stunden nach dem Patch. Darüber hinaus wurde eine CVSS-10.0-Schwachstelle im Bricksforge-Plugin (Oktober 2026) nahezu sofort von Angreifern eingesetzt. 5
All dies wirft eine einzige Frage auf: Wie sicher ist die Serversoftware selbst, unabhängig von der Sprache, die sie ausführt?
Die Ursache von PHP-Schwachstellen: Die Interpreter-Schicht
CVE-2026-109618 und CVE-2026-109619 nutzen zwei verschiedene Szenarien aus, in denen PHP seine internen Datenstrukturen für die Anfrageverarbeitung nur teilweise initialisiert oder zuvor freigegebenen Speicher erneut verwendet. Im Kern beider Schwachstellen liegen subtile Speicherverwaltungsfehler in einem in C geschriebenen Interpreter.
Das Design von PHP ist für diese Art von Risiken strukturell offen. Jede HTTP-Anfrage startet den PHP-Interpreter, der den Quellcode der Anwendung einliest, kompiliert und ausführt. Diese mehrschichtige Architektur verdoppelt die Angriffsfläche: Fehler im Anwendungscode (WordPress, Plugins) und Fehler im Interpreter-Kern sind gleichermaßen nutzbare Einfallstore. In der Krise vom Oktober 2026 wurde ein Fehler nicht im WordPress-Code, sondern in PHP selbst gefunden — und jede WordPress-Seite war betroffen. 6
Die Sicherheitsbegründung für die Entwicklung von FFS in C++
FFS basiert bewusst auf einem anderen Modell als PHPs Interpreter-Ansatz.
Keine Interpreter-Schicht. FFS ist eine einzelne ausführbare Datei, in C++23 geschrieben, die nativ unter Linux läuft. Wenn eine HTTP-Anfrage eintrifft, wird kein PHP-, Python- oder Ruby-Interpreter gestartet und kein Quellcode gelesen. Der laufende Code ist zur Kompilierzeit erzeugter Maschinencode, verifiziert durch das Typsystem. Es gibt keinen Pfad, über den Schwachstellen auf Interpreter-Ebene wie CVE-2026-109618 und CVE-2026-109619 FFS erreichen könnten.
Speichersicherheit zur Kompilierzeit. Use-after-free- und teilweise initialisierte Pufferfehler in PHP treten zur Laufzeit auf. FFS verwendet moderne C++-Semantiken — RAII, Smart Pointer, Move Semantics — um diese Fehlerklasse weitgehend zur Kompilierzeit zu eliminieren. Objektlebenszeiten werden vom Compiler verfolgt; Speicher wird deterministisch freigegeben, wenn er den Gültigkeitsbereich verlässt.
Komponenten-Isolation begrenzt den Schaden. Jede Seite wird als unabhängige .so-Shared-Library geladen. Selbst wenn eine Komponente fehlerhaft wäre, bliebe der Kern-Serverprozess unberührt. Bei WordPress hingegen läuft eine Plugin-Schwachstelle im gleichen Laufzeitkontext wie die gesamte Anwendung.
Eine Abhängigkeitskette, eine Angriffsfläche. WordPress hängt von einem Ökosystem aus über 55.000 Plugins und zahllosen PHP-Bibliotheken ab. FFS's Laufzeitabhängigkeiten werden in einem einzigen Manifest erfasst; jede Abhängigkeit ist SHA-verifiziert paketiert.
Echtwelt-Nachweis: ~300 Angriffssonden täglich auf fedem.eu
Über theoretische Sicherheitsbewertungen hinaus erlebt fedem.eu täglich echten Angriffsverkehr. Logs zeigen konsistent rund 300 eindeutige IPs, die automatisierte Scans und Ausnutzungsversuche starten. Die häufigsten Sonden:
/wp-admin,/wp-login,/wp-config.php— Scanner, die auf WordPress-Schwachstellen abzielen- Jede
.php-Dateianfrage — Versuche, einen PHP-Interpreter zu erreichen oder Remote File Inclusion auszulösen /phpmyadmin,/pma— Erkundung von Datenbankverwaltungs-Panelseval-stdin.php,phpunit— PHPUnit-RCE-Exploits/.env,/.git/config,private.key— Versuche zur Credential-Exfiltration- JNDI-Injektion (
${jndi:...}) — Nachwirkungen von Log4Shell ../Path Traversal und/etc/passwd-Sonden — Dateisystem-Aufklärung
Jeder dieser Angriffsvektoren ist in einem FFS-Deployment bedeutungslos: Kein PHP-Interpreter läuft auf dem Server, kein WordPress, kein Datenbankverwaltungs-Panel, keine .php-Dateien. Scanner wissen das nicht und senden trotzdem in Sekunden Hunderte von Sonden.
FFS Guard: Beim ersten Request blockieren
Das eingebaute Guard-Modul von FFS reagiert nicht nur einzeln auf Bedrohungen; es analysiert das Verhalten und setzt die IP auf die Blacklist.
Pfad- und Musteranalyse
Guard arbeitet mit zwei Regelschichten:
Verbotene Pfade (banned-paths.txt) — umfasst Pfade, die in FFS nie existieren: WordPress, Joomla, Drupal, phpMyAdmin, /cgi-bin, /admin, Git/SVN-Metadaten-Verzeichnisse und Linux-Systemverzeichnisse. Eine Anfrage, die einen dieser Pfade trifft, erhält sofort ein HTTP 404 zurück, bevor eine Wt-Session erstellt wird; der Greylisting-Zähler wird erhöht.
Musteranalyse (banned-patterns.txt) — eine Regex-Zweischicht, die Pfad und Query-String nach URL-Dekodierung untersucht. Jede .php-Anfrage, eval-stdin, JNDI-${...}-Muster, Path-Traversal-Sequenzen (../) und sensible Dateinamen (.env, id_rsa, .git-credentials) werden erkannt. Ein Treffer erhöht den Greylist-Zähler; bei Überschreitung der Schwelle wird die IP automatisch auf die Blacklist gesetzt.
Honeypot-Mechanismus
Eines der stärksten Features von Guard sind seine Honeypot-Pfade: Gefälschte Pfade, die beim Server registriert sind, aber auf keiner Seite verlinkt, in keiner Sitemap aufgeführt und nirgendwo referenziert werden. Kein legitimer Besucher oder wohlverhaltener Bot kann sie entdecken. Eine IP, die einen dieser Pfade aufruft, wird sofort und dauerhaft auf die Blacklist gesetzt — ohne Greylist-Schwelle, was ein eindeutiger Beweis für automatisiertes Scanning ist.
Abgestufte Reaktion
Sobald eine IP die Greylist-Schwelle überschreitet, wird sie automatisch auf die Blacklist gesetzt. Bestimmte Signale — ein Honeypot-Treffer, spezifische kritische Muster — lösen sofortige Promotion aus. Die gesamte Entscheidung ist durch einen Whitelist-Filter geschützt, der seine Regeln vor dem Serverstart lädt: Eine IP auf der Whitelist kann niemals auf die Blacklist fallen.
PHP vs. C++: Die Zahlen
| Kriterium | PHP / WordPress | FFS (C++) |
|---|---|---|
| Interpreter-Schicht | Vorhanden — bei jeder Anfrage | Keine |
| Oktober 2026 PHP RCE (CVE-2026-109618/19) | Direkt betroffen | Nicht betroffen |
| CVE-2026-87902 (WordPress RCE) | Direkt betroffen | Nicht betroffen |
| Abhängigkeitsfläche | 55.000+ Plugin-Ökosystem | Einzelnes, SHA-verifiziertes Manifest |
| Speicherverwaltung | Laufzeit-GC, use-after-free-Risiko | RAII, Lebenszeit-Tracking zur Kompilierzeit |
| Angriffserkennung | Abhängig von Drittanbieter-Plugin | Eingebautes Guard-Modul |
| HTTP-Schicht-Blockierung | Keine | HTTP 404 vor Öffnung der Wt-Session |
Fazit
Die PHP/WordPress-Community befindet sich erneut in einem Notfall-Patch-Zyklus. Diesmal liegt das Problem nicht im Anwendungscode, sondern in der Laufzeit selbst; Ausnutzungsversuche laufen seit September weiter, auch während Patches eingespielt werden.
FFS ist nicht Teil dieser Diskussion. Da der Server keinen PHP-Interpreter ausführt, liegen PHP-Schwachstellen außerhalb des Anwendungsbereichs; da kein WordPress-Plugin-Ökosystem vorhanden ist, können keine Angriffsketten wie CVE-2026-87902 konstruiert werden. Sicherheit ist nicht an ein Drittanbieter-Plugin delegiert — sie ist in den Kern eingebaut.
fedem.eu's ~300 tägliche Angriffs-IPs sind kein Problem; sie sind ein Maß für Guards Gesundheit. Diese Zahlen würden auf einem System, das auf einem Open-Source-PHP-Interpreter und einem 55.000-Plugin-Ökosystem basiert, eine sehr andere Bedeutung haben.
Um über architekturbasierte Sicherheit und FFS zu sprechen, nehmen Sie Kontakt auf.
Quellen
- 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 ↩
