PHP hat gerade zwei kritische CVEs bekommen. Neleto musste nie patchen.

Am Dienstag, dem 20. Oktober, hat das PHP-Sicherheitsteam ein kritisches Security-Release angekündigt, bevor irgendwelche Details veröffentlicht waren. Das macht es nur, wenn es ernst ist. Zwei Schwachstellen, beide mit CVSS 9,2 bewertet, der Patch ist für heute, den 21. Oktober, um 14:00 UTC angesetzt. CERT-Bund hat die Lage mit 9,8 (kritisch) bewertet. CERT-EU ging noch weiter: Die Fehler könnten zu Remote Code Execution führen, und sie betreffen jede PHP-Version seit 5.0.

Wenn du WordPress, Laravel, Drupal oder eine der zig Millionen anderen PHP-Websites betreibst, ist spätestens dieser letzte Satz ein Alarmsignal. Patche jetzt, oder nimm deine internetzugänglichen Anwendungen offline, bis du patchen kannst.

Was die CVEs sind (bisher)

Die zwei Kennungen lauten CVE-2026-109618 und CVE-2026-109619. Zum Zeitpunkt dieses Artikels sind keine technischen Details veröffentlicht. Das PHP-Team behält sich vor, das Release früher auszuliefern, "sobald Details zu einer der Schwachstellen öffentlich werden oder Hinweise auf aktive Ausnutzung auftauchen".

Genau dieser Zusatz ist beunruhigend, denn er heißt: Der Fix läuft womöglich gerade mit Angreifern um die Wette. Ohne öffentliche Details gibt es noch nichts zu bewerten. Es gibt nur eine Deadline.

Warum Neleto nie in der Gefahrenzone stand

Auf Neletos Anfragepfad gibt es keinen PHP-Interpreter.

Das Backend ist in Rust geschrieben, basiert auf axum und spricht über sqlx mit Postgres. Seiten rendert unsere Handlebars-Engine, und Caddy sitzt als Gateway davor. Das Admin-Panel ist eine Vue-3-SPA. Nichts davon ist PHP, also gibt es auf dem Auslieferungspfad keinen Interpreter, in dem diese CVEs greifen könnten.

Ein Bug im PHP-Interpreter kann dich nicht treffen, wenn du nie einen lädst. Für genau diese CVE haben wir nichts geplant. Sie geht uns einfach nichts an, weil wir uns für Rust entschieden haben, wie in diesem Artikel über Rust als Backend beschrieben.

Jede Runtime kann verrotten

Das Problem dieser Woche betrifft nicht nur PHP. Es betrifft jede Sprache, die eine Runtime mitliefert.

Eine interpretierte Sprache bringt ihren Interpreter überallhin mit, auf jeden Server, hinter jede Anwendung. Dieser Interpreter ist ein großes gemeinsam genutztes Programm, einmal vom Sprachteam kompiliert und von jeder Anwendung übernommen, die darauf läuft. Ein Bug darin betrifft jede App auf jedem Rechner mit dieser Version, ganz egal, wie sorgfältig die Entwickler der Anwendung waren. Wer dein CMS entwickelt hat, hat die verwundbare Zeile nicht geschrieben, sondern sie mit der Sprache geerbt.

PHP steht damit nicht allein. Ruby, Python, Node.js und die JVM bringen alle eine Runtime mit, alle hatten schon Runtime-CVEs, und bei allen werden weitere kommen. Die Runtime ist eine große Codebasis, die sich alle Apps darüber teilen, und meist ist sie älter als diese Apps. Hat sie einen Bug, zahlt jede App dafür, ob sie will oder nicht.

Warum kompilierte Sprachen hier prinzipiell besser sind

Ein kompiliertes Backend steckt seinen Code in ein eigenes Binary. Zur Laufzeit sitzt kein Interpreter zwischen Anfrage und Code, also gibt es auch keine Interpreter-Angriffsfläche, die es erben könnte. Die Art von Bug, die PHP diese Woche getroffen hat, ein Fehler in einer geteilten Runtime unter allen Apps, kommt in einem kompilierten Backend nicht vor.

Für diese Art von Schwachstelle sind kompilierte Sprachen deshalb prinzipiell besser: keine Runtime, keine Runtime-Bugs.

"Kompiliert" heißt allerdings nicht "sicher". C und C++ sind kompiliert und trotzdem berüchtigt für Buffer Overflows und Use-after-free-Bugs. Ohne Interpreter fällt eine Angriffsfläche weg, eine andere bleibt. Statt der Bugs des Runtime-Teams hast du dann die Bugs, die die Entwickler der Anwendung selbst schreiben.

Rust geht noch einen Schritt weiter. Der Borrow Checker lehnt eine ganze Klasse von Memory-Safety-Bugs schon beim Kompilieren ab. Viele der Bugs, die C und C++ so gefährlich machen, kompilieren in Rust also gar nicht erst. Für diese Art von Problem ergibt sich folgende Reihenfolge:

1. Bugs in interpretierten Runtimes, das Problem von PHP diese Woche.
2. Memory-Bugs in kompilierten, aber unsicheren Sprachen, das Problem von C und C++.
3. Rust, wo der Compiler einen großen Teil von beidem abfängt, bevor es ausgeliefert wird.

Ein weiterer Grund, warum wir Rust gewählt haben

Als wir uns für die Sprache entschieden haben, haben wir das als Performance- und Kostenentscheidung begründet. Beide Gründe gelten nach wie vor, die Zahlen stehen im Benchmark-Artikel. Diese Woche hat uns aber an einen Vorteil erinnert, den wir unterschätzt hatten: Mit einem kompilierten Backend patchen wir unseren Code, nicht den Interpreter von jemand anderem.

Eine PHP-CVE trifft Millionen von Servern auf einmal. Alle haben dasselbe Upgrade-Fenster und spielen einen Patch ein, den sie nicht geschrieben haben und nicht vollständig prüfen können. Ein Bug in Neleto steckt in Code, der uns gehört, und der Compiler hat sich schon vor dem Release mit uns darüber gestritten. Wenn der nächste kritische Bug auftaucht, beheben wir ihn selbst, statt darauf zu warten, dass jemand einen jahrzehntealten Interpreter flickt, von dem wir abhängen.

Wogegen Neleto nicht immun ist

Neleto ist nicht gegen alles immun, und wer dir etwas anderes erzählt, will dir etwas verkaufen. Das Admin-Frontend ist TypeScript und läuft in einer JavaScript-Runtime, nur eben im Browser statt auf dem Server. Und jeder Server hängt an Systembibliotheken, allen voran OpenSSL. Eine kompilierte Sprache verkleinert die Angriffsfläche, aber sie bringt sie nicht auf null.

Was für den Auslieferungspfad wegfällt, ist das Szenario dieser Woche: ein einziger Fehler in einem geteilten Interpreter, der Millionen von Apps gleichzeitig gefährdet. Wenn doch ein Bug in Neleto auftaucht, steckt er in Code, den wir selbst lesen und prüfen können, nicht in einer Runtime, die wir aus dem Jahr 2004 geerbt haben.

Was das für dich bedeutet

Wenn du heute PHP betreibst: Das Release ist draußen, also patche. CERT-EU war da deutlich. Erfasse deine PHP-Systeme und aktualisiere, sobald gefixte Versionen verfügbar sind, oder trenne internetzugängliche Anwendungen vom öffentlichen Netz, bis du das kannst.

Wenn du gerade ein CMS für die nächsten Jahre auswählst, stell eine Frage, die die meisten Vergleichsartikel auslassen: In welcher Sprache ist das Backend geschrieben, und bringt es eine Runtime mit? Der Interpreter gehört zu deiner Angriffsfläche, ob du ihn geschrieben hast oder nicht, und diese Woche hat gezeigt, was das kostet, wenn er kaputtgeht.

Quellen

• Ankündigung des PHP-Sicherheitsteams, 20. Oktober 2026
• CERT-Bund, WID-SEC-2026-4055: "PHP: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff"
• CERT-EU, Security Advisory 2026-018: "Critical Vulnerabilities in PHP"

Schnelle Websites. Einfache Inhalte. Agentenbereit.

Kostenlos starten auf neleto.io, einem CMS, dessen Backend die Runtime nicht mit der Hälfte des Webs teilt.