Ein Leser, der sich um gut vierzig Kundeninstallationen kümmert, hat mir gestern geschrieben: Das neue WordPress-Advisory listet so viele Vorbedingungen auf, dass er versucht war, es unter später abzulegen. Ich verstehe den Reflex. Ich halte ihn trotzdem für falsch. Patche heute auf 7.1.2, das dauert Minuten. Die Lehre, die du behalten solltest, ist größer: Dieser Bug wurde nur gefährlich wegen Dateien und Flags, die die meisten von uns nie ausgewählt und kein einziges Mal geprüft haben.

php.ini
; Mitigation while you roll out 7.1.2; updating WordPress is the real fix.
register_argc_argv = Off

Zuerst die nüchterne Version. WordPress 7.1.2 ist am 22. September 2026 erschienen und schließt CVE-2026-87902, bewertet mit 9.2 Critical nach CVSS 4.0. Die Schwachstelle steckt in der Template-Auflösung rund um get_page_template(): Unter den richtigen Bedingungen kann ein nicht authentifizierter Besucher WordPress dazu bringen, eine lokale PHP-Datei außerhalb des Theme-Verzeichnisses einzubinden, ein Lehrbuchfall von CWE-98. Das Advisory ist GHSA-7hp8-65ch-5whp, und der Fix wurde bis hinunter auf den 4.7-Branch zurückportiert, es gibt also für so ziemlich jede Installation, für die du dich schämst, ein Security-Release.

Jetzt der interessante Teil, die Bedingungen. Damit die bösartige Einbindung überhaupt erreichbar ist, braucht das aktive Theme ein Verzeichnis auf oberster Ebene, dessen Name mit page- beginnt, etwas wie page-templates. Das Advisory nennt Twenty Twelve, Twenty Fourteen, Neve, Hestia und Sydney als Themes, bei denen dieses Layout existiert, was keine Anschuldigung ist, sondern nur Geografie. Und um aus einer Datei-Einbindung eine Code-Ausführung zu machen, braucht der Angreifer eine brauchbare PHP-Datei, die schon auf der Platte liegt. Das Beispiel im Advisory ist pearcmd.php, das zum Gadget wird, sobald register_argc_argv eingeschaltet ist, eine Kombination, die es ausdrücklich für das offizielle PHP-Docker-Image und für Standard-cPanel-Setups mit PHP-Versionen unter 8.5 markiert.

Lies dir diese Liste noch einmal durch. Da ist ein PEAR-Kommandozeilen-Helfer, der im Base-Image mitkommt, egal ob du in diesem Jahrzehnt jemals pear getippt hast. Da ist register_argc_argv, ein Ini-Schalter, der aus der CGI-Ära übrig geblieben ist. Selbst die Theme-Bedingung ist nur eine Angewohnheit bei der Verzeichnisbenennung, älter als der Block-Editor. Keines davon ist für sich genommen ein Bug. Zusammen bilden sie die Startbahn, auf der ein Ausrutscher bei der Template-Auflösung zur Remote Code Execution abhebt. WordPress hat die verwundbare Zeile geschrieben, aber der umgebende Stack hat die Komplizen geliefert.

Das faire Gegenargument lautet, dass genau diese Schichtung die meisten Seiten geschützt hat. Drei Bedingungen müssen zusammenpassen, eine veraltete Installation ist also nicht automatisch nur einen präparierten Request von der Übernahme entfernt, und das Advisory sagt genau das. Stimmt, und ich bin froh, dass die Berichterstattung dazu größtenteils ruhig geblieben ist. Trotzdem werde ich mich hier nicht entspannen: Jede einzelne dieser Bedingungen lässt sich billig aus der Ferne und in großem Maßstab abklopfen. Die Theme-Struktur sickert über Asset-URLs durch, Hosting-Fingerabdrücke verraten cPanel, und Angreifer skripten solche Checks an einem Nachmittag, während sich Verteidiger einreden, dass die Sterne auf ihren Kisten schon nicht in einer Reihe stehen werden. Enge Vorbedingungen lesen sich schön in einem Advisory und furchtbar in einem Incident-Report.

Die Reihenfolge ist also absichtlich langweilig. Update zuerst, aus dem Dashboard oder mit dem passenden Release für den Branch, den du fährst. Dann, wo du sowieso schon auf der Kiste bist, prüf register_argc_argv und schalt es aus, sofern du keinen echten Grund hast, es zu behalten, denn allein das durchtrennt das pearcmd.php-Glied in der Kette. Und wenn eine Seite mit einer betroffenen Version, einem passenden Theme und Hosting-Setup exponiert war, verbring zehn Minuten damit, das Access-Log nach merkwürdigen Template-Requests zu greppen und wp-content gegen eine bekannt saubere Kopie zu diffen, bevor du das Ticket schließt.

Der langfristigere Fix ist, dein Baseline-Image wie eine Abhängigkeit zu behandeln. Dass das Advisory bei PHP 8.5 eine Grenze zieht, ist ein Hinweis, dass neuere Plattform-Defaults einen Teil dieses Pfads bereits schließen. Wenn du auf dem offiziellen Docker-Image baust, kostet es dich zwei Zeilen in der Production-Stage, PEAR-Tooling zu entfernen, das du nie aufrufst. Die Go-Leute weisen gerne darauf hin, dass ihr Deploy-Artefakt eine einzige Binary ist, in der sonst nichts drin steckt, und gut, das haben sie sich verdient, aber nichts hindert einen PHP-Container daran, fast genauso schlank zu sein. Wir müssen nur akzeptieren, dass Software, die wir nie absichtlich installiert haben, trotzdem als Angriffsfläche zählt.

Was mich zu der Frage bringt, die ich unter dieser Kolumne wirklich beantwortet haben will. Wenn du eine Produktionskiste oder ein Image prüfst, gehst du dann auf die Jagd nach ausführbaren Überresten wie pearcmd.php, oder endet dein Review bei deinem eigenen Code und der composer.lock? Und wenn die ehrliche Antwort die zweite ist: Was bräuchte es, Tooling, Zeit oder einen Schrecken wie diesen, um diese Linie zu verschieben?