Aktuell gehackte Websites: PHP-Sicherheitslücke bedroht weltweit Webseiten

Kurzfassung

• Betroffen: PHP-Versionen 5.4 bis 8.5.11 – praktisch jeder Webserver, der PHP-Anfragen verarbeitet (PHP-FPM, Apache mod_php, CGI, FrankenPHP, LiteSpeed).
• Fix: Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Für PHP 8.1 und älter gibt es keine offiziellen Security-Releases mehr (End of Life).
• Risiko: Ein einziger HTTP-Request kann ausreichen; WordPress-Plugin-Updates reichen nicht – die PHP-Runtime beim Hoster muss aktualisiert werden.
• Deutschland: Das BSI ordnet das Risiko mit Warnstufe 3 / Orange ein – unverzügliche Gegenmaßnahmen nötig (tagesschau.de).
• Maßnahme: Sofort patchen oder internet-facing Sites offline nehmen, bis PHP gepatcht ist (CERT-EU, Heise Security, BSI).

Einordnung in den Medien (21.10.2026)

Bundesweit und international berichten Nachrichten und Fachmedien über die Lage – von Kommunen, die Portale abschalten, bis zu Experten, die bereits erste Angriffe sehen. Ausführliche Quellenangabe am Ende des Artikels.

• tagesschau.de – BSI-Warnstufe Orange, Mainz, Potsdam, Halberstadt, Charité Berlin
• Handelsblatt – Patch am Nachmittag, BMI und Verfassungsschutz offline, erste Angriffe
• Deutschlandfunk – Kommunen nach Bundeswarnung, mainz.de, CERT-EU

Wie funktionieren die beiden Sicherheitslücken?

Am 20. Oktober 2026 kündigte das PHP-Team ein Security-Release an; die Patches erschienen am 21. Oktober 2026 gegen 13:30 UTC (ca. 15:30 Uhr MESZ). Betroffen ist die PHP-Laufzeit selbst – nicht ein einzelnes WordPress-Plugin. Angreifer müssen sich nicht anmelden; unter Umständen reicht eine manipulierte HTTP-Anfrage.

Offizielle Hinweise: PHP Changelog & Security, CERT-EU Advisory 2026-018, NCSC UK.

1. Was kann ein Angreifer damit machen?

Wenn der Angriff erfolgreich ist, könnte ein Angreifer beispielsweise:

• Dateien lesen: Konfigurationen, Zugangsdaten, .env-Dateien und Anwendungsschlüssel.
• Datenbanken kompromittieren: Über die Zugangsdaten der Anwendung auf PostgreSQL, MySQL oder MariaDB zugreifen.
• Dateien verändern: PHP-Dateien manipulieren oder eine dauerhafte Hintertür (Webshell) installieren.
• Daten stehlen: Kunden-, Benutzer- oder Geschäftsdaten auslesen.
• Weitere Systeme angreifen: Vom kompromittierten PHP-Prozess auf intern erreichbare Dienste zugreifen (Laterales Movement).

Das Handelsblatt zitiert Sicherheitsexperten mit dem Hinweis, dass bereits erste Angriffe beobachtet werden – nicht gepatchte, erreichbare Server gelten als hochgradig gefährdet.

Welche Webseiten und Systeme sind bedroht?

Grundsätzlich gilt: Jede Website, die auf einem Server mit verwundbarer PHP-Version läuft, kann kompromittiert werden – unabhängig vom CMS. Schätzungen zur Anzahl exponierter Instanzen gehen stark auseinander (Hunderttausende bis Millionen); entscheidend ist Ihre konkrete PHP-Version und ob der Server aus dem Internet erreichbar ist.

Welche Dienste sind aktuell abgeschaltet?

Am 21. Oktober 2026 haben mehrere Behörden, Universitäten, Unternehmen und Hosting-Anbieter offiziell gemeldet, dass sie Websites oder Dienste wegen der kritischen PHP-Sicherheitslücken vorsorglich offline genommen haben – während Patches eingespielt werden, nicht weil jeder Betreiber bereits gehackt wurde. Die Liste ändert sich laufend; einzelne Angebote können zwischenzeitlich wieder online sein.

2. Anleitung: PHP-Version prüfen (Shell & PHP)

WordPress- oder Shop-Updates ersetzen nicht das PHP-Update auf dem Server. Prüfen Sie die Runtime auf dem System, das Anfragen entgegennimmt (VPS, Dedicated, Container – nicht nur Ihr Laptop).

Linux / SSH – CLI-Version

php -v
php-fpm8.2 -v
php8.2 -v

Erwartung nach Patch (eine Zeile reicht): PHP 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 (oder höher).

Debian / Ubuntu – welches Paket ist installiert?

Vor dem Update Index aktualisieren, dann Policy prüfen (Beispiel PHP 8.2-FPM):

sudo apt update
apt-cache policy php8.2-fpm
apt-cache policy php8.2-cli

In der Ausgabe von apt-cache policy sehen Sie die installierte Version (Zeile „Installed:“) und ob im Repository bereits ein Fix-Paket liegt („Candidate:“). Ist Candidate noch 8.2.34 oder niedriger, fehlt der Patch in Ihrer Quelle noch – siehe Abschnitt „Wo gibt es noch keine Updates?“.

Update einspielen (wenn Candidate gepatcht ist)

sudo apt update
sudo apt install --only-upgrade php8.2-fpm php8.2-cli php8.2-common
sudo systemctl restart php8.2-fpm
sudo systemctl reload nginx

Paketnamen an Ihre PHP-Minor-Version anpassen (php8.3-fpm, php8.4-fpm …). Bei Apache mit mod_php: sudo systemctl reload apache2.

PHP-Code – Version und relevante Einstellungen (z. B. eigenes Admin-Skript, nur intern!)

Legen Sie kein öffentliches phpinfo() ab. Für eine kurze interne Prüfung reicht:

<?php
declare(strict_types=1);

header('Content-Type: text/plain; charset=utf-8');

$fixed = [
    '8.2' => '8.2.35',
    '8.3' => '8.3.36',
    '8.4' => '8.4.27',
    '8.5' => '8.5.12',
];

$version = PHP_VERSION;
echo "PHP_VERSION: {$version}\n";
echo "SAPI: " . PHP_SAPI . "\n";
echo "session.upload_progress.enabled: "
    . (ini_get('session.upload_progress.enabled') ? 'On' : 'Off') . "\n";

$majorMinor = implode('.', array_slice(explode('.', $version), 0, 2));
if (isset($fixed[$majorMinor])) {
    $ok = version_compare($version, $fixed[$majorMinor], '>=');
    echo $ok ? "Status: gepatcht (>= {$fixed[$majorMinor]})\n" : "Status: KRITISCH – Update nötig (< {$fixed[$majorMinor]})\n";
} else {
    echo "Status: Minor-Version prüfen (EOL oder 8.5.x beachten)\n";
}

Datei nach dem Test wieder löschen oder per IP/Firewall absichern.

WordPress (wp-cli, falls vorhanden)

wp cli info
# Zeigt u. a. die PHP-Version der WP-CLI-Runtime – mit Server-PHP abgleichen

3. Wo gibt es noch keine Updates?

Offizielle Fixes kommen vom PHP-Projekt – Distributionen und Hosters brauchen oft Stunden bis Tage, bis Pakete nachziehen. Prüfen Sie deshalb immer apt-cache policy oder Ihr Hosting-Panel, nicht nur Pressemeldungen.

• Ondřej Surý PPA (ppa:ondrej/php auf Ubuntu): Beliebt für mehrere PHP-Versionen parallel. Stand einer typischen Prüfung am 21.10.2026 kann der PPA noch PHP 8.2.34 als Candidate liefern – also noch ohne 8.2.35. Dann: PPA-Updates abwarten, temporär auf offizielle PHP-Releases aus anderen Quellen wechseln oder Server isolieren.
• Debian Stable / Enterprise-Linux: Security-Teams backporten Patches – Verzögerung möglich. apt update mehrfach täglich, Security-Mailinglisten des Distributors beobachten.
• Shared Hosting: Kein SSH – Ticket an Provider: „PHP ≥ 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12?“ Bis Antwort: Wartungsseite schalten. Bei All-Inkl zusätzlich Störungslage prüfen: All-Inkl auf allestörungen.de.
• Docker-Images: php:8.2-fpm etc. neu pullen und Container ersetzen; alte Images nicht weiterbetreiben.
• PHP 8.1 und älter: Kein Patch vom PHP-Projekt – nur Migration auf 8.2+ oder Abschaltung.

# PPA-Quelle prüfen (Ubuntu)
apt-cache policy php8.2-fpm | head -n 15

# Beispiel-Ausgabe interpretieren:
#  Installed: 8.2.34
#  Candidate: 8.2.34   → noch KEIN Fix im Repo
#  Candidate: 8.2.35   → jetzt upgraden

4. Übergangs-Härtung: session.upload_progress.enabled

Ein Patch ist die einzige dauerhafte Lösung. Bis das Update auf Ihrem System verfügbar ist, können Sie Angriffsflächen reduzieren – insbesondere im Zusammenhang mit Upload-/Formularverarbeitung (CVE-2026-109618).

In der php.ini oder FPM-Pool-Datei (z. B. /etc/php/8.2/fpm/conf.d/99-security.ini):

; Upload-Fortschritt deaktivieren – reduziert Angriffsvektor bei Formular-Uploads
session.upload_progress.enabled = Off

; Optional zusätzlich (je nach App testen):
; upload_max_filesize = 2M
; post_max_size = 8M

Danach PHP-FPM neu laden:

sudo systemctl restart php8.2-fpm

Wichtig: Das ersetzt kein Security-Update. Apps, die Upload-Fortschritt in der Session nutzen, können betroffen sein – vorher testen. Wer das Risiko nicht tragen will, folgt der Empfehlung von Heise Security / BSI: Webserver vom Netz trennen, bis gepatcht.

5. Checkliste für Website-Betreiber

1. PHP-Version ermitteln – Shell, Panel oder internes Prüfskript (siehe oben).
2. Patchen auf 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 – oder Provider-Ticket.
3. Kein Paket? apt-cache policy dokumentieren, Server offline oder hinter VPN, PPA/Distributor im Auge behalten.
4. PHP-FPM / Apache / Container neu starten – alle Worker laden die neue Binary.
5. Übergang: session.upload_progress.enabled = Off nur als Zusatz, nicht als Ersatz.
6. Nach Angriffsverdacht: Logs, Webshells, Admin-User – Reparatur & Härtung.
7. Langfristig: PHP-LTS, Monitoring, WAF – Softwareentwicklung, IT-Beratung.