WordPress-Server härten: Upgrade-Verzeichnis sperren und PHP sicher konfigurieren

Stellen Sie sich vor, Ihr WordPress-Core-Update läuft gerade automatisch im Hintergrund durch – wie es das jede Woche tut. Niemand schaut hin. Genau in diesem Zeitfenster von wenigen Sekunden entpackt WordPress neue Dateien in ein Unterverzeichnis von wp-content/upgrade/, das von außen erreichbar ist und den WordPress-Installer enthält. Ein nicht angemeldeter Angreifer, der den Pfad kennt oder findet, kann in diesem Moment bis zur Ausführung von PHP-Code gelangen.

Genau das beschreibt CVE-2026-119977, die schwerste Lücke im Sicherheitsrelease WordPress 7.1.4 vom 28. Oktober 2026. Wordfence bewertet sie mit CVSS 8.1 „High". Die Angriffskomplexität ist hoch, das Zeitfenster in Laborbedingungen nur Sekunden lang – trotzdem registrierte Wordfence innerhalb von 21 Stunden nach dem Release mehr als 18.500 Anfragen auf Pfade des zwischengespeicherten Installers (Wordfence-eigene Angabe). Das Update schließt die Lücke. Aber die Konfigurationsschwäche, die das Angriffsszenario erst ermöglicht, bleibt auf ungepatchten und auf frisch aktualisierten Servern gleichermaßen bestehen – sofern niemand sie behebt.

Dieser Artikel zeigt, welche Härtungsmaßnahmen aus den beiden Lücken CVE-2026-119977 und CVE-2026-87902 folgen, wie sie auf Webserver-Ebene umgesetzt werden und warum Firewall und Rechtemanagement das Update nicht ersetzen, aber substanziell ergänzen.

Was die Lücken über den Zustand vieler Server verraten

CVE-2026-119977 existiert, weil der Code, der das temporäre Update-Verzeichnis anlegt, auf WordPress 2.8 zurückgeht – laut Patchstack. Jahrelang war das Staging-Verzeichnis unter wp-content/upgrade/ mit einem vorhersagbaren Namen erreichbar, ohne Index-Schutz, ohne Zugangsbeschränkung. Die Korrektur in 7.1.4 vergibt jetzt zufällige Namen, ergänzt einen Index-Schutz und übernimmt Konfigurationsdaten aus dem Staging-Bereich nicht mehr unsicher.

CVE-2026-87902 – gepatcht in WordPress 7.1.2 vom 22. September 2026, als „kritisch" eingestuft (CVSS v4.0: 9.2) und von der CISA am 25. September 2026 in den KEV-Katalog aufgenommen – nutzte einen anderen strukturellen Schwachpunkt: Die Seitenvorlagen-Auflösung ließ sich dazu bringen, eine lesbare lokale PHP-Datei außerhalb der Theme-Verzeichnisse einzubinden. Das Advisory nennt als Beispiel pearcmd.php bei aktivem register_argc_argv – betroffen laut Advisory das offizielle PHP-Docker-Image und Standard-cPanel-Konfigurationen mit PHP vor 8.5.

Beide Lücken haben eine strukturelle Gemeinsamkeit: Sie setzen voraus, dass der Webserver PHP-Dateien in bestimmten Verzeichnissen aus dem Internet erreichbar macht und ausführt, ohne dass das technisch nötig wäre. Genau dort setzt Härtung an.

wp-content/upgrade/ auf Webserver-Ebene sperren

Das temporäre Update-Verzeichnis braucht zu keinem Zeitpunkt öffentlichen Web- oder PHP-Zugriff. Weder Besucher noch Suchmaschinen haben dort etwas zu suchen. Die naheliegende Maßnahme ist deshalb, den Webzugriff auf wp-content/upgrade/ vollständig zu blockieren – auf Webserver-Ebene, nicht über eine Plugin-Firewall.

Warum das unterscheidet sich: Eine Firewall auf Plugin-Ebene läuft innerhalb von WordPress. Wenn PHP direkt eine Datei unter wp-content/upgrade/ aufruft, ohne den WordPress-Bootstrap zu durchlaufen, greift die Plugin-Firewall nicht. Wordfence selbst weist darauf hin, dass ihre Firewall bei CVE-2026-119977 nur mit „Extended Protection" – dem vorgelagerten Schutz auf Serverebene – wirksam ist, nicht bei der Standard-Plugin-Variante.

Sperrung im Apache-vHost oder in der zentralen .htaccess (im WordPress-Wurzelverzeichnis, nicht im Upgrade-Ordner selbst):

<IfModule mod_rewrite.c>
  RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

Alternativ mit <Directory>-Direktive in der Server- oder vHost-Konfiguration – als allgemeines Muster, keine versionsgebundene Anleitung:

<Directory "/var/www/html/wp-content/upgrade">
  Require all denied
</Directory>

Bei Nginx entspricht das einer location-Direktive, die Anfragen auf das Verzeichnis mit return 403 oder deny all beantwortet.

Wichtig: Die Regel gehört in die Webserver-Konfiguration oder in die .htaccess im Wurzelverzeichnis der WordPress-Installation. Eine .htaccess im Upgrade-Ordner selbst ist keine zuverlässige Lösung, weil das Verzeichnis bei jedem Update neu angelegt und geleert wird – und dabei auch die Datei verschwinden kann.

Verzeichnisauflistung verhindern

Ergänzend sollte sichergestellt sein, dass Verzeichnisauflistung (Directory Listing) für das gesamte WordPress-Verzeichnis deaktiviert ist. Ein offenes Directory Listing in wp-content/upgrade/ hätte einem Angreifer ermöglicht, den vorhersagbaren Pfad des Staging-Unterverzeichnisses selbst zu finden – ohne vorherige Kenntnis. Die Direktive Options -Indexes in Apache oder autoindex off in Nginx gehört zur Grundkonfiguration jedes Webservers, der WordPress ausliefert.

register_argc_argv deaktivieren und PEAR vermeiden

CVE-2026-87902 nennt pearcmd.php als Beispieldatei, die bei aktivem register_argc_argv und lesbarem Pfad zur Codeausführung führen kann. Das Advisory betrifft laut Veröffentlichung das offizielle PHP-Docker-Image und Standard-cPanel-Konfigurationen mit PHP vor 8.5.

register_argc_argv ist eine PHP-Direktive, die bestimmt, ob PHP die Argumente der Kommandozeile ($argc, $argv) in regulären Web-Requests bereitstellt. Für eine WordPress-Website ist diese Funktion unter normalen Umständen nicht erforderlich. Der Standardwert variiert je nach PHP-Build und Konfiguration; auf vielen Shared-Hosting-Umgebungen steht er auf On.

Prüfung und Anpassung:

In der php.ini (oder einer eingebundenen Konfigurationsdatei wie php.ini.d/*.ini) sollte stehen:

register_argc_argv = Off

Der Wert lässt sich auch über phpinfo() prüfen – im Produktivbetrieb sollte phpinfo() allerdings nicht dauerhaft erreichbar sein.

PEAR: Das PHP Extension and Application Repository war in älteren PHP-Installationen standardmäßig enthalten und bringt unter anderem pearcmd.php mit. Moderne PHP-Installationen liefern PEAR nicht mehr im Standard aus, aber auf bestehenden Servern, die über Jahre gewachsen sind, kann es noch vorhanden sein. Ist PEAR nicht aktiv genutzt, sollte es entfernt oder zumindest sichergestellt werden, dass pearcmd.php und vergleichbare Skripte vom Webserver nicht aufgerufen werden können – analog zur Sperrung des Upgrade-Verzeichnisses.

Firewall mit vorgelagertem Schutz – was Plugin-Firewalls können und was nicht

Wordfence hat am 28. Oktober 2026 um 20:30 UTC eine Firewall-Regel für Premium-, Care- und Response-Kunden ausgerollt, rund drei Stunden nach dem WordPress-Release. Nutzer der kostenlosen Version erhalten die Regel erst am 27. November 2026 – vier Wochen später, in denen aktive Abtastversuche bereits liefen.

Das zeigt die strukturelle Schwäche von Plugin-Firewalls: Sie schützen nur Anfragen, die den WordPress-Bootstrap durchlaufen. Wer direkt eine PHP-Datei unter wp-content/upgrade/ aufruft, umgeht diesen Pfad vollständig. Wordfence selbst benennt das: Wirksam ist die Regel nur bei aktivierter „Extended Protection" – dem Modus, in dem Wordfence als mu-plugin oder über eine auto_prepend_file-Konfiguration läuft und damit vor WordPress selbst initialisiert wird.

Die praktische Konsequenz für den Serverbetrieb: Eine vorgelagerte Firewall – sei es eine Web Application Firewall (WAF) auf CDN-Ebene, eine Reverse-Proxy-Konfiguration mit Rate Limiting oder eine Firewall auf Webserver-Ebene – bietet strukturell stärkeren Schutz als ein reines WordPress-Plugin. Die Regeln aus dem vorherigen Abschnitt (Sperrung von wp-content/upgrade/, Deaktivierung von Directory Listing) wirken unabhängig davon, ob WordPress geladen wird.

Eine Plugin-Firewall bleibt trotzdem sinnvoll – für Login-Schutz, Brute-Force-Erkennung, Dateiintegritätsprüfung und die breite Abdeckung bekannter Angriffsmuster. Sie ersetzt den vorgelagerten Schutz nicht, sondern ergänzt ihn.

Zur Einordnung: CVE-2026-119977 steht nicht im KEV-Katalog der CISA (geprüft 03.11.2026, Katalogstand 30.10.2026), und Wordfence benennt keine bestätigten erfolgreichen Angriffe – nur Ausnutzungsversuche. Patchstack hält die Lücke für nicht praktikabel ausnutzbar. Das Angriffsfenster öffnet sich aber bei jedem Update, auch bei unbeaufsichtigten automatischen Updates.

Benutzerrechte minimieren: Mitarbeiter-, Autor- und Redakteurskonten

Mehrere der weiteren 22 in 7.1.4 behobenen Lücken setzen ein angemeldetes Konto mit mindestens Mitarbeiter-Rechten (Contributor), Autor- oder Redakteursrechten voraus – darunter mehrere Stored-XSS-Lücken (Blockbegrenzer, Kategorien-Block, Kommentar-Paginierung, präparierte Benutzernamen, Bild- und Playlist-Block) und eine Berechtigungsschwäche bei Notizen für Rollen mit Kommentar-Moderationsrecht.

Das bedeutet: Ein kompromittiertes Konto mit niedrigen Rechten kann unter Umständen als Sprungbrett dienen. Wordfence und Patchstack empfehlen ausdrücklich, Konten mit Mitarbeiter-Rechten oder höher nach der Lückenmeldung zu überprüfen.

Konkrete Maßnahmen:

• Rechteprinzip der minimalen Vergabe: Wer ausschließlich Inhalte einreicht, braucht die Rolle „Mitarbeiter" (Contributor), nicht „Autor" oder „Redakteur". Wer nur Kommentare moderiert, braucht keinen Redakteur-Account.
• Inaktive Konten deaktivieren oder löschen: Ehemalige Mitarbeiter, Testkonten und Agentur-Zugänge ohne aktive Nutzung sind ein häufig übersehenes Risiko.
• Zwei-Faktor-Authentifizierung für alle privilegierten Konten: Mindestens für Administrator- und Redakteursrollen sollte 2FA erzwungen werden, nicht optional sein.
• Passwort-Richtlinien: Starke, einmalige Passwörter – idealerweise über einen Passwort-Manager verwaltet.
• Anmelde-Protokolle auswerten: Unbekannte Administratorkonten, unerwartete Plugins oder fremde PHP-Dateien unter wp-content/ sind Indikatoren für eine mögliche Kompromittierung.

Ein hypothetisches, aber realistisches Bild aus der Praxis: Eine WordPress-Installation mit zehn Redakteurskonten, von denen drei seit über einem Jahr inaktiv sind und eines noch die Zugangsdaten eines ehemaligen Dienstleisters hat. Keine dieser Schwachstellen ist technisch, keine wird von einem Webserver-Scan erkannt – und keine wird durch das Update auf 7.1.4 automatisch behoben.

Praxisbeispiel: Was Härtung konkret verhindert hätte

Folgendes Szenario ist hypothetisch, aber aus den bekannten Lückenbeschreibungen direkt abgeleitet:

Ein KMU betreibt WordPress auf einem Shared-Hosting-Paket. Automatische Updates sind aktiviert. Am Morgen des 28. Oktober 2026 läuft das Update auf 7.1.4 durch. wp-content/upgrade/ ist ohne Zugangsbeschränkung aus dem Web erreichbar, Directory Listing ist aktiv. Der Server läuft mit einer PHP-Konfiguration, in der register_argc_argv auf On steht; PEAR ist noch installiert, weil das Hosting-Paket seit Jahren unverändert ist.

In den ersten Stunden nach dem Release tasten automatisierte Scanner bekannte Pfade des zwischengespeicherten Installers ab – mehr als 18.500 solcher Anfragen registriert Wordfence in 21 Stunden. Auf einem Server ohne vorgelagerte Zugangsbeschränkung und ohne Webserver-Regel für wp-content/upgrade/ öffnet sich bei jedem zukünftigen Update erneut dasselbe Fenster.

Hätte der Server die in diesem Artikel beschriebenen Maßnahmen umgesetzt gehabt – Sperrung des Upgrade-Verzeichnisses auf Webserver-Ebene, deaktiviertes Directory Listing, register_argc_argv = Off, keine überflüssigen PEAR-Skripte im Web-Zugriff –, wären die Voraussetzungen für eine erfolgreiche Ausnutzung nicht erfüllt gewesen. Das Update bleibt dennoch zwingend: Härtung reduziert die Angriffsfläche, ersetzt aber keine Patches.

Was Härtung leisten kann – und was nicht

Die folgende Tabelle ordnet die beschriebenen Maßnahmen nach ihrer Wirkungsebene und den Grenzen, die jede einzelne hat.

Härtung und Firewall ersetzen das Update nicht. Das ist keine Floskel: CVE-2026-119977 ist in 7.1.4 durch eine Änderung der Core-Logik behoben – zufällige Verzeichnisnamen, Index-Schutz, sichere Übernahme von Konfigurationsdaten. Diese Korrektur ist nicht durch eine Konfigurationsmaßnahme nachzubauen. Das Update muss eingespielt werden; Härtung ist das, was danach (und davor) den nächsten Vorfall schwerer macht.

Wann Härtung professionell begleitet werden sollte

Viele der beschriebenen Maßnahmen sind dokumentiert und für technisch erfahrene Administratoren umsetzbar. Drei Situationen sprechen dafür, externe Unterstützung einzuziehen:

Kein direkter Serverzugriff. Wer WordPress auf einem Managed-Hosting-Paket betreibt, auf dem die Webserver-Konfiguration durch den Hoster verwaltet wird, kann <Directory>-Direktiven nicht selbst setzen. Hier ist eine Abstimmung mit dem Hoster oder ein Wechsel auf eine Umgebung mit mehr Kontrolle nötig.

Mehrere WordPress-Installationen auf einem Server. Was für eine einzelne Installation überschaubar ist, skaliert schlecht. Eine .htaccess-Regel je Installation, unterschiedliche PHP-Versionen, verschiedene Hoster-Accounts – der Überblick geht schnell verloren. Eine zentrale Härtungsstrategie erfordert dann eine Bestandsaufnahme aller Installationen, ihrer PHP-Konfigurationen und ihrer Updatestände.

Keine Gewissheit über den aktuellen Stand. Wer nicht weiß, ob register_argc_argv aktiv ist, ob PEAR auf dem Server liegt, ob Directory Listing deaktiviert ist und welche Konten welche Rechte haben, braucht vor den Maßnahmen eine Analyse. Härtungsmaßnahmen auf unbekannte Ausgangslage aufzusetzen erzeugt ein falsches Sicherheitsgefühl.

SW Business Solutions härtet Webserver, PHP-Konfiguration und WordPress-Installation und dokumentiert jede Maßnahme – damit der Zustand nachvollziehbar bleibt und beim nächsten Sicherheitsrelease nicht wieder von vorne begonnen werden muss. Ob Apache, Nginx oder ein Managed-Hosting-Paket: Der erste Schritt ist eine Bestandsaufnahme der aktuellen Konfiguration.

Eine umfassendere Einordnung aller Lücken in WordPress 7.1.2 und 7.1.4, Handlungsempfehlungen für den Updateprozess und Hinweise für verspätete Patches finden Sie im Überblicksartikel WordPress-Sicherheitslücken 2026: Was Unternehmen nach 7.1.2 und 7.1.4 jetzt prüfen müssen.

Mehr zur dauerhaften Absicherung von WordPress-Installationen im Betrieb zeigt der Artikel WordPress Sicherheit: So schützen Sie Ihre Website zuverlässig.

Checkliste: WordPress-Server härten – was jetzt zu prüfen ist

Diese Liste fasst die Maßnahmen aus diesem Artikel zusammen. Sie ist kein Ersatz für eine vollständige Sicherheitsanalyse, aber ein Ausgangspunkt für die Prüfung der eigenen Konfiguration:

• WordPress auf 7.1.4 (oder den Backport des jeweiligen Zweigs) aktualisiert
• Webzugriff auf wp-content/upgrade/ auf Webserver-Ebene gesperrt (Regel in vHost-Konfiguration oder zentraler .htaccess, nicht im Upgrade-Ordner selbst)
• Directory Listing für das gesamte WordPress-Verzeichnis deaktiviert (Options -Indexes / autoindex off)
• register_argc_argv in der php.ini auf Off gesetzt und geprüft
• PEAR: nicht benötigte Komponenten entfernt oder deren Web-Erreichbarkeit gesperrt
• Vorgelagerte Firewall oder WAF vorhanden und aktiv; Plugin-Firewall ggf. in Extended Protection betrieben
• Alle Benutzerkonten mit Mitarbeiter-Rechten oder höher überprüft; inaktive Konten deaktiviert
• 2FA für Administrator- und Redakteurskonten aktiviert
• Zugriffsprotokoll nach unbekannten PHP-Dateien unter wp-content/, unbekannten Admin-Konten und unerwarteten Plugins durchsucht

Nächster Schritt

Wenn Sie nicht mit Sicherheit sagen können, ob wp-content/upgrade/ auf Ihrem Server gesperrt ist, ob register_argc_argv aktiv ist oder welche Konten welche Rechte haben – dann ist jetzt der richtige Moment für eine Bestandsaufnahme.

Kontaktieren Sie SW Business Solutions für eine WordPress-Härtung: Wir analysieren die aktuelle Serverkonfiguration, setzen die beschriebenen Maßnahmen um und dokumentieren den Ergebnis-Stand, damit Ihr Team beim nächsten Sicherheitsrelease gezielt handeln kann.