RDDZ

PHP 8.6: Neuerungen, Änderungen und was jetzt zu prüfen ist

dennis_rddz — Sun, 01 Nov 2026 10:44:47 +0000

PHP · PHP 8.6 · STAND 01.11.2026

PHP 8.6: Neuerungen, Änderungen und was jetzt zu prüfen ist

PHP 8.6 soll am 19. November 2026 erscheinen. Zu den Neuerungen gehören Partial Function Application, eine Polling-API, die Klasse Time\Duration und Standardwerte für readonly Properties. Wichtiger für bestehende Anwendungen sind die strengeren Session-Defaults und eine lange Liste von Deprecations.

PHP 8.6 · RELEASE-PLAN

● Release Candidate

21.10.2026

RC4 erschienen

05.11.2026

RC5 geplant

19.11.2026

GA geplant

Partial Function Application● Neu

Polling-API (Io\Poll)● Neu

Time\Duration● Neu

Session-Defaults● Strenger

Deprecations● Viele

Quelle: Release-Plan und RFCs auf wiki.php.net. Stand 1. November 2026.

✓ Gegen RFCs und Release-Plan geprüft

✓ Stand 1. November 2026

✓ Mit Hinweisen für Hosting

✓ Praxisbefehle für den Umstieg

STAND

Release-Termin und Entwicklungsstand

Der Release-Plan sieht PHP 8.6.0 für den 19. November 2026 vor. Release Candidate 1 wurde übersprungen, RC2 erschien am 24. September, RC3 am 8. Oktober und RC4 am 21. Oktober. Für den 5. November ist RC5 eingeplant. Plan und einzelne Details der Version können sich bis zum Release noch ändern.

Release Candidates sind für Tests gedacht und gehören nicht auf Produktivsysteme. Anwendungen, Bibliotheken und Erweiterungen lassen sich schon jetzt testen. Freigeben sollte man PHP 8.6 erst nach dem finalen Release und einer eigenen Kompatibilitätsprüfung. Zend erwartet aktive Unterstützung bis Ende 2028 und Sicherheitsunterstützung bis Ende 2030, verbindlich sind die Termine erst mit dem Release.

NEUERUNGEN

Die wichtigsten Neuerungen in PHP 8.6

Partial Function Application

Mit Partial Function Application (PFA) lassen sich Funktionen teilweise vorbelegen. Der Platzhalter ? markiert ein Argument, das später übergeben wird, ... steht für alle restlichen. PHP erzeugt daraus eine Closure. Jedes ? wird dabei zu einem Pflichtparameter der Closure, auch wenn der Parameter der Originalfunktion optional war.

⚙

Eigene und eingebaute Funktionen

PHP

$makeSlug = str_replace(' ', '-', ?);

echo $makeSlug('Hello World');
// Hello-World

function multiply(int $a, int $b): int
{
    return $a * $b;
}

$double = multiply(2, ?);
echo $double(5);
// 10

Bei str_replace() sind die ersten beiden Argumente festgelegt, der Platzhalter steht für das Subjekt.

→

Zusammen mit dem Pipe-Operator

PHP

$output = 'Hello World'
    |> str_replace(' ', '-', ?)
    |> strtolower(...);

echo $output;
// hello-world

Der Pipe-Operator erwartet eine Funktion mit genau einem Argument. PFA liefert sie, ohne dass dafür eine eigene Closure wie fn($v) => str_replace(' ', '-', $v) nötig ist.

PFA ergänzt das bisherige Funktionsmodell und ist vor allem bei Callbacks, Array-Funktionen und Verarbeitungsketten praktisch.

Readonly Properties mit Standardwerten

Instanz-Properties mit readonly dürfen in PHP 8.6 einen Standardwert haben. Bisher war das ein Fehler beim Kompilieren. Das RFC wurde mit 24 zu 0 Stimmen angenommen und ist umgesetzt. Es betrifft normale deklarierte Properties und Properties in readonly-Klassen. Standardwerte an promoted Constructor-Parametern bleiben ganz normale Parameter-Defaults und sind nicht Teil der Änderung.

PHP

final class ApiConfig
{
    public readonly string $host = 'localhost';
    public readonly int $port = 443;
}

Der Standardwert gilt als Initialisierung. Die Property ist also schon gesetzt, bevor der Konstruktor läuft, und jede spätere Zuweisung wirft einen Fehler, auch im Konstruktor.

PHP

final class ApiConfig
{
    public readonly int $port = 443;

    public function __construct()
    {
        $this->port = 8443; // Fehler: bereits initialisiert
    }
}

Nutzen hat das vor allem bei unveränderlichen Konfigurationsobjekten und bei Klassen, die Interfaces mit { get; }-Properties erfüllen.

Polling-API für I/O

Für I/O-Multiplexing gab es bisher im Wesentlichen stream_select(). Die neue Polling-API im Namespace Io\Poll bietet eine einheitliche Schnittstelle über die Mechanismen des Betriebssystems: epoll unter Linux, kqueue unter BSD und macOS, Event Ports unter Solaris und illumos, WSAPoll unter Windows und poll als Fallback auf anderen POSIX-Systemen. Das Backend wird standardmäßig automatisch gewählt. Das RFC wurde mit 33 zu 1 Stimmen angenommen.

PHP

use Io\Poll\Context;
use Io\Poll\Event;

$context = new Context();

$stream = stream_socket_server('tcp://0.0.0.0:8080', $errno, $errstr);
stream_set_blocking($stream, false);

// StreamPollHandle liegt im globalen Namespace
$handle = new StreamPollHandle($stream);

$context->add($handle, [Event::Read], ['type' => 'server']);

while (true) {
    $watchers = $context->wait(1); // Timeout in Sekunden

    // Ereignisse verarbeiten
}

add() gibt ein Watcher-Objekt zurück, wait() liefert die Watcher mit ausgelösten Ereignissen. Welche Timeout-Typen wait() in 8.6 akzeptiert, ist nach den RFC-Texten nicht eindeutig: Das Polling-RFC nennt Sekunden und Mikrosekunden als Integer, das Duration-RFC spricht von einer Duration. Wer die API einsetzt, prüft die Signatur im Manual oder in einer Release Candidate.

Für ReactPHP, Amp und Revolt kann die API eine gemeinsame Grundlage sein, statt dass jede Bibliothek die Betriebssystem-Backends selbst anbindet. Asynchron wird PHP dadurch nicht: Die API ist laut RFC minimal gehalten und bringt weder eine Event-Loop noch eine Async-Laufzeit mit. Timer, Signale, Prozessverwaltung und die Ereignisverarbeitung bleiben Sache der Anwendung oder der Bibliothek. Erweiterungen um Timer-, Signal- und Prozess-Handles liegen als eigenes RFC vor, das für PHP 8.7 vorgesehen ist. Der Hauptgrund für die API liegt in PHP selbst: PHP-FPM, Signalbehandlung in ZTS und weitere interne Komponenten sollen von einer einheitlichen Polling-Infrastruktur profitieren.

Time\Duration

Time\Duration ist eine final readonly Klasse für Zeitspannen mit Nanosekunden-Genauigkeit. Es gibt Factory-Methoden wie fromSeconds(), fromMilliseconds(), fromMinutes() und fromIso8601DurationString(), außerdem add(), sub(), multiplyBy(), divideBy(), negate() und absolute(). Zeitspannen lassen sich mit < und > vergleichen. Das RFC wurde mit 35 zu 1 Stimmen angenommen.

PHP

use Time\Duration;

$base = Duration::fromMilliseconds(100);

// Duration ist unveränderlich, add() und multiplyBy() geben neue Objekte zurück
$total = $base->add(Duration::fromSeconds(2));

$attempt = 5;
$delay = $base->multiplyBy(2 ** $attempt);

if ($delay < Duration::fromSeconds(10)) {
    // Backoff liegt unter dem Limit
}

sleep() und usleep() akzeptieren Duration nicht. Das RFC schlägt keine Änderung bestehender Funktionen vor, die Beispiele dort sind ausdrücklich hypothetisch. Anders als DateTimeImmutable beschreibt Duration eine Zeitspanne und keinen Zeitpunkt oder ein Kalenderintervall.

Reflection: isReadable() und isWritable()

ReflectionProperty bekommt isReadable() und isWritable(). Im RFC-Code heißt die Methode isWritable, nur der URL-Slug des RFC enthält „iswriteable“. Beide Methoden nehmen einen Scope (null für den globalen Scope oder einen Klassennamen) und optional ein Objekt. Das RFC wurde mit 27 zu 0 Stimmen angenommen.

PHP

final class Book
{
    public private(set) string $title;
}

$property = new ReflectionProperty(Book::class, 'title');

var_dump($property->isReadable(scope: null)); // true
var_dump($property->isWritable(scope: null)); // false, von außen nicht schreibbar

Nötig wurden die Methoden, weil readonly (PHP 8.1) und asymmetrische Sichtbarkeit (PHP 8.4) die Annahme gebrochen haben, dass isPublic() auch etwas über Schreibbarkeit aussagt. Ohne Objekt wertet PHP nur die statischen Eigenschaften aus. Mit Objekt berücksichtigt es, ob eine readonly Property schon initialisiert ist. Gebraucht werden die Methoden vor allem in ORMs, Serializern, DI-Containern und Frameworks. In normalen Anwendungen fällt die Änderung kaum auf.

DocComments an Funktionsparametern

Dokumentationskommentare dürfen direkt an einzelnen Parametern stehen, vor dem Parameter oder dahinter und vor dem folgenden Komma. ReflectionParameter::getDocComment() liest sie aus. Das RFC wurde mit 23 zu 0 Stimmen angenommen.

PHP

function store(
    /** @param Book[] */
    array $books,
): void {
    // ...
}

$parameters = (new ReflectionFunction('store'))->getParameters();
$comment = $parameters[0]->getDocComment();

Statische Analyse, IDEs und Codegeneratoren können Typinformationen so gezielt einem Parameter zuordnen, statt sie aus einem gemeinsamen Funktionskommentar herauszulesen.

Kleinere Neuerungen

⇅

enum SortDirection

Eine globale Enum mit den Fällen Ascending und Descending als einheitlicher Typ für Sortierrichtungen. Eingebaute Funktionen wie array_multisort() oder scandir() akzeptieren sie noch nicht, Bibliotheken müssen sie selbst auswerten. Das RFC wurde mit 22 zu 2 Stimmen angenommen.

↔

clamp()

PHP

clamp(101, 0, 100);
// 100

clamp(-1, 0, 100);
// 0

Begrenzt einen Wert auf einen Bereich, auch für Strings und DateTime-Objekte. Ist min größer als max, wirft die Funktion einen ValueError. Eine Eingabevalidierung ersetzt sie nicht.

🔎

Enums mit __debugInfo()

Enums dürfen __debugInfo() implementieren und damit steuern, wie var_dump() sie ausgibt. Das hilft bei der Fehlersuche in Domain-Modellen. Zu dieser Änderung liegen nur Übersichtsartikel vor, ein einzelnes RFC wurde nicht geprüft.

Weitere Änderungen

Mehrere Übersichten (Zend, DEV Community) nennen darüber hinaus diese Punkte. Sie sind nicht einzeln gegen RFCs geprüft.

Die Funktionen mb_ereg*() und mb_split() sind deprecated und sollen in PHP 9.0 entfallen, weil Oniguruma nicht mehr gepflegt wird. Als Alternative nennt Zend PCRE mit dem Modifier /u.
php://filter-Ketten sind standardmäßig auf 16 Filter begrenzt. Das Limit lässt sich anheben.
Rückgabewerte aus __construct() und __destruct() lösen eine Deprecation aus und sollen in PHP 9.0 zum Fehler werden.
mysqli_quote_string() kommt als Gegenstück zu PDO::quote().
TLS-Sessions können über mehrere Requests auf derselben Verbindung wiederverwendet werden.
#[\Override] lässt sich auf Klassenkonstanten anwenden.

SICHERHEIT

Session-Defaults werden strenger

Für bestehende Anwendungen sind die geänderten Session-Defaults die praktisch wichtigste Änderung. Das RFC „Secure Session Configuration Defaults“ wurde angenommen: Jede der drei Einstellungen bekam eine eigene Abstimmung, alle mit mindestens 26 Ja-Stimmen und ohne Gegenstimme.

Einstellung	Bisher	PHP 8.6
`session.use_strict_mode`	`0`	`1`
`session.cookie_httponly`	`0`	`1`
`session.cookie_samesite`	leer	`Lax`

Das RFC ändert die eingebauten Defaults im Quellcode. Ob auch php.ini-development und php.ini-production angepasst werden, nennt es nicht, und eine Übersicht (Laravel News) spricht von „neuen Installationen“. Wer sich auf ein Verhalten verlassen will, setzt die drei Werte deshalb explizit.

session.use_strict_mode

PHP weist ungültige oder nicht akzeptierte Session-IDs zurück, was gegen Session-Fixation hilft. Anwendungen, die Session-IDs bewusst zwischen Subdomains übergeben, können mit dem dateibasierten Handler auf Probleme stoßen: Existiert die Session-Datei auf der empfangenden Seite noch nicht, wird die ID abgelehnt. Die Session sollte auf der Ursprungsseite geschrieben und mit session_write_close() geschlossen werden, bevor die ID weitergegeben wird. Handler, deren validateId() true liefert, sind nicht betroffen. Eigene Handler brauchen korrekte create_sid() und validateId().

session.cookie_httponly

JavaScript kann das Session-Cookie nicht mehr über document.cookie lesen. Anwendungen, die die Session-ID im Browser auslesen und etwa in eigene Header schreiben, müssen angepasst werden. Für Werte, die im Browser gebraucht werden, ist ein separates CSRF- oder Anwendungstoken der richtige Weg.

session.cookie_samesite=Lax

Das Cookie wird bei normalen same-site-Anfragen und bei Top-Level-Navigationen mit sicheren HTTP-Methoden gesendet, bei Cross-Site-POST-Anfragen nicht. Das RFC nennt SP-initiiertes SAML Single Sign-on und ältere Cross-Origin-Formulare als betroffen, dazu kommen externe Login-Prozesse. Wer Cross-Site-POST mit Session-Cookie braucht, muss die Cookie-Einstellungen gezielt setzen, in manchen Fällen mit SameSite=None; Secure, oder auf einen tokenbasierten Ablauf umstellen.

Die Änderung macht bisher implizite Annahmen sichtbar. SSO- und Login-Abläufe sollten deshalb vor dem Upgrade getestet werden.

DEPRECATIONS

Was Entwickler prüfen sollten

Eine Deprecation heißt: Das Verhalten funktioniert noch, PHP gibt aber eine Warnung aus, und es kann in einer späteren Version entfallen. Das RFC „Deprecations for PHP 8.6“ umfasst 35 einzelne Punkte. Nicht alle wurden angenommen: list() und in/out/inout als Bezeichner sind abgelehnt und stehen deshalb nicht in der Liste. Zu einem Teil der angenommenen Punkte stand das Abstimmungsergebnis bei der Prüfung nicht zur Verfügung. Die Liste gibt den RFC-Stand und die Übersichten wieder.

return in finally

Ein return im finally-Block ist deprecated (39 zu 3 Stimmen). Sein Wert überschreibt den Rückgabewert aus try, was überraschend ist und Fehler verdecken kann.

PHP

function getConfig(): array
{
    try {
        return loadConfig();
    } finally {
        return []; // überschreibt den Rückgabewert aus try
    }
}

Die übrigen Deprecations im Überblick

Bereich	Was deprecated wird	Empfehlung
Bezeichner	`let` und `is` als Namen für Klassen, Funktionen und Konstanten (Abstimmungsergebnis für `is` unbekannt); `namespace` als Klassenkonstante; Funktion namens `readonly` (39 zu 1); `_` als Konstante oder Compile-Time-Alias	Umbenennen
Objekte statt Arrays	`array_walk()`, `array_walk_recursive()`, `deflate_init()`, `inflate_init()`, `mb_convert_variables()`, `http_build_query()` sowie die Stream-Filter `zlib.` und `bzip2.` mit Objekten	Echte Arrays übergeben
Funktions-Aliase	`is_double()`, `is_integer()`, `is_long()`, `doubleval()`	`is_float()`, `is_int()`, `floatval()`
Funktionen	`define()` mit `$case_insensitive`; `is_a()` und `is_subclass_of()` mit String bei `allow_string: false`; `strcoll()`; `SORT_LOCALE_STRING`; `metaphone()`; `spl_classes()`; `spl_object_hash()`	`spl_object_id()` statt `spl_object_hash()`, für `spl_classes()` Reflection
Reflection	`ReflectionProperty::setValue()` und `setRawValue()` mit Objekt einer falschen Klasse; `ReflectionMethod::invoke()` und `invokeArgs()` mit Objekt bei statischen Methoden	Passendes Objekt, bei statischen Methoden `null`
SPL	Mehrere `ArrayIterator`-Methoden (`getFlags()`, `setFlags()`, `asort()`, `ksort()`, `uasort()`, `uksort()`, `natsort()`, `natcasesort()`, `serialize()`, `unserialize()`); die CSV-Methoden von `SplFileObject`	Auf `ArrayObject` oder Funktionen ausweichen
mysqli und Sessions	`mysqli::stmt_init()`; `mysqli_get_charset()` und `mysqli::get_charset()`; Session-Handler ohne `create_sid()` und `validateId()`	`$mysqli->prepare()`, Handler vervollständigen
Konstruktoren	Rückgabewerte aus `__construct()` und `__destruct()` (laut Zend Fehler ab PHP 9.0)	Rückgabewert entfernen

PHP

// Statische Methode über Reflection: null statt Objekt übergeben
$method = new ReflectionMethod(Book::class, 'create');
$method->invoke(null);

// Objekt-ID statt spl_object_hash()
$id = spl_object_id($object);

// Prepared Statement direkt erzeugen
$statement = $mysqli->prepare($sql);

Die meisten Umstellungen sind mechanisch. Frameworks, CMS-Plugins und ältere Anwendungen betrifft es am ehesten, bei den SPL-, Reflection- und Session-Handler-Punkten lohnt ein gezielter Blick.

HOSTING

Was PHP 8.6 für Hosting-Umgebungen bedeutet

🖥

PHP-FPM und paralleler Betrieb

PHP 8.6 braucht eine eigene Runtime mit separaten FPM-Pools, eigenen Sockets oder Ports, passendem CLI-Binary sowie eigenen Konfigurations- und Erweiterungsverzeichnissen. Im Shared Hosting sollte die Version pro Website wählbar sein. Eine globale Umstellung bestehender Websites ist unnötig riskant.

🧩

Native Erweiterungen

Imagick, Redis, Memcached, APCu, ionCube Loader, SourceGuardian und eigene PECL-Erweiterungen müssen für 8.6 verfügbar sein. Erweiterungen mit C-Anteilen werden gegen die passende PHP-Version neu gebaut, bei proprietären Modulen ist die Freigabe des Herstellers abzuwarten. Ein erfolgreicher Core-Build sagt nichts darüber, ob alle Erweiterungen laufen.

⚡

OPcache und Performance

OPcache gehört in die Testplanung: Speicherbedarf, Cache-Invalidierung, Verhalten nach Updates und FPM-Neustarts sowie Unterschiede zwischen CLI und FPM. Ob eine Anwendung schneller wird, zeigen nur realistische Benchmarks.

🔒

Session-Defaults dokumentieren

Kunden sollten wissen, warum sich SSO- oder externe Login-Abläufe nach dem Wechsel anders verhalten können. Einstellungen sind sauber zwischen globaler Konfiguration, FPM-Pools und Website-Konfiguration abzugrenzen.

Beim Rollout lohnt es sich, FPM-Fehler, Worker-Neustarts, Speicherverbrauch, Request-Laufzeiten, Fehler beim Laden von Erweiterungen, Session-Probleme und Deprecation-Meldungen zu überwachen.

Zur Sicherheitslage der aktuellen PHP-Versionen gibt es bei uns zwei Beiträge zu den PHP2Shell-Schwachstellen und den betroffenen Versionen.

KOMPATIBILITÄT

Welche Anwendungen laufen mit PHP 8.6?

Hier gibt es drei Stufen: Eine Anwendung läuft technisch unter PHP 8.6, der Hersteller testet 8.6 regelmäßig, oder der Hersteller gibt 8.6 offiziell frei. Nur die dritte ist eine Kompatibilitätsfreigabe. Bei WordPress, Laravel, Symfony, Nextcloud und anderen großen Projekten gilt das für die konkrete Version, Plugins, Themes, Bundles und Composer-Abhängigkeiten eingeschlossen.

📦

Composer als erste Prüfung

Bash

composer validate
composer check-platform-reqs
composer why-not php 8.6

Die Befehle zeigen, welche Abhängigkeiten PHP 8.6 nicht zulassen. Ein erfolgreicher Check beweist nicht, dass der Code fehlerfrei läuft, dafür braucht es automatisierte Tests.

🔎

Deprecations früh finden

Bash

grep -RInE \
'is_double|is_integer|is_long|doubleval|spl_object_hash|spl_classes' \
./src ./app

PHP 8.6 gehört in eine separate Testumgebung oder in die CI-Matrix. Die Meldungen sollte man auswerten und nicht unterdrücken. Auch die CSV-Methoden, Reflection-Aufrufe und Session-Handler gezielt prüfen.

VORGEHEN

So gelingt der Umstieg

Sinnvoll ist ein Vorgehen in mehreren Schritten.

Testumgebung

PHP 8.6 in einer Testumgebung installieren und die Anwendung damit starten.

Abhängigkeiten

Composer-Pakete, native Erweiterungen und proprietäre Module kontrollieren.

Deprecations

Neue Warnungen auswerten und die betroffenen Stellen im Code korrigieren.

Sessions und SSO

Sessions, Cookies, SSO und externe Anmeldung gezielt testen, die drei Session-Werte explizit setzen.

Tests und Performance

Unit-, Integrations- und Funktionstests mit 8.6 laufen lassen und Laufzeit sowie Speicherverbrauch mit realistischen Benchmarks vergleichen.

Rollout nach GA

Produktiv erst nach dem finalen Release und einem kontrollierten Rollout.

BEI RDDZ

Wie wir mit PHP 8.6 umgehen

Unser Hosting bietet aktuell PHP ab Version 8.3 an. PHP 8.6 bieten wir erst nach dem finalen Release und eigenen Tests an. Wer vorher wissen möchte, ob die eigene Anwendung betroffen ist, kann sich bei uns melden.

FAZIT

Jetzt testen, danach freigeben

Partial Function Application, Time\Duration, die Polling-API und die Reflection-Erweiterungen betreffen vor allem Frameworks, Bibliotheken und komplexere Anwendungen. Für Hosting-Umgebungen und bestehende Anwendungen zählen die geänderten Session-Defaults und die Deprecations mehr.

Produktiv freigeben sollte man PHP 8.6 nach dem Release am 19. November und einer eigenen Kompatibilitätsprüfung. Bis dahin lohnt sich ein Testlauf mit den Release Candidates.

QUELLEN

Quellen und RFCs

PHP-Update für Ihre Website planen?

Kompatibilität prüfen, Tests aufsetzen, sauber umstellen: Sprechen Sie uns an, wir begleiten Hosting und Betrieb.

Der Beitrag PHP 8.6: Neuerungen, Änderungen und was jetzt zu prüfen ist erschien zuerst auf RDDZ.

WordPress 7.1.4: Sicherheitsupdate behebt mehrere Schwachstellen

dennis_rddz — Wed, 28 Oct 2026 17:59:02 +0000

SICHERHEIT · WORDPRESS · 28.10.2026

WordPress 7.1.4: Sicherheitsupdate behebt mehrere Schwachstellen

Das WordPress-Team hat am 28. Oktober 2026 WordPress 7.1.4 veröffentlicht. Das Sicherheitsrelease behebt eine Schwachstelle im Aktualisierungsprozess, die zu Remote Code Execution führen kann, mehrere Stored-XSS-Probleme und ein gespeichertes Denial-of-Service-Problem. Laut WordPress sollten Websites umgehend aktualisiert werden.

WORDPRESS 7.1.4 · RELEASE

● Sicherheitsrelease

28.10.2026

Veröffentlicht

Sofort

Empfehlung von WordPress

7.2

Nächste Hauptversion

RCE im Upgrade-Fenster● Behoben

Stored XSS● Mehrere behoben

Stored DoS (Interactivity API)● Behoben

Customizer-Changesets● Behoben

Notizen-Berechtigung● Behoben

Root-Zertifikate● Aktualisiert

Quelle: offizielle Veröffentlichungsmitteilung von WordPress.org.

✓ Auf Basis der offiziellen Mitteilung

✓ Release vom 28. Oktober 2026

✓ Checkliste für Administratoren

✓ Hinweise zu älteren Zweigen

ÜBERBLICK

Das Wichtigste zu WordPress 7.1.4

WordPress empfiehlt, die eigenen Websites umgehend zu aktualisieren. Das Update lässt sich im Dashboard unter „Aktualisierungen“ installieren, und Installationen mit aktivierten automatischen Hintergrundupdates erhalten es von selbst. Die vollständige Liste der Korrekturen steht in der offiziellen Veröffentlichungsmitteilung.

Version: WordPress 7.1.4, veröffentlicht am 28. Oktober 2026
Typ: Sicherheitsrelease mit kurzem Zyklus, kein Funktionsupdate
Empfehlung des WordPress-Teams: sofort aktualisieren
Nächste Hauptversion: WordPress 7.2, derzeit für den 8. Dezember geplant

KORREKTUREN

Welche Sicherheitsprobleme behebt das Update?

Die Mitteilung nennt mehrere unterschiedliche Schwachstellen. Besonders relevant sind Probleme, die unter bestimmten Voraussetzungen Codeausführung ermöglichen, Inhalte manipulieren oder nicht veröffentlichte Informationen offenlegen.

Remote Code Execution im Upgrade-Fenster

Laut Mitteilung kann eine Schwachstelle im Aktualisierungsprozess während des Upgrade-Fensters zu Remote Code Execution führen. Gemeldet hat sie Umut Bayram. Remote Code Execution (RCE) bedeutet, dass sich Code auf einem Zielsystem ausführen lässt. Wie schwer das im Einzelfall wiegt, hängt von den Voraussetzungen für die Ausnutzung und von den Rechten des betroffenen Prozesses ab.

Der offizielle Hinweis beschreibt die Schwachstelle, liefert aber keine vollständige technische Analyse. Daraus lässt sich nicht ableiten, dass jede Installation gleichermaßen angreifbar ist. Einen Grund, mit dem Update zu warten, gibt es trotzdem nicht.

Mehrere Stored-XSS-Schwachstellen

Bei Stored Cross-Site Scripting (Stored XSS) werden manipulierte Inhalte gespeichert und später auf der Website verarbeitet oder angezeigt. Sichert die Anwendung sie nicht ausreichend ab, kann eingeschleuster JavaScript-Code im Kontext der Website laufen. Die Folgen hängen von der einzelnen Lücke und den Rechten der betroffenen Nutzer ab. Denkbar sind manipulierte Darstellungen, unerwünschte Aktionen im Browser oder Angriffe auf angemeldete Benutzer.

WordPress 7.1.4 korrigiert laut Mitteilung solche Probleme in diesen Bereichen:

speziell präpariertes Block-Markup
Datenschutzanfragen zur Entfernung personenbezogener Daten
die Interactivity API
die selektive Aktualisierung im Customizer
der Kategorien-Block
speziell präparierte Benutzernamen
Playlist- und Bild-Blöcke
die Blöcke für die Kommentarnavigation

Gespeichertes Denial of Service in der Interactivity API

Behoben ist außerdem ein gespeichertes Denial-of-Service-Problem (DoS) in der Interactivity API. Ein DoS zielt darauf, eine Anwendung zu beeinträchtigen, etwa durch erhöhte Auslastung oder eingeschränkte Verfügbarkeit einzelner Funktionen. Die Mitteilung nennt das Problem nur als gespeicherten DoS und macht keine weiteren Angaben zu den Ausnutzungsbedingungen.

Nicht veröffentlichte Customizer-Änderungen

Nicht veröffentlichte Änderungen im Customizer (Changesets) konnten laut WordPress auch von nicht angemeldeten Benutzern entdeckt werden. Das betrifft vor allem Websites, die dort Änderungen vorbereiten, die noch nicht öffentlich sein sollen. Ein Zugriff auf das Backend ist damit nicht gleichzusetzen, geplante Inhalte oder Designänderungen können aber sichtbar werden.

Notizen und Root-Zertifikate

Die Mitteilung nennt außerdem ein Berechtigungsproblem bei Notizen, die an Beiträge angehängt sind. Privilegierte Benutzer konnten sie lesen, obwohl ihnen die Berechtigung fehlte, den zugehörigen Beitrag zu bearbeiten. Zusätzlich hat WordPress die mitgelieferten Root-Zertifikate wegen des Widerrufs von eMudhra aktualisiert. Root-Zertifikate bilden die Vertrauenskette für bestimmte verschlüsselte Verbindungen.

Die vollständigen Details und die Liste der beteiligten Sicherheitsforscher stehen in der offiziellen Mitteilung.

CHECKLISTE

Was Administratoren jetzt tun sollten

Wichtigste Maßnahme ist das Update auf 7.1.4, sofern die Installation zum 7.1-Zweig gehört. Vor und nach der Aktualisierung lohnen sich ein paar Kontrollen.

Version prüfen

Im Backend zeigt „Dashboard, Aktualisierungen“ die installierte Version und ob 7.1.4 angeboten wird.

Wer einen anderen Versionszweig nutzt, prüft die dafür verfügbaren Sicherheitsupdates. WordPress hat die Korrekturen auf alle Zweige zurückportiert, die Sicherheitsfixes erhalten, derzeit bis 4.7. Die Backports sind noch in Arbeit und erscheinen, sobald sie fertig sind. Aktiv unterstützt wird laut WordPress nur die jeweils neueste Version.

Backup erstellen

Vor dem Update braucht es ein aktuelles Backup mit Datenbank, WordPress-Dateien, Upload-Verzeichnis, Themes, Plugins und Konfiguration, insbesondere wp-config.php.

Viele Hoster sichern automatisch. Prüfe, ob eine aktuelle Sicherung vorliegt und ob sich daraus wiederherstellen ließe. Bei produktiven Websites sollte der Restore regelmäßig getestet werden.

Update installieren

Im Dashboard unter Aktualisierungen auf „Jetzt aktualisieren“ klicken oder das Release von WordPress.org herunterladen.

Auch bei aktivierten Hintergrundupdates lohnt der Blick auf den tatsächlich installierten Versionsstand.

Website testen

Nach dem Update prüfen: Startseite und wichtige Unterseiten, Backend-Anmeldung, Bearbeitung von Beiträgen und Seiten, Formulare, Suche, WooCommerce und andere geschäftskritische Plugins, Caching- und Sicherheitsplugins sowie die Fehlerprotokolle von Webserver und WordPress.

Bei Problemen zuerst Fehlerprotokolle und Kompatibilität der Erweiterungen untersuchen. Ein erfolgreiches Core-Update sagt nichts darüber, ob jedes Drittanbieter-Plugin fehlerfrei läuft.

Plugins und Themes aktuell halten

Das Core-Update ersetzt keine Plugin- und Theme-Updates. Prüfe separat, ob für installierte Erweiterungen Sicherheitsupdates vorliegen, und entferne nicht mehr benötigte Plugins und Themes vollständig, statt sie deaktiviert auf dem Server liegen zu lassen.

AUTOMATISCH

Werden Websites automatisch aktualisiert?

WordPress unterstützt automatische Hintergrundupdates, und laut Mitteilung aktualisieren sich Websites, die das unterstützen, automatisch. Ob das bei einer konkreten Installation greift, hängt von Konfiguration und Voraussetzungen ab. Ob eine Website bereits geschützt ist, zeigt der Versionsstand im Dashboard oder in der Verwaltungsumgebung, die für die Installation vorgesehen ist. Wer mehrere Websites betreut, sollte sich eine zentrale Übersicht schaffen, damit keine Installation durchrutscht.

EINORDNUNG

Ist WordPress 7.1.4 ein Funktionsupdate?

Nein, 7.1.4 ist ein Sicherheitsrelease mit kurzem Zyklus. Die nächste Hauptversion WordPress 7.2 ist derzeit für den 8. Dezember geplant. Laut WordPress enthält bereits die Beta 3 von 7.2 alle zutreffenden Korrekturen.

Für Betreiber produktiver Websites heißt das: Sicherheitsupdates sollten zeitnah eingespielt werden, größere Funktionsupdates lassen sich vorher auf Kompatibilität und Änderungen im eigenen Betrieb prüfen.

FAZIT

7.1.4 zeitnah einspielen

WordPress 7.1.4 behebt mehrere sicherheitsrelevante Probleme. Dazu gehören die Schwachstelle im Aktualisierungsprozess, die unter bestimmten Voraussetzungen Remote Code Execution ermöglichen kann, mehrere Stored-XSS-Probleme und ein Denial-of-Service-Problem. Wer WordPress betreibt, prüft jetzt den installierten Versionsstand und spielt das Update ein. Ein Backup vorher, ein kurzer Funktionstest danach und die regelmäßige Kontrolle von Plugins und Themes gehören weiterhin zur Wartung.

QUELLEN

Offizielle Quellen

Updates und Wartung für Ihre WordPress-Website?

Backups, Updates und Tests nehmen Zeit in Anspruch. Sprechen Sie uns an, wir kümmern uns um Betrieb und Absicherung.

Der Beitrag WordPress 7.1.4: Sicherheitsupdate behebt mehrere Schwachstellen erschien zuerst auf RDDZ.

VLAN im Firmennetzwerk: Gäste-WLAN, Server und Arbeitsplätze sicher trennen

dennis_rddz — Sat, 24 Oct 2026 16:57:39 +0000

RDDZ PRAXISBEISPIEL · NETZWERKSEGMENTIERUNG

VLAN im Firmennetzwerk: Gäste-WLAN, Server und Arbeitsplätze sicher trennen

Buchhaltung, Verwaltungssoftware und Gäste-WLAN hängen bei vielen Kunden im selben Netz. Wir zeigen, wie wir Netzwerke mit VLANs, OPNsense, MikroTik und UniFi in getrennte Zonen aufteilen, und was dafür an Hardware und Planung nötig ist.

NETZWERKSEGMENTIERUNG · VON RDDZ

● Mehrfach bei Kunden umgesetzt

Default Deny

Grundprinzip unserer Firewall-Regeln

3 bis 4

Typische Netzwerk-Zonen bei Kunden

Art. 32

DSGVO: angemessene TOMs je nach Risiko

Schritt 1Bestandsaufnahme

Schritt 2VLAN-Konzept & Regeln

Schritt 3Umsetzung & Test

Beispielhafter Ablauf, Details je nach Umgebung unterschiedlich.

✓ Buchhaltung und Verwaltungssoftware in eigener Netzwerk-Zone

✓ Gäste-WLAN ohne Zugriff auf interne Systeme

✓ Firewall-Regeln nach dem Default-Deny-Prinzip zwischen den Zonen

✓ Mögliche technische Maßnahme im Sinne von Art. 32 DSGVO

✓ Umgesetzt mit OPNsense, MikroTik/UniFi-Switches und UniFi-Access-Points

DAS PROBLEM

Ein Netz für alles ist keine Trennung

Ein typisches Firmennetzwerk, das wir bei Kunden vorfinden, sieht oft gleich aus: ein einziges Netz für Buchhaltung, Arbeitsplätze und Gäste.

📂

Sensible Systeme offen erreichbar

Der Server mit der Verwaltungssoftware hängt oft im gleichen Subnetz wie jeder andere Arbeitsplatz.

📶

Gäste ohne echte Trennung

Ein Gäste-Laptop im Empfang kann technisch oft dieselben Geräte erreichen wie ein Mitarbeiter-PC, wenn keine wirksame Trennung eingerichtet ist.

🔓

Keine Zugriffskontrolle

Geräte im selben Netz können je nach lokalen Regeln und Diensten direkt miteinander kommunizieren, auch wenn sie dort nichts zu suchen haben.

⚠

Im selben VLAN keine Trennung

Geräte im gleichen VLAN können weiterhin direkt miteinander kommunizieren. Eine Trennung entsteht erst zwischen verschiedenen VLANs.

Was das in der Praxis bedeutet

Wird ein Gerät im Gäste-WLAN kompromittiert, kann es im schlimmsten Fall direkt mit Systemen im selben Netz kommunizieren, ohne eine weitere Hürde überwinden zu müssen.

GRUNDLAGEN

Was ein VLAN kann und was nicht

VLAN steht für Virtual Local Area Network: Ein physisches Netzwerk wird logisch in mehrere getrennte Netze aufgeteilt, ohne dafür extra Kabel zu verlegen.

🔗

Logische statt physische Trennung

Jedes VLAN verhält sich wie ein eigenes Netzwerk, auch wenn am Ende alles über dieselben Switches und Leitungen läuft.

🔒

Firewall entscheidet zwischen VLANs

Bei richtigem Aufbau läuft der Verkehr zwischen VLANs über die Firewall und wird dort nach den festgelegten Regeln erlaubt oder blockiert.

⚙

Erst mit passenden Regeln sicher

Den gewünschten Schutz bringen erst sauber geplante Firewall-Regeln und anschließende Tests.

DATENSCHUTZ

Netzwerksegmentierung und die DSGVO

Buchhaltung und Verwaltungssoftware verarbeiten in aller Regel personenbezogene Daten: Gehälter, Kundendaten, Vertragsinhalte.

Der Gesetzestext dazu, ohne eigene Rechtsbewertung:

Art. 32 DSGVO

Art. 32 DSGVO verlangt:
"geeignete technische und organisatorische Maßnahmen",
angepasst an Stand der Technik, Implementierungskosten,
Art, Umfang und Zwecke der Verarbeitung sowie das Risiko
für die Rechte und Freiheiten betroffener Personen.

VLANs schreibt Art. 32 nicht ausdrücklich vor. Netzwerksegmentierung kann aber eine geeignete Maßnahme sein, um Zugriffe auf Systeme mit personenbezogenen Daten zu begrenzen. Welche Maßnahmen im Einzelfall erforderlich sind, hängt vom jeweiligen Risiko und der konkreten Umgebung ab.

IN DER PRAXIS

Ein Beispiel für Firewall-Regeln

Wie die Trennung konkret aussieht, hängt vom Einzelfall ab. Ein typisches Muster sieht etwa so aus:

📶

Gäste: nur Internet

Gäste dürfen ins Internet, aber nicht auf interne Server oder Verwaltungsoberflächen zugreifen.

👤

Mitarbeiter: nur was gebraucht wird

Mitarbeiter erhalten nur Zugriff auf die Systeme, die sie für ihre Arbeit tatsächlich benötigen.

🛠

Verwaltung: eigene Zugriffsgrenzen

Administrationszugriffe auf Firewall, Switches und Access Points sind auf dafür vorgesehene Geräte oder Netze beschränkt.

Default Deny als Ausgangsbasis

Nicht benötigte Verbindungen zwischen VLANs werden standardmäßig blockiert. Die Planung für die jeweilige Umgebung bleibt trotzdem nötig.

NICHT VERGESSEN

Weitere Geräte und Tests

Weitere Geräte im Netz

Drucker, NAS-Systeme, VoIP-Telefone und IoT-Geräte sollten bei der Planung mitgedacht werden, auch wenn sie nicht immer eine eigene Zone brauchen.

Tests nach der Einrichtung

Aus dem Gäste-WLAN gezielt prüfen, ob Server, Drucker, NAS und Verwaltungsoberflächen wirklich nicht erreichbar sind, auch über IPv6 und nicht nur über IPv4.

UMSETZUNG

Was man dafür braucht

Ein einfaches Gastnetz, wie es z. B. eine FRITZ!Box bietet, trennt Gäste vom Heimnetz. Für mehrere frei konfigurierbare Zonen mit individuellen Firewall-Regeln braucht es darüber hinaus passende Netzwerktechnik:

Firewall mit VLAN-Routing

Bei uns in der Regel OPNsense, die VLAN-Routing und Regeln pro VLAN beherrscht.

VLAN-fähige Switches

Managed Switches, je nach Projekt häufig MikroTik, teils auch UniFi-Switches.

Access Points mit VLAN-Zuordnung

Meist UniFi-Access-Points, bei denen sich z. B. das Gäste-WLAN-SSID automatisch dem richtigen, isolierten VLAN zuordnen lässt.

Bestandsaufnahme

Welche Geräte und Systeme gibt es, und wer muss worauf zugreifen?

VLAN-Konzept erstellen

Zonen und Firewall-Regeln passend zu den vorhandenen Systemen und dem Schutzbedarf festlegen.

Umsetzung an Firewall, Switches, APs

Konfiguration der VLANs und Firewall-Regeln auf der vorhandenen oder neu beschafften Hardware.

Testphase inkl. IPv6

Prüfen, dass alle wirklich benötigten Verbindungen funktionieren und alle anderen blockiert sind.

FAZIT

Netzwerksegmentierung braucht Planung und Tests

Ein Netzwerk, in dem Buchhaltung, Verwaltungssoftware und Gäste-WLAN im selben Netz liegen, kommt bei Kunden häufig vor. VLANs mit sauber geplanten Firewall-Regeln können den Zugriff auf sensible Systeme deutlich einschränken, ersetzen aber keine sorgfältige Planung und regelmäßige Überprüfung.

Welche Trennung sinnvoll ist, hängt von den vorhandenen Systemen, den benötigten Verbindungen und dem Schutzbedarf ab.

Hinweis: Dieser Beitrag beschreibt unser generelles Vorgehen bei Kundenprojekten, keine konkrete Kundenumgebung und keine Rechtsberatung. Details hängen immer vom Einzelfall ab.

FAQ

Häufige Fragen zur Netzwerksegmentierung

Was ist der Unterschied zwischen einem VLAN und einem separaten Netzwerk?

Nextcloud 34 auf 35 aktualisieren: Schritt für Schritt per Kommandozeile

dennis_rddz — Sat, 24 Oct 2026 16:18:47 +0000

NEXTCLOUD · ANLEITUNG · 24.10.2026

Nextcloud 34 auf 35 aktualisieren: Schritt für Schritt per Kommandozeile

Nextcloud 35 ist da, und für klassische Installationen unter Debian und Ubuntu führt der sauberste Weg über die Kommandozeile: Backup, Updater, occ, Kontrolle. Wir zeigen den kompletten Ablauf mit den Befehlen, erklären die PHP-Falle bei älteren Systemen und sagen, was du im Fehlerfall tust.

UPGRADE · 34 → 35

● Per Kommandozeile

34.0.5

Ausgangsstand

35.0.2

Zielversion

9 Schritte

vom Backup bis zur Kontrolle

PHP● 8.3 bis 8.5

Betriebssystem● z. B. Debian 13, Ubuntu 24.04

Werkzeug● updater.phar + occ

Vorher● Backup und Testkopie

Nicht überspringbar● Hauptversionen

Für Archivinstallationen. Docker, AIO und Snap haben eigene Wege.

✓ Alle Befehle für Debian und Ubuntu

✓ Updater per Kommandozeile

✓ Mit Backup und Rollback

✓ Geprüft gegen die offizielle Doku

ÜBERBLICK

Für wen diese Anleitung gedacht ist

Diese Anleitung gilt für eine klassische Nextcloud-Installation aus dem offiziellen Archiv unter Debian oder Ubuntu, betrieben mit PHP und Apache oder nginx. Sie setzt voraus, dass du per SSH auf den Server kommst. Für Docker, Nextcloud AIO und Snap gelten eigene Update-Verfahren, die wir ganz unten kurz abgrenzen.

Warum 35 und warum jetzt oder später, haben wir in unserem Vergleich Nextcloud 34 vs. 35 beschrieben. Hier geht es nur um das Wie. Die Pfade und der Benutzer www-data in den Beispielen sind typische Werte und müssen zu deiner Installation passen.

Der Ablauf in neun Schritten

Vorbereiten

Ausgangslage prüfen
Systemanforderungen und PHP-Falle
Apps prüfen

Absichern

Auf 34.0.5 bringen
Vollständiges Backup
Testkopie und Wartungsfenster

Ausführen

Upgrade per Updater
Nacharbeiten
Kontrolle und Rollback-Plan

SCHRITT 1

Ausgangslage prüfen

Melde dich per SSH an und prüfe, welche Version läuft und wo die Daten liegen. Den Pfad des Datenverzeichnisses brauchst du später für Backup und Rollback.

Bash

cd /var/www/nextcloud

sudo -E -u www-data php occ status
sudo -E -u www-data php occ config:system:get datadirectory
sudo -E -u www-data php occ config:system:get dbtype

occ status zeigt die installierte Version und ob der Wartungsmodus aktiv ist. Du solltest wirklich Nextcloud 34 betreiben und die Installation sollte fehlerfrei laufen. Sieh dir außerdem unter Einstellungen → Verwaltung → Übersicht die Warnungen an. Bestehende Probleme löst du besser vor dem Upgrade, sonst suchst du hinterher nach der Ursache.

Wichtig

Das Upgrade läuft als Webserver-Benutzer. Gehören die Nextcloud-Dateien einem anderen Benutzer, scheitert der Updater an den Schreibrechten. Prüfe das vorab mit ls -ld /var/www/nextcloud /var/www/nextcloud/updater und passe den Benutzer in allen Befehlen an.

SCHRITT 2

Systemanforderungen und die PHP-Falle

Nextcloud 35 setzt neuere Systemkomponenten voraus. Laut offizieller Dokumentation gilt:

Komponente	Unterstützt für Nextcloud 35
PHP	8.3, 8.4 und 8.5 (8.5 empfohlen)
MariaDB	10.11, 11.4, 11.8 und 12.3
MySQL	8.4 und 9.7
PostgreSQL	14 bis 18 (18 empfohlen)
Debian	13 (Trixie)
Ubuntu	24.04 LTS und 26.04 LTS
Webserver	Apache 2.4 oder nginx mit PHP-FPM

Die vollständige und aktuelle Liste steht in den offiziellen Systemanforderungen. Prüfe dein System so:

Bash

cat /etc/os-release | head -3
php -v
php -m | grep -Ei 'gd|curl|intl|mbstring|zip|xml|apcu|redis'
mariadb --version   # oder: mysql --version / psql --version

Die Falle: Debian 12 und Ubuntu 22.04

php -v zeigt nur die PHP-CLI. Entscheidend ist die Version, die dein Webserver tatsächlich verwendet, etwa PHP-FPM. Debian 12 liefert in den Standardpaketquellen PHP 8.2, Ubuntu 22.04 sogar nur PHP 8.1. Beide erfüllen die PHP-Mindestversion von Nextcloud 35 nicht, und die Betriebssysteme stehen auch nicht in der Liste oben. Der Upstream-Support für PHP 8.2 endet zudem am 31. Dezember 2026.

Du hast drei Möglichkeiten:

Betriebssystem aktualisieren (empfohlen). Zuerst auf einer Kopie oder einer frischen VM durchspielen, dann produktiv umsetzen. Dazu haben wir einen eigenen Beitrag: Debian 12 auf Debian 13 upgraden.
PHP aus einer Drittquelle einspielen. Technisch möglich, liegt aber außerhalb der Distribution. Du trägst dann Pflege, Sicherheitsupdates und Kompatibilität selbst und solltest es nur nach einem Test tun.
Bei Nextcloud 34 bleiben. Es besteht kein Zeitdruck, Nextcloud 34 wird bis Juni 2027 unterstützt. So gewinnst du Zeit für den Systemumbau.

Bei MySQL 9 gibt es eine zusätzliche Besonderheit mit der MD5-Komponente, die wir im Vergleichsbeitrag beschrieben haben. Wer MySQL 9 einsetzt, liest dort nach, bevor er startet.

SCHRITT 3

Installierte Apps auf Kompatibilität prüfen

Nicht jede Zusatz-App ist sofort mit einer neuen Hauptversion kompatibel. Halte zuerst fest, was installiert ist, damit du nach dem Upgrade vergleichen kannst.

Bash

cd /var/www/nextcloud
sudo -E -u www-data php occ app:list > ~/nextcloud-apps-vorher.txt
sudo -E -u www-data php occ app:update --all

app:update --all bringt die Apps auf den neuesten für Nextcloud 34 verfügbaren Stand. Prüfe dann für jede wichtige App im App-Store, ob sie Nextcloud 35 unterstützt. Das gilt besonders für Drittanbieter-Apps, externe Speicher, zusätzliche Anmeldeverfahren und selbst entwickelte Erweiterungen. Ist die Unterstützung unklar, ist das ein Grund für die Testkopie aus Schritt 6.

Fällt eine App durch, kannst du sie vor dem Upgrade mit sudo -E -u www-data php occ app:disable APPNAME abschalten und nach dem Upgrade einzeln wieder aktivieren, sobald eine kompatible Version vorliegt.

SCHRITT 4

Nextcloud 34 auf den aktuellen Stand bringen

Vor dem Wechsel auf eine neue Hauptversion muss die bestehende Installation auf dem aktuellen Wartungsstand ihrer Hauptversion sein. Zum Stand vom 24. Oktober 2026 ist das Nextcloud 34.0.5. Hauptversionen darfst du nicht überspringen: Wer noch auf Nextcloud 33 läuft, geht zuerst auf 34 und danach auf 35.

Dafür nutzt du denselben Updater wie in Schritt 7. Führe ihn aus, schließe das Update auf 34.0.5 ab und kontrolliere danach die Version:

Bash

sudo -E -u www-data php /var/www/nextcloud/updater/updater.phar

sudo -E -u www-data php occ status

Der Updater zeigt vor dem Start an, auf welche Version er aktualisiert. Lies diese Anzeige und bestätige erst dann. Läuft die Installation auf 34.0.5 fehlerfrei, kannst du weitermachen. Wer ohnehin schon auf 34.0.5 ist, überspringt diesen Schritt.

SCHRITT 5

Vollständiges Backup erstellen

Dieser Schritt ist unverzichtbar. Der Updater sichert zwar den bisherigen Programmcode, aber weder die Datenbank noch das Datenverzeichnis. Ein Downgrade wird nicht unterstützt, im Fehlerfall ist das Backup der einzige verlässliche Rückweg. Nach der offiziellen Anleitung sicherst du für ein konsistentes Backup bei aktiviertem Wartungsmodus Verzeichnisse und Datenbank:

Bash

cd /var/www/nextcloud
sudo -E -u www-data php occ maintenance:mode --on

# Verzeichnisse: Nextcloud inkl. config, Apps und Datenverzeichnis
sudo rsync -Aavx /var/www/nextcloud/ /backup/nextcloud-dirbkp_$(date +%Y%m%d)/
# Liegt das Datenverzeichnis außerhalb (siehe Schritt 1), separat sichern:
sudo rsync -Aavx /srv/nextcloud-data/ /backup/nextcloud-databkp_$(date +%Y%m%d)/

💾

MariaDB und MySQL

Bei Verwendung von utf8mb4 den Zeichensatz mitgeben. Das Passwort nicht direkt in den Befehl schreiben, sondern über eine geschützte Optionsdatei oder die Eingabeaufforderung (-p) angeben, sonst steht es in der Prozessliste und in der Shell-Historie:

Bash

mariadb-dump --single-transaction \
  --default-character-set=utf8mb4 \
  -h localhost -u NEXTCLOUD_DBUSER -p NEXTCLOUD_DB \
  > /backup/nextcloud-sqlbkp_$(date +%Y%m%d).bak

Bei MySQL heißt das Programm mysqldump, die Optionen sind gleich.

💾

PostgreSQL

Auch hier wird das Passwort besser über die Eingabeaufforderung oder ~/.pgpass bereitgestellt:

Bash

pg_dump NEXTCLOUD_DB \
  -h localhost -U NEXTCLOUD_DBUSER \
  -f /backup/nextcloud-sqlbkp_$(date +%Y%m%d).bak

Datenbankname, Benutzer und Host findest du in config/config.php.

Schalte den Wartungsmodus nach dem Backup wieder aus, denn der Updater aktiviert ihn bei Bedarf selbst:

Bash

sudo -E -u www-data php occ maintenance:mode --off

Backup prüfen

Ein Backup, das sich nicht zurückspielen lässt, ist keines. Kontrolliere zumindest, dass die Dateien vorhanden und nicht leer sind. Besser ist eine Probe-Wiederherstellung auf der Testkopie aus dem nächsten Schritt. Bei virtuellen Maschinen ist zusätzlich ein Snapshot unmittelbar vor dem Upgrade ein guter Rückfallpunkt.

SCHRITT 6

Testkopie und Wartungsfenster

Bei einer produktiven Installation lohnt es sich, den Ablauf zunächst auf einer Kopie zu üben. Stelle das Backup aus Schritt 5 auf einer separaten VM mit gleichem Betriebssystem und gleicher PHP- und Datenbankversion wieder her und führe dort das komplette Upgrade durch. So siehst du, ob Apps, PHP-Module oder die Datenbank Probleme machen, bevor sie den laufenden Betrieb treffen. Gleichzeitig bekommst du ein Gefühl für die Dauer.

Dauer abschätzen

Die Testkopie zeigt, wie lange das Upgrade mit deiner Datenmenge und Datenbankgröße dauert. Das Wartungsfenster sollte großzügig darüber liegen.

Benutzer informieren

Kündige das Wartungsfenster an. Während des Upgrades ist Nextcloud nicht normal nutzbar. Synchronisierende Clients melden in dieser Zeit Fehler und holen den Abgleich danach nach.

Keine anderen Änderungen

Nimm im selben Fenster keine weiteren Änderungen an PHP, Datenbank oder Webserver vor. Bei einem Problem wüsstest du sonst nicht, was die Ursache ist.

SCHRITT 7

Das Upgrade mit dem Updater durchführen

Der Updater lädt das neue Archiv, prüft es, ersetzt den Programmcode und kann anschließend occ upgrade ausführen. Er läuft als Webserver-Benutzer und setzt zu Beginn selbst den Wartungsmodus. Starte ihn aus dem Nextcloud-Verzeichnis:

Bash

cd /var/www/nextcloud
sudo -E -u www-data php updater/updater.phar

Der Updater führt dich durch die Schritte:

Er zeigt die Versionsinformationen an. Prüfe, dass die Zielversion Nextcloud 35.0.2 ist, und bestätige mit Y.
Er prüft Voraussetzungen, lädt das Archiv herunter und ersetzt den Programmcode. Die bisherigen Programmdateien sichert er im updater-Ordner im Datenverzeichnis.
Am Ende fragt er, ob occ upgrade ausgeführt werden soll. Beantworte das mit Y, dann übernimmt der Updater die Datenbank- und App-Migration.
Danach fragt er, ob der Wartungsmodus aktiv bleiben soll. Antworte mit N, wenn der Wartungsmodus nach dem Upgrade enden soll. Wer zuerst intern testen möchte, lässt ihn aktiv und schaltet ihn später mit occ maintenance:mode --off aus.

Wenn ein Schritt scheitert

Behebe die Ursache und starte den Updater erneut. Er setzt an der fehlgeschlagenen Stelle fort und wiederholt abgeschlossene Schritte nicht. Hinweise liefert die Datei updater.log im Datenverzeichnis. Sagst du beim Start der Migration versehentlich N, führst du sie selbst aus:

Bash

cd /var/www/nextcloud
sudo -E -u www-data php occ upgrade

Nicht doppelt ausführen

Hat der Updater occ upgrade bereits erfolgreich abgeschlossen, ist ein zweiter manueller Aufruf unnötig. Orientiere dich am Status der Installation und an der Meldung des Updaters.

Optionen für Sonderfälle

Mit --no-interaction läuft der Updater ohne Rückfragen, sinnvoll etwa in einem vorbereiteten Wartungsfenster. Der Wartungsmodus wird dann am Ende ausgeschaltet, es sei denn, beim Austausch oder bei occ upgrade ist ein Fehler aufgetreten. --no-backup überspringt die Sicherung des alten Programmcodes. Beide Optionen sind für den Normalfall nicht nötig, und auf --no-backup solltest du verzichten. Der Updater benötigt laut Dokumentation mindestens 256 MB RAM.

Ein manuelles Upgrade mit dem Archiv ist ebenfalls möglich, aber fehleranfälliger. Es empfiehlt sich, wenn der Updater nicht nutzbar ist. Die vollständige Abfolge beschreibt die offizielle Anleitung zum manuellen Upgrade. Mische beide Verfahren nicht unkoordiniert.

SCHRITT 8

Nacharbeiten nach dem Upgrade

Kontrolliere zuerst Version und Wartungsmodus, und schalte den Wartungsmodus bei Bedarf aus:

Bash

cd /var/www/nextcloud
sudo -E -u www-data php occ status
sudo -E -u www-data php occ maintenance:mode --off

Danach lohnt sich ein Blick auf Einstellungen → Verwaltung → Übersicht. Nach einem Hauptversions-Upgrade meldet Nextcloud dort oft fehlende Datenbankindizes oder anstehende Reparaturen. Die üblichen Befehle dazu:

Bash

sudo -E -u www-data php occ db:add-missing-indices
sudo -E -u www-data php occ maintenance:repair --include-expensive

maintenance:repair --include-expensive kann bei großen Installationen lange dauern. Plane das außerhalb der Hauptnutzungszeit ein und führe es nur aus, wenn die Übersicht oder die Upgrade-Hinweise es verlangen. Die Datei nextcloud-apps-vorher.txt aus Schritt 3 hilft jetzt, die Apps zu vergleichen:

Bash

sudo -E -u www-data php occ app:list
sudo -E -u www-data php occ app:update --all

Aktiviere abgeschaltete Apps nur dann wieder (occ app:enable APPNAME), wenn für Nextcloud 35 eine kompatible Version vorliegt, und prüfe sie einzeln.

SCHRITT 9

Kontrolle und Rollback-Plan

Prüfe nicht nur die Versionsnummer, sondern den Alltagsbetrieb:

Wird Nextcloud 35 angezeigt und ist der Wartungsmodus aus?
Funktionieren Anmeldung, Datei-Upload und Datei-Download?
Laufen Kalender, Kontakte und gegebenenfalls Talk?
Sind externe Speicher erreichbar und die wichtigen Apps aktiv?
Läuft der Hintergrundjob (Cron)? Unter Einstellungen → Verwaltung → Grundeinstellungen steht der Zeitpunkt der letzten Ausführung.
Gibt es neue Fehler im Nextcloud-Protokoll unter Einstellungen → Verwaltung → Protokoll?

Stehen Hintergrundmigrationen aus, warte deren Abschluss ab, bevor du weitere Änderungen planst. Bei Problemen analysiere zuerst die konkrete Fehlermeldung und die Protokolle, statt wahllos Reparaturbefehle auszuführen.

Wenn nichts mehr hilft: zurück zum Backup

Ein Downgrade ist nicht vorgesehen und kann Daten beschädigen. Der Rückweg ist deshalb das Wiederherstellen aus dem Backup. Das ist ein bewusst gewählter, destruktiver Schritt: Die Datenbank wird gelöscht und aus der Sicherung neu aufgebaut. Gehe nur so vor, wenn du ihn wirklich brauchst, und folge der offiziellen Wiederherstellungs-Anleitung. Im Kern sieht das bei MariaDB und MySQL so aus:

Bash

# Dateien zurückspielen
sudo rsync -Aax /backup/nextcloud-dirbkp_DATUM/ /var/www/nextcloud/

# Datenbank löschen, neu anlegen, Dump einspielen
mysql -h localhost -u NEXTCLOUD_DBUSER -p -e "DROP DATABASE NEXTCLOUD_DB"
mysql -h localhost -u NEXTCLOUD_DBUSER -p -e "CREATE DATABASE NEXTCLOUD_DB CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci"
mysql -h localhost -u NEXTCLOUD_DBUSER -p NEXTCLOUD_DB < /backup/nextcloud-sqlbkp_DATUM.bak

Ist das Backup älter als die letzten Änderungen der Benutzer, kann nach dem Zurückspielen occ maintenance:data-fingerprint helfen, damit Clients den Abgleich korrekt behandeln. Beachte die Hinweise in der Dokumentation, denn der Befehl kann Konfliktdialoge auslösen.

ABGRENZUNG

Docker, AIO und Snap: andere Wege

📦

Docker

Hier zählen Image, Containerkonfiguration und persistente Volumes. Lege den Image-Tag bewusst fest, statt latest zu verwenden, und folge der Anleitung des eingesetzten Images.

☁

Nextcloud AIO

AIO verwaltet seine Komponenten über eine eigene Update-Logik. Nutze die offiziellen AIO-Schritte und keine Archiv-Installation im Container.

🔧

Snap

Bei Snap läuft die Aktualisierung über den Snap-Mechanismus mit eigener Dokumentation.

Merke: Nicht die Nextcloud-Version allein entscheidet über den Update-Weg, sondern auch die Installationsart.

FAZIT

Gut vorbereitet, dann ist das Upgrade unspektakulär

Entscheidend sind ein aktueller Stand von Nextcloud 34, ein System, das die Anforderungen von Nextcloud 35 erfüllt, geprüfte Apps und ein getestetes Backup. Mit dem Updater auf der Kommandozeile ist das Upgrade selbst schnell erledigt. Die Zeit steckt in der Vorbereitung, und gerade bei älteren Debian- und Ubuntu-Systemen ist die PHP-Version der Punkt, der am häufigsten überrascht.

Da Nextcloud 34 bis Juni 2027 unterstützt wird, musst du nichts überstürzen. Plane den Wechsel lieber in Ruhe, teste auf einer Kopie und nimm dir ein Wartungsfenster.

QUELLEN

Offizielle Quellen

Nextcloud-Upgrade nicht selbst durchführen?

Backup, Testkopie, PHP-Umstellung und Wartungsfenster sind Aufwand. Sprechen Sie uns an, wir unterstützen bei Planung und Durchführung.

Der Beitrag Nextcloud 34 auf 35 aktualisieren: Schritt für Schritt per Kommandozeile erschien zuerst auf RDDZ.

PHP2Shell: Über 34 Millionen PHP-Dienste melden noch betroffene Versionen – was die Zahlen bedeuten

dennis_rddz — Fri, 23 Oct 2026 18:17:37 +0000

SICHERHEIT · PHP · STAND 23.10.2026

PHP2Shell: Über 34 Millionen PHP-Dienste melden noch betroffene Versionen – was die Zahlen bedeuten

Das öffentliche Censys-Dashboard zeigt auch zwei Tage nach der Veröffentlichung der korrigierten Versionen mehr als 34 Millionen PHP-Dienste, die eine Version aus dem betroffenen Bereich melden. Das sind keine 34 Millionen nachweislich hackbaren Server, aber ein deutliches Zeichen, wie schwer sich eine Korrektur über die gesamte Webinfrastruktur verteilt.

CENSYS · ABRUF 23.10.2026

● Momentaufnahme

34,3 Mio.

melden betroffene Version

7,1 Mio.

auf korrigierte Version gewechselt

49,7 Mio.

ohne sichtbare Version

PHP 7.4.33ca. 6,43 Mio.

PHP 8.1.34ca. 2,05 Mio.

PHP 5.2.6ca. 1,56 Mio.

PHP 5.6.40ca. 1,52 Mio.

PHP 8.0.30ca. 1,16 Mio.

Gemeldete Versionen, keine bestätigte Verwundbarkeit. Backports bleiben von außen unsichtbar.

✓ Zahlen aus dem öffentlichen Censys-Dashboard

✓ Die Werte sind eine Obergrenze

✓ Alte PHP-Zweige als Kernproblem

✓ Gründe für den Patch-Rückstand

DIE ZAHLEN

Millionen Dienste melden weiterhin betroffene Versionen

Die Sicherheitsforscher von Censys erfassen weltweit öffentlich erreichbare PHP-Dienste, deren gemeldete Version im betroffenen Bereich für PHP2Shell (CVE-2026-109618 und CVE-2026-109619) liegt. Die korrigierten Versionen erschienen am 21. Oktober. Trotzdem zeigt das öffentliche Live-Dashboard auch am 23. Oktober noch einen enormen Bestand. Es verfolgt, wie sich die Zahl der erfassten Dienste seit Bekanntwerden der Lücken verändert, und wird laut Censys stündlich aktualisiert.

Beim Abruf am 23. Oktober 2026 zeigte das Dashboard diese Werte:

Kennzahl	Erfasster Stand
Seit Beginn der Erfassung mit betroffener Version gesehen	41.400.836 Dienste
Bei der jüngsten Erfassung weiterhin mit betroffener Version	34.280.868 Dienste
Seit Beginn auf eine als korrigiert erkannte Version gewechselt	7.128.257 Dienste
PHP-Dienste ohne öffentlich erkennbare Versionsangabe	49.695.981 Dienste

Die Werte sind eine Momentaufnahme und verändern sich mit jeder neuen Erfassung. Auch Änderungen an der Erkennung können dazu führen, dass Dienste neu eingeordnet werden.

Rund 34,3 von 41,4 Millionen sind etwa 83 Prozent der Dienste, die seit Beginn als betroffen erkannt wurden. Umgekehrt haben gut 17 Prozent auf eine korrigierte Version gewechselt. Beides ist eine Orientierung anhand der Zähler, keine exakte Patchquote: Neu entdeckte Dienste, verzögerte Scans und geänderte Erkennung beeinflussen die Werte. Außerdem liegen erst zwei Tage zwischen Release und Abruf.

EINORDNUNG

Warum das nicht 34 Millionen verwundbare Server sind

📦

Dienste sind keine Server

Censys zählt Dienste, nicht einzelne physische Server oder Betreiber. Ein Host kann viele Websites und Dienste auf verschiedenen Ports bereitstellen.

🔧

Backports bleiben unsichtbar

Linux-Distributionen können Korrekturen zurückportieren, ohne die gemeldete Versionsnummer anzuheben. Die versionsbasierte Zählung ist laut Censys deshalb eine Obergrenze der möglichen Betroffenheit.

❓

Ohne Version heißt nicht sicher

Fast 50 Millionen Dienste verraten ihre Version nicht. Sie dürfen weder automatisch als verwundbar noch als sicher eingestuft werden.

Die Daten sind keine vollständige Schwachstellenprüfung. Sie sind ein deutlicher Hinweis darauf, wie groß die öffentlich sichtbare Angriffsfläche ist.

ALTE ZWEIGE

Besonders problematisch: PHP 7.4 und älter

Im Dashboard gehören diese Versionsstände zu den am häufigsten gemeldeten:

PHP 7.4.33: rund 6,43 Millionen Dienste
PHP 8.1.34: rund 2,05 Millionen Dienste
PHP 5.2.6: rund 1,56 Millionen Dienste
PHP 5.6.40: rund 1,52 Millionen Dienste
PHP 8.0.30: rund 1,16 Millionen Dienste

Diese Zahlen beziehen sich auf gemeldete Versionsstände und beweisen nicht, dass jedes dieser Systeme ungepatcht ist. Zur Zeile PHP 5.2.6: Laut Forschern und Censys beginnt der betroffene Bereich bei PHP 5.4. Das Dashboard zählt diese Version offenbar trotzdem mit, die Einordnung hängt also an dessen Methode.

Für PHP 8.2 bis 8.5 gibt es reguläre korrigierte Releases. PHP 8.2 wird allerdings nur noch bis zum 31. Dezember 2026 mit Sicherheitsupdates versorgt. PHP 8.1 und ältere Zweige liegen außerhalb des Upstream-Supports, für 7.4, 8.0 und 8.1 existieren nur Quellcode-Backports, und Distributionen oder Supportanbieter liefern teils eigene Korrekturen. Für PHP 5.4 bis 7.3 gibt es laut Censys keinen Fixpfad mehr.

Wer eine solche Version betreibt, kann deshalb nicht einfach das nächste offizielle PHP-Update installieren. Oft ist eine Migration auf einen unterstützten Zweig nötig, und das ist in gewachsenen Umgebungen der schwierigere Teil.

URSACHEN

Warum sind nach dem Fix noch so viele Systeme betroffen?

Die Censys-Auswertung liefert dafür keine vollständige Erklärung, denn sie zeigt den Zustand der Dienste, nicht die Abläufe ihrer Betreiber. Es gibt aber plausible Gründe, die nicht für jeden einzelnen Eintrag gelten müssen:

Ein PHP-Update ist nicht nur ein Paketupdate

In produktiven Umgebungen hängt PHP an Webserver, PHP-FPM-Pools, CMS, Plugins, Frameworks und eigenen Anwendungen. Updates werden deshalb oft erst getestet und in Wartungsfenstern ausgerollt. Bei einer kritischen Lücke braucht es dann aber eine Zwischenmaßnahme und einen klaren Zeitplan.

Unklar, wo überall PHP läuft

PHP kann in mehreren Versionen parallel, über PHP-FPM oder in Container-Images und Drittanbieterprodukten laufen. Ein korrigiertes Hostpaket hilft nicht, wenn ein Container seine eigene Runtime mitbringt.

Alte Anwendungen blockieren die Migration

Alte Frameworks und Erweiterungen sind oft nicht mit aktuellen PHP-Versionen kompatibel. Ein Wechsel von 7.4 auf 8.4 ist dann kein Routineeingriff. Eine nur mit einem ungepflegten Zweig lauffähige Anwendung muss modernisiert, isoliert oder ersetzt werden.

Hosting-Plattformen vergrößern den Aufwand

Auf Hostingplattformen laufen viele Websites mit unterschiedlichen Anforderungen und mehreren parallelen PHP-Runtimes. Betreiber müssen die tatsächlich genutzten Runtimes erfassen und sicherstellen, dass die Prozesse die neuen Versionen verwenden.

Der Patchstand ist von außen unklar

Eine alte Versionsnummer kann bereits einen Backport enthalten. Umgekehrt belegt eine neue Nummer nicht, dass jede Runtime und jeder Prozess aktualisiert wurde. Ein Teil des scheinbaren Rückstands kann deshalb an der externen Erkennung liegen.

Es wäre falsch, jeden Eintrag als nachlässigen Administrator zu bezeichnen. Genauso falsch wäre es, die Zahlen mit diesem Hinweis abzutun.

AUSWIRKUNG

Die eigentliche Gefahr: was danach passiert

PHP2Shell betrifft die Verarbeitung von Webanfragen in der PHP-Laufzeit. Unter geeigneten Bedingungen kann ein nicht authentifizierter Angreifer Code im Kontext des Webserver- oder PHP-Prozesses ausführen. Das ist nicht automatisch eine vollständige Übernahme des Servers: Welche Rechte ein Angreifer erhält und wie weit er sich bewegen kann, hängt von Berechtigungen, Isolation und Konfiguration ab. Möglich sind etwa das Sammeln von Systeminformationen, der Start weiterer Programme oder eine Webshell als späterer Zugang.

Zur tatsächlichen Ausnutzung hat Censys mehrere widersprüchliche Meldungen zusammengetragen. Amazon beobachtete Versuche in Honeypots seit dem 17. Oktober, watchTowr meldet Versuche gegen beide Lücken, VulnCheck sah einen erfolglosen Webshell-Versuch. Andere Stellen, darunter das Canadian Centre for Cyber Security, meldeten bis zum 21. Oktober keine aktive Ausnutzung, und beide CVEs standen laut Censys am 22. Oktober nicht im CISA-Katalog bekannter ausgenutzter Schwachstellen. Die Lage ist deshalb anhand der einzelnen Quellen und ihrer Zeitstempel zu beurteilen.

Wer eine betroffene Version öffentlich erreichbar betrieben hat, sollte bei Verdachtsmomenten auch auf mögliche Kompromittierung prüfen. Wie das geht, zeigt unser Beitrag PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab.

MASSNAHMEN

Was Betreiber daraus mitnehmen

Die Auswertung ist ein guter Anlass, die eigene PHP-Landschaft zu erfassen, statt sich an einer öffentlichen Zahl zu orientieren. Die konkreten Schritte, korrigierten Versionen und Praxisbefehle stehen im PHP2Shell-Hauptbeitrag. Drei Punkte sind hier besonders wichtig:

Alte Zweige nicht ignorieren

Bei PHP 7.4 und älter klären, ob ein bestätigter Backport existiert. Sonst eine Migration auf einen unterstützten Zweig einplanen. Dass ein Zweig seit Jahren ohne sichtbare Probleme läuft, macht ihn nicht sicher.

Fixstand der Plattform prüfen

Bei distributionsverwalteten Systemen zählen die Sicherheitsmeldungen und Paketstände des Anbieters. Ein zurückportierter Fix kann vorhanden sein, auch wenn die Versionsnummer abweicht.

Nicht auf die Statistik warten

Censys kann die weltweite Exposition schätzen, aber nicht die eigene Inventarisierung ersetzen. Verlässlich sind die eigenen Paketstände und die tatsächlich laufenden Runtimes.

BEI RDDZ

Was wir bei RDDZ daraus ableiten

Wir bieten bei RDDZ aktuell nur noch PHP ab Version 8.3 an. Ältere Zweige, wie sie in der Censys-Auswertung ein großer Teil des Bestands sind, gehören damit nicht zu unserem aktuellen Angebot.

Die Auswertung zeigt zugleich, warum die Frage nach dem Patchstatus nicht bei einer einzelnen Versionsnummer enden darf. In komplexeren Umgebungen müssen zusätzliche PHP-Runtimes, Container und Anwendungen berücksichtigt werden, und der Zustand einer öffentlich sichtbaren Runtime sagt nicht automatisch etwas über alle Komponenten eines Hosts aus.

Wichtig ist uns eine klare Trennung: Ein Sicherheitsupdate behebt die bekannte Schwachstelle in der korrigierten Runtime, ist aber kein rückwirkender Beweis dafür, dass ein System vorher nicht angegriffen wurde. Die öffentlichen Zahlen belegen außerdem nicht, dass ein bestimmter Anbieter oder eine bestimmte Infrastruktur kompromittiert ist. Sie sind ein ernstes Signal dafür, wie groß die Aufgabe ist, kritische Updates im gesamten Web zeitnah umzusetzen.

FAZIT

Das Problem ist größer als ein einzelner PHP-Patch

Mehr als 34 Millionen öffentlich erfasste PHP-Dienste melden laut Censys weiterhin eine Version aus dem betroffenen Bereich, und fast 50 Millionen weitere geben ihre Version nicht preis. Der hohe Anteil alter PHP-Zweige zeigt, dass es nicht nur um die Geschwindigkeit von Updates geht: Ein Teil der Webinfrastruktur hängt an Anwendungen und Laufzeiten, für die Sicherheitsupdates nicht mehr selbstverständlich verfügbar sind.

Die Zahlen dürfen nicht als garantiert verwundbare Server missverstanden werden. Die zentrale Aussage bleibt trotzdem: Eine Korrektur kann an einem Tag erscheinen, bis sie in Millionen Installationen, Containern und Hosting-Plattformen wirksam ist, dauert es deutlich länger. Entscheidend ist nicht, ob ein Patch existiert, sondern ob er auf jedem relevanten System angekommen ist und dort läuft.

QUELLEN

Quellen und weiterführende Informationen

Wissen Sie, welche PHP-Version Ihre Website nutzt?

Alte PHP-Zweige, Container und mehrere Runtimes sind schnell übersehen. Sprechen Sie uns an, wir unterstützen bei Bestandsaufnahme, Migration und Betrieb.

Der Beitrag PHP2Shell: Über 34 Millionen PHP-Dienste melden noch betroffene Versionen – was die Zahlen bedeuten erschien zuerst auf RDDZ.

PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab

dennis_rddz — Thu, 22 Oct 2026 21:16:55 +0000

SICHERHEIT · PHP · STAND 22.10.2026

PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab

Die kritischen PHP-Schwachstellen PHP2Shell (CVE-2026-109618 und CVE-2026-109619) sind öffentlich bekannt, Sicherheitsanbieter berichten von Ausnutzungsversuchen. Wer inzwischen aktualisiert hat, sollte noch eine Frage klären: Gibt es Hinweise darauf, dass vor dem Update bereits jemand versucht hat, die Lücken auszunutzen? Wir zeigen, welche Spuren sich prüfen lassen, welche Befehle helfen und wo die Grenzen liegen.

SPURENSUCHE · PHP2SHELL

● Erste Orientierung

17.10.2026

Frühester beobachteter Versuch

3 Stufen

Exploit, Versuch, Erfolg

Mehrere

Datenquellen kombinieren

Webserver-Logs● Body oft nicht geloggt

PHP-Fehlerlogs● Fehler auch ohne Angriff

Prozesse● nur Momentaufnahme

Dateien● Zeitstempel manipulierbar

Netzwerk● nur aktueller Zustand

Jede Quelle hat Grenzen. Erst das Zusammenspiel liefert belastbare Hinweise.

✓ Praxisbefehle für Debian und Ubuntu

✓ Prüfzeitraum ab 17. Oktober 2026

✓ Mit ehrlichen Grenzen der Analyse

✓ Vorgehen bei konkretem Verdacht

LAGE

Was ist über tatsächliche Angriffsversuche bekannt?

Ein erfolgreiches Update behebt die bekannte Schwachstelle in der aktualisierten PHP-Laufzeit. Es kann aber nicht rückwirkend ausschließen, dass ein Angreifer vorher bereits Code ausgeführt, Dateien verändert oder weitere Zugänge eingerichtet hat. Die Hintergründe zu den Schwachstellen und den korrigierten Versionen findest du in unserem PHP2Shell-Hauptbeitrag.

PHP2Shell umfasst zwei kritische Schwachstellen im PHP-Kern. Unter bestimmten Voraussetzungen kann ein nicht authentifizierter Angreifer darüber Code auf einem verwundbaren System ausführen. Am 21. Oktober 2026 wurden die korrigierten PHP-Versionen veröffentlicht.

Amazon Threat Intelligence berichtet von einem Ausnutzungsversuch gegen die eigene Honeypot-Infrastruktur bereits am 17. Oktober sowie von weiteren Aktivitäten am 21. Oktober. Die ersten öffentlich kursierenden Proofs of Concept tauchten laut Amazon noch am 21. Oktober gegen 02:00 UTC auf, also vor der Veröffentlichung der Updates um 14:00 UTC. Das PHP-Projekt erklärte laut Tenable allerdings, in den ihm bekannten PoCs zum Zeitpunkt der Veröffentlichung keine funktionsfähigen Exploits gefunden zu haben. Die Funktionsfähigkeit einzelner Codes ist also nicht unabhängig bestätigt, und angeblicher Exploit-Code im Netz kann selbst Schadsoftware enthalten.

Es geht damit nicht mehr nur um eine theoretische Angriffsmöglichkeit, denn es gibt konkrete Berichte über Versuche. Allerdings müssen drei Dinge auseinandergehalten werden:

Ein Exploit ist verfügbar

Ein technischer Ansatz zur Ausnutzung ist beschrieben oder im Umlauf. Ob konkreter Code funktioniert, ist damit noch nicht gesagt.

Ein Angriff wurde beobachtet

Ein System hat eine Anfrage oder Aktivität erkannt, die mit dem Exploit zusammenhängt. Das beweist keine erfolgreiche Kompromittierung.

Ein Angriff war erfolgreich

Es gibt belastbare Hinweise, dass tatsächlich Code ausgeführt oder das System kompromittiert wurde.

Diese Aussagen sind nicht gleichbedeutend. Umgekehrt lässt sich eine frühere Kompromittierung nicht allein deshalb ausschließen, weil keine offensichtlichen Fehlermeldungen gefunden werden.

SCHRITT 1

Zuerst feststellen, welche Systeme betroffen waren

Bevor Logs ausgewertet werden, sollte klar sein, welche PHP-Installationen überhaupt exponiert waren. Dabei reicht es nicht, nur den Hauptwebserver zu betrachten. PHP kann auf einem System in mehreren Versionen und Betriebsarten installiert sein, und Anwendungen können ihre eigene Runtime mitbringen. Relevant sind insbesondere:

PHP-FPM hinter Nginx oder Apache
Apache mit mod_php
php-cgi
PHP innerhalb von Docker-Containern
PHP-basierte Verwaltungsoberflächen
Drittanbieterprodukte mit integrierter PHP-Laufzeit
ältere Anwendungen auf nicht mehr unterstützten PHP-Versionen

Die PHP-Sicherheitsmeldung nennt diese Betriebsarten ausdrücklich. Besonders kritisch ist laut PHP die Konfiguration mit Apache mod_php, weil ein präparierter Request die Schwachstelle auslösen kann, bevor der eigentliche Anwendungscode ausgeführt wird.

🔍

Installierte Versionen und Prozesse

Auf Debian und Ubuntu liefern diese Befehle eine erste Übersicht:

Bash

php -v

dpkg -l | grep -E 'php[0-9.]|php-fpm|libapache2-mod-php'

ps -eo pid,ppid,user,lstart,args \
  | grep -E '[p]hp-fpm|[p]hp-cgi|[a]pache2|[h]ttpd'

Wichtig: php -v zeigt die Version der PHP-CLI. Diese muss nicht der Version entsprechen, die eine Website tatsächlich verwendet. Auch Paketlisten reichen nicht, um PHP in Containern oder Drittanbieterprodukten zu erfassen.

📦

Docker

Zeigt zunächst nur laufende Container und deren Images:

Bash

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

Ob und welche PHP-Version enthalten ist, muss anschließend innerhalb der jeweiligen Runtime oder anhand des Images geprüft werden, etwa mit docker exec php -v.

SCHRITT 2

Webserver-Logs auf auffällige Requests untersuchen

Ein wichtiger Ansatzpunkt sind die HTTP-Zugriffe. Bei PHP2Shell sind insbesondere POST-Anfragen mit multipart/form-data relevant, das Format, das etwa bei Datei-Uploads verwendet wird. Außerdem ist das Feld PHP_SESSION_UPLOAD_PROGRESS von Interesse: Amazon Threat Intelligence empfiehlt ausdrücklich, nach POST-Anfragen zu suchen, die dieses Feld enthalten, und Webserver-Logs auf verdächtige Aktivitäten zu prüfen.

Das bedeutet nicht, dass jede solche Anfrage bösartig ist. Uploads gehören bei vielen Anwendungen zum normalen Betrieb. Entscheidend sind Kontext, Häufigkeit, Aufbau der Anfrage und mögliche Folgeaktivitäten.

Die Grenze klassischer Access-Logs

Klassische Access-Logs enthalten die HTTP-Methode, den Pfad, den Statuscode und die Antwortgröße, aber weder den Content-Type noch den Inhalt des Request-Bodys. Ein einfacher Textfilter nach multipart/form-data findet dort deshalb nichts, und ein Filter nach POST liefert auf aktiven Websites Tausende Treffer. Wenn der Inhalt einer Anfrage nicht protokolliert wurde, kann ein einfacher Textfilter den Angriff nicht erkennen.

Systeme mit zentraler Protokollierung, vorgeschaltetem Reverse Proxy, CDN oder Web Application Firewall müssen gegebenenfalls an mehreren Stellen untersucht werden.

🔒

POST-Anfragen mit Serverfehler

Als grobe Orientierung lassen sich POST-Anfragen herausfiltern, die mit HTTP 500 endeten. Das Beispiel geht vom üblichen Combined-Log-Format aus, bei dem der Statuscode das neunte Feld ist:

Bash

sudo zgrep -h '"POST ' \
  /var/log/nginx/access.log* \
  /var/log/apache2/access.log* 2>/dev/null \
  | awk '$9 == 500' | head -50

Ein Treffer ist kein Beweis, Treffer häufen sich aber auch bei fehlerhaften Anwendungen. Abweichende Log-Formate müssen angepasst werden.

🔍

Nach PHP_SESSION_UPLOAD_PROGRESS suchen

Das funktioniert nur dort, wo Request-Bodys oder WAF-Ereignisse protokolliert werden, etwa in ModSecurity-Audit-Logs (Pfad je nach Setup) oder in einer vorgeschalteten WAF:

Bash

sudo zgrep -Ein \
  'PHP_SESSION_UPLOAD_PROGRESS' \
  /var/log/nginx/* \
  /var/log/apache2/* \
  2>/dev/null

Ein Treffer ist ein Anlass zur näheren Untersuchung, kein Beweis. Ein fehlender Treffer ist keine Entwarnung, denn bei nicht geloggtem Body kann der Begriff schlicht nicht vorkommen.

SCHRITT 3

PHP- und Webserver- Fehlerlogs prüfen

Beide Schwachstellen betreffen interne Abläufe in PHP. Deshalb können Fehler rund um die Verarbeitung einer Anfrage Hinweise liefern, zum Beispiel:

Auffällige Häufungen von Speicherfehlern und Meldungen über Speichererschöpfung
Ungewöhnliche Abstürze oder Segmentation Faults
Neustarts von PHP-FPM-Workern
Wiederholte HTTP-500-Antworten
Ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies (Hinweis von Wiz)
Zeitlich auffällige Kombinationen aus HTTP-Anfragen und PHP-Fehlern

Solche Ereignisse sind nicht automatisch ein Angriff. Speicherfehler können auch durch reguläre Last, fehlerhafte Anwendungen oder zu knapp konfigurierte Ressourcen entstehen. Umgekehrt weist Datadog darauf hin, dass erfolgreiche Ausnutzung den Worker nicht zwingend zum Absturz bringt. Fehlende Fehlermeldungen sind deshalb keine Entwarnung.

📜

Systemmeldungen durchsuchen

Auf Systemen mit systemd lassen sich die vergangenen Tage so untersuchen. Den Zeitraum bitte an den tatsächlichen Untersuchungszeitraum anpassen:

Bash

sudo journalctl \
  --since "2026-10-17 00:00:00" \
  --until "2026-10-22 23:59:59" \
  | grep -Ei \
  'php|php-fpm|out of memory|memory exhausted|segfault|fatal error'

📁

Eigene Logdateien nicht vergessen

PHP kann Fehler auch in eigene Dateien schreiben. Auf Debian und Ubuntu liegen die Logs von PHP-FPM meist unter /var/log/php-fpm.log (zum Beispiel /var/log/php8.4-fpm.log), bei Apache mit mod_php landen PHP-Fehler im Apache-Error-Log, etwa /var/log/apache2/error.log.

Der genaue Speicherort hängt von der Konfiguration (error_log) ab und sollte pro System geprüft werden.

Worauf kommt es bei der Auswertung an?

Ein einzelner PHP-Fehler ist noch kein Nachweis einer Kompromittierung. Verdächtiger wäre eine zeitliche Abfolge aus (1) einer ungewöhnlichen POST-Anfrage, (2) einem auffälligen PHP-Fehler, (3) dem Start eines bislang nicht beobachteten Prozesses und (4) einer unerwarteten Dateiänderung oder ausgehenden Netzwerkverbindung. Eine solche Kette ist ein Ansatzpunkt für eine Incident-Response-Untersuchung und sollte anhand der vorhandenen Daten verifiziert werden.

SCHRITT 4

Prüfen, ob PHP ungewöhnliche Prozesse gestartet hat

Eine erfolgreiche Remote-Code-Ausführung kann dazu führen, dass ein PHP-Prozess weitere Programme startet. Deshalb lohnt sich ein Blick auf die Prozesshierarchie. Auch die Erkennungsansätze etwa von Elastic setzen genau hier an: Auffällig sind Shells, Skript-Interpreter oder Download-Werkzeuge (curl, wget), die von PHP-FPM oder einem Webserver-Prozess gestartet werden, sowie Programme, die aus /tmp, /dev/shm oder dem Webroot laufen. Aufklärungsbefehle wie id, whoami oder uname -a unter dem Webserver-Benutzer sind ebenfalls ein Warnsignal. Sie können in legitimen Anwendungen vorkommen und müssen im Kontext des Dienstes bewertet werden.

Bash

ps -eo pid,ppid,user,lstart,args --forest

Achte auf unerwartete Kindprozesse von PHP-FPM oder Apache, Prozesse unter dem Webserver-Benutzer, die nicht zum Betrieb gehören, unbekannte Skripte oder ausführbare Dateien, ungewöhnliche Prozessketten und Prozesse, deren Startzeit zu verdächtigen HTTP-Anfragen passt.

Der Befehl zeigt nur eine Momentaufnahme: Bereits beendete Prozesse erscheinen nicht mehr. Wer vor dem Angriff keine Prozessaktivitäten protokolliert hat, kann einen beendeten Prozess normalerweise nicht allein durch eine nachträgliche Abfrage rekonstruieren. Hilfreicher sind historische Daten aus Prozessüberwachung, Audit-Protokollierung oder einem Endpoint-Detection-System, sofern sie schon vor dem Vorfall aktiv waren.

SCHRITT 5

Webverzeichnisse auf unerwartete Änderungen prüfen

Wenn ein Angreifer Code ausführen konnte, könnte er Dateien verändert oder zusätzliche Skripte abgelegt haben. Untersucht werden sollten insbesondere Webroots und Upload-Verzeichnisse, Verzeichnisse mit PHP-Skripten, temporäre Verzeichnisse, vom Webserver beschreibbare Verzeichnisse sowie Konfigurationsdateien und geplante Aufgaben. Dabei sind reguläre Änderungen durch Deployments, CMS-Updates, Uploads und Wartung von unbekannten Änderungen zu unterscheiden.

📄

Kürzlich veränderte Dateien

Für ein Webverzeichnis unter /var/www lassen sich Skripte suchen, die seit dem 17. Oktober geändert wurden. Das ist genauer als ein relativer Zeitraum wie -mtime -7, der mit jedem Tag verrutscht:

Bash

sudo find /var/www -type f \
  \( -name '*.php' -o -name '*.phtml' \) \
  -newermt '2026-10-17' -ls

⏰

Geplante Aufgaben

Neue Cron-Einträge können auf Persistenz hinweisen:

Bash

ls -la /etc/cron.d /var/spool/cron/crontabs

Besonders prüfenswert sind unbekannte PHP-Dateien, unerwartete Änderungen an vorhandenen Skripten sowie neue Dateien in Verzeichnissen, in denen normalerweise keine ausführbaren Skripte liegen. Eine große Trefferliste ist bei aktiv betriebenen Websites normal, vergleiche sie deshalb mit bekannten Deployments, Paketupdates und Backups.

Was dieser Dateicheck nicht leisten kann

Ein Angreifer kann Dateien verändern, Zeitstempel beeinflussen oder Code an vorhandene Dateien anhängen. Umgekehrt erzeugen normale Updates viele legitime Änderungen. Der Befehl ist deshalb nur eine erste Bestandsaufnahme. Belastbarer sind bekannte Sollzustände, Versionskontrolle, vertrauenswürdige Backups oder Integritätsprüfungen.

SCHRITT 6

Ausgehende Netzwerkverbindungen untersuchen

Ein kompromittierter Webserver könnte versuchen, weitere Systeme zu erreichen, Daten zu übertragen oder zusätzliche Dateien abzurufen. Deshalb sollte geprüft werden, ob PHP-Prozesse oder andere Prozesse unter dem Webserver-Benutzer ungewöhnliche ausgehende Verbindungen aufbauen.

Bash

sudo ss -tpn

Der Befehl zeigt aktuelle TCP-Verbindungen und, soweit verfügbar, die zugehörigen Prozesse. Auch hier gilt: Es ist nur der aktuelle Zustand, eine bereits beendete Verbindung lässt sich damit nicht nachweisen. Für eine rückwirkende Untersuchung sind vorhandene Firewall-, DNS-, Proxy-, NetFlow- oder EDR-Protokolle wesentlich wertvoller. Ein Webserver kann außerdem durch reguläre API-Aufrufe, Updates oder externe Dienste legitime Verbindungen aufbauen, auffällige Verbindungen müssen deshalb im Zusammenhang mit Prozessen und dem jeweiligen Dienst bewertet werden.

ZEITRAUM

Den Zeitraum vor dem Patch nicht vergessen

Wer am 21. Oktober oder später aktualisiert hat, sollte bei einer rückwirkenden Untersuchung nicht nur die Zeit nach dem Update betrachten. Amazon Threat Intelligence hat einen Ausnutzungsversuch bereits am 17. Oktober 2026 beobachtet und empfiehlt, Untersuchungen ab diesem Datum zu beginnen. Je nach Systemhistorie kann ein sinnvoller erster Prüfzeitraum deshalb bis zum 17. Oktober zurückreichen, bei konkreten Hinweisen auch weiter. Angreifer könnten eine Schwachstelle außerdem schon vor der öffentlichen Bekanntgabe gekannt haben.

Eine sinnvolle Zeitleiste umfasst:

den Zeitraum vor der öffentlichen Veröffentlichung,
den Tag der Veröffentlichung und der Verfügbarkeit von Exploits,
den Zeitpunkt der eigenen Aktualisierung,
die Zeit nach dem Update, falls weiterhin verdächtige Aktivitäten auftreten.

Die Grenzen sind klar: Wenn Logs bereits rotiert wurden, Request-Bodys nicht protokolliert wurden oder keine Prozessüberwachung existierte, kann die rückwirkende Prüfung unvollständig bleiben.

VERDACHT

Was tun bei einem konkreten Verdacht?

Wenn mehrere Indikatoren zusammenpassen, sollte die Untersuchung nicht bei einzelnen Shell-Befehlen enden.

Beweise sichern

Webserver-, PHP-, System-, Firewall- und Sicherheitslogs sichern. Zeitstempel, betroffene Systeme und auffällige Ereignisse dokumentieren. Vorschnelle Bereinigungen vermeiden, sie können Beweise zerstören.

System bewerten und isolieren

Ist eine erfolgreiche Kompromittierung wahrscheinlich, das System nach einem geeigneten Incident-Response-Verfahren isolieren und dabei die Auswirkungen auf produktive Dienste berücksichtigen.

Nicht nur nach Schadsoftware suchen

Ein Angreifer muss keine dauerhafte Datei hinterlassen. Auch Prozesse, Benutzerkonten, SSH-Zugänge, geplante Aufgaben, Dienste, Konfigurationsänderungen und ausgehende Verbindungen gehören in die Untersuchung.

Zugangsdaten und Geheimnisse bewerten

Bei bestätigter oder stark vermuteter Kompromittierung prüfen, welche Zugangsdaten, Tokens oder API-Schlüssel das System erreichen konnte. Je nach Befund ist eine Rotation nötig.

Wiederherstellung nicht mit Patchen verwechseln

Ein Sicherheitsupdate behebt die bekannte Schwachstelle. Bei bestätigter Kompromittierung müssen zusätzlich unerwünschte Änderungen und Persistenzmechanismen beseitigt werden. In schwerwiegenden Fällen kann ein Neuaufbau aus einem vertrauenswürdigen Zustand sicherer sein, als nur verdächtige Dateien zu löschen.

GRENZEN

Warum es keine einfache Entwarnung gibt

Die beschriebenen Prüfungen liefern Hinweise, aber keine universelle Garantie. Angriffsspuren können in Webserver-Logs fehlen, weil der Request-Body nicht protokolliert wurde. Laut Wiz laufen die Schwachstellen unterhalb der Anwendungsebene, Anwendungslogs zeigen deshalb oft wenig. Prozessinformationen gehen verloren, wenn keine historischen Daten aufgezeichnet wurden, und Dateien können verändert oder entfernt worden sein, bevor die Untersuchung beginnt.

Umgekehrt können legitime Uploads, PHP-Fehler und reguläre Deployments einzelne Indikatoren auslösen, ohne dass ein Angriff stattgefunden hat. Die beste Bewertung entsteht aus mehreren unabhängigen Datenquellen: HTTP-Zugriffen, PHP-Fehlern, Prozessaktivitäten, Dateiänderungen, Netzwerkdaten und bekannten Änderungen am System.

Liegen konkrete Hinweise auf eine Kompromittierung vor, ist eine strukturierte Incident-Response-Untersuchung sinnvoller als der Versuch, mit einem einzelnen Befehl Sicherheit zu beweisen.

BEI RDDZ

Was wir bei RDDZ empfehlen

Wir haben unsere Systeme am 21. Oktober 2026 um 18:00 Uhr gepatcht. Das war der entscheidende Schritt, um die bekannten Schwachstellen in den aktualisierten Umgebungen zu beheben. Eine rückwirkende Prüfung auf frühere Ausnutzung ist davon getrennt zu betrachten.

Wir empfehlen Betreibern deshalb, nicht nur die installierten PHP-Versionen zu kontrollieren, sondern auch die vor dem Update verfügbaren Protokolle und Systeminformationen zu prüfen. Bei öffentlich erreichbaren Systemen sollten insbesondere ungewöhnliche HTTP-Anfragen, auffällige PHP-Fehler, unerwartete Prozesse und unbekannte Dateiänderungen untersucht werden.

Ein erfolgreiches Update ist notwendig. Eine belastbare Aussage über eine mögliche frühere Kompromittierung erfordert jedoch eine separate Untersuchung.

FAZIT

Patchen ist der Anfang, nicht die gesamte Untersuchung

PHP2Shell zeigt, wie schnell eine kritische Schwachstelle in einer weit verbreiteten Laufzeitumgebung zu einem praktischen Sicherheitsproblem werden kann. Die verfügbaren Updates sollten unverzüglich installiert werden. Zusätzlich lohnt sich eine rückwirkende Prüfung, insbesondere wenn Systeme vor dem Patch öffentlich erreichbar waren und relevante Logs noch vorhanden sind.

Webserver- und PHP-Logs, Prozessaktivitäten, Dateisystemänderungen und ausgehende Netzwerkverbindungen liefern zusammen mögliche Hinweise auf einen Angriff. Keine dieser Quellen reicht für sich allein aus, um eine Kompromittierung sicher nachzuweisen oder auszuschließen. Wer verdächtige Aktivitäten findet, sollte die Hinweise sichern, zeitlich korrelieren und bei konkretem Verdacht eine strukturierte Incident-Response-Untersuchung durchführen.

QUELLEN

Weiterführende Quellen

Verdacht auf einen Angriff oder Hilfe bei der Prüfung?

Logs, Prozesse und Dateien sauber auswerten ist Aufwand. Sprechen Sie uns an, wir unterstützen bei Prüfung, Absicherung und Betrieb.

Der Beitrag PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab erschien zuerst auf RDDZ.

PHP2Shell: Kritische PHP-Sicherheitslücken gefährden Websites und Server

dennis_rddz — Wed, 21 Oct 2026 15:55:39 +0000

SICHERHEIT · PHP · UPDATE 22.10.2026

PHP2Shell: Kritische PHP-Sicherheitslücken gefährden Websites und Server

Zwei kritische Sicherheitslücken im PHP-Kern sorgen für Alarm: PHP2Shell, geführt als CVE-2026-109618 und CVE-2026-109619. Unter bestimmten Voraussetzungen können Angreifer aus der Ferne und ohne Anmeldung Code auf einem verwundbaren System ausführen. Betroffen sind PHP-Versionen ab 5.4, also auch viele ältere Installationen.

PHP2SHELL · 2 CVES

● Updates seit 21.10.2026

9,2

CVSS 4.0, kritisch

Ohne Login

Remote-Codeausführung

ab 5.4

Betroffene Versionen

PHP 8.5 ✓ 8.5.12

PHP 8.4 ✓ 8.4.27

PHP 8.3 ✓ 8.3.36

PHP 8.2 ✓ 8.2.35

PHP 8.1 und älter ● kein Upstream-Fix

Entscheidend: korrigierte Version installieren, PHP-Prozesse neu starten und prüfen, was tatsächlich läuft.

✓ Korrigierte PHP-Versionen seit 21. Oktober 2026

✓ Betroffen: mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed

✓ Kein vollständiger Schutz ohne Update

✓ Mit Praxisbefehlen und Übergangsmaßnahmen

UPDATE 22.10.2026

Neue Erkenntnisse zur Angriffslage

Seit unserer ursprünglichen Veröffentlichung liegen weitere technische Informationen zu PHP2Shell vor. Die Sicherheitslücken CVE-2026-109618 und CVE-2026-109619 sind inzwischen genauer dokumentiert. Außerdem haben Sicherheitsforscher und Sicherheitsorganisationen ihre Einschätzungen zur möglichen Ausnutzung veröffentlicht.

Die wichtigste Nachricht bleibt: Die PHP-Projektseite stellt korrigierte Versionen bereit, und betroffene Systeme sollten aktualisiert werden. Darüber hinaus sollten Betreiber prüfen, ob ihre Systeme bereits vor der Aktualisierung verdächtige Aktivitäten gezeigt haben.

Was ist inzwischen über mögliche Angriffe bekannt?

Sicherheitsforscher haben die Schwachstellen technisch untersucht, und es sind Berichte zu Exploit-Ansätzen im Umlauf. Das PHP-Projekt erklärte laut Tenable allerdings, in den ihm bekannten Proof-of-Concepts zum Zeitpunkt der Veröffentlichung keine funktionsfähigen Exploits gefunden zu haben. Angeblicher Exploit-Code im Netz sollte nicht unbesehen ausgeführt werden, er kann selbst Schadsoftware enthalten.

Zu tatsächlichen Angriffen unterscheiden sich die Berichte: Amazon Threat Intelligence meldet erste Angriffsversuche gegen sein Honeypot-Netz bereits am 17. Oktober 2026, also rund vier Tage vor der Veröffentlichung, und weitere Versuche am 21. Oktober von offenbar mehreren Akteuren. watchTowr berichtet von aktiven Ausnutzungsversuchen, Cloudflare von Angriffsverkehr gegen Kundensysteme. Ob die Versuche bei echten Systemen erfolgreich gewesen wären, ist nach Angaben von Amazon offen. Ein bestätigter erfolgreicher Angriff auf ein konkretes produktives System ist uns nicht bekannt.

Ein öffentlich verfügbarer Exploit, ein erfolgreicher Test im Labor und ein bestätigter Angriff auf ein produktives System sind drei unterschiedliche Dinge. Für Betreiber bedeutet das: Die Gefahr sollte nicht unterschätzt werden. Aus den bisherigen Meldungen lässt sich aber auch nicht ableiten, dass jeder verwundbare Server tatsächlich angegriffen wurde.

🔧

Warum die verwendete PHP-Umgebung wichtig ist

Die Sicherheitslücken betreffen die PHP-Laufzeit selbst und nicht nur ein bestimmtes Content-Management-System oder Plugin. Deshalb reicht es nicht, ausschließlich WordPress, TYPO3 oder eine andere Anwendung zu aktualisieren.

Laut dem PHP-Projekt sind unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed relevant. Das PHP-Team stuft insbesondere Apache-Konfigurationen mit mod_php als risikoreich ein: Ein präparierter Request kann dort die Schwachstelle auslösen, bevor der eigentliche Anwendungscode ausgeführt wird.

Auch PHP-Runtimes, die in Containern, Verwaltungsoberflächen oder Drittanbieterprodukten gebündelt sind, müssen separat berücksichtigt werden. Ein aktualisiertes PHP-Paket auf dem Host bedeutet nicht automatisch, dass jede mitgelieferte Runtime ebenfalls korrigiert ist.

📦

Neuer Stand bei den Distributionen

Seit der ersten Veröffentlichung sind weitere Korrekturen erschienen. Laut den Herstellerseiten (Stand 22.10.2026):

Debian 12 Bookworm: 8.2.35-1~deb12u1 (DLA-4848-1)
Debian 13 Trixie: 8.4.27-1~deb13u1 (DSA-6574-1)
Ubuntu 22.04 LTS und 24.04 LTS: korrigierte Pakete (USN-8948-1 und USN-8948-2)
Debian Unstable/Testing: zum Prüfzeitpunkt noch nicht korrigiert

Details stehen im Abschnitt „Korrigierte Versionen“ weiter unten.

Gepatcht bedeutet nicht automatisch, dass es vorher keinen Angriff gab

Wir haben unsere Systeme am 21. Oktober 2026 um 18:00 Uhr auf den korrigierten Stand gebracht. Damit haben wir die notwendigen Aktualisierungen zeitnah nach Veröffentlichung der Sicherheitskorrekturen umgesetzt.

Ein Patch schließt die bekannte Schwachstelle in der aktualisierten Runtime. Er kann jedoch nicht rückwirkend ausschließen, dass ein System vor dem Update bereits angegriffen wurde oder dass ein Angreifer zuvor Dateien, Konten oder andere Zugänge verändert hat. Amazon empfiehlt deshalb, Untersuchungen nicht erst ab dem Tag der Veröffentlichung zu beginnen, sondern ab dem 17. Oktober 2026, dem frühesten bekannten Angriffsversuch.

Bei einem konkreten Verdacht sind zusätzlich die verfügbaren Webserver- und PHP-Logs, Prozessaktivitäten und Dateiänderungen zu untersuchen. Auffälligkeiten müssen zeitlich eingeordnet und mit regulären Deployments sowie Wartungsarbeiten abgeglichen werden. Umgekehrt gilt auch: Wenn keine verdächtigen Einträge gefunden werden, ist das allein noch kein Beweis dafür, dass es keinen Angriff gab.

Zum Zeitpunkt dieser Aktualisierung liegen uns keine Erkenntnisse vor, die wir als Beleg für eine erfolgreiche Ausnutzung auf unseren Systemen veröffentlichen könnten. Das ist ausdrücklich keine allgemeine Garantie, dass eine frühere Ausnutzung allein durch das Einspielen eines Updates ausgeschlossen wäre.

Was Administratoren jetzt zusätzlich prüfen sollten

Neben dem Update der PHP-Runtime empfehlen wir, die eigene Umgebung systematisch zu kontrollieren:

Alle PHP-Runtimes erfassen: Dazu gehören auch alternative PHP-Versionen, PHP-FPM-Pools, Container und in Drittanbieterprodukten gebündelte Laufzeiten.
Laufende Version kontrollieren: Prüfen, ob die korrigierte Version tatsächlich von den Webanwendungen verwendet wird und ob betroffene Prozesse nach dem Update neu gestartet wurden.
Webserver- und PHP-Logs prüfen: Auffällige Requests, ungewöhnliche Fehlerhäufungen und zeitlich zusammenhängende Ereignisse können Ansatzpunkte für eine Untersuchung liefern. Einzelne HTTP-Fehler sind für sich genommen kein Beweis für einen Angriff.
Prozesse und Dateien kontrollieren: Ungewöhnliche Kindprozesse von PHP oder dem Webserver, unerwartete Skripte im Webverzeichnis, neue geplante Aufgaben oder unbekannte Dienste sollten untersucht werden.
Bei konkretem Verdacht Beweise sichern: Logs und relevante Systeminformationen sollten gesichert werden, bevor Bereinigungsmaßnahmen Spuren verändern. Bei belastbaren Hinweisen sollte das betroffene System nach einem geeigneten Incident-Response-Verfahren isoliert und untersucht werden.

Ausführliche Anleitung: Wie du Logs, Prozesse, Dateien und Netzwerkverbindungen prüfst, welche Befehle helfen und wo die Grenzen liegen, zeigen wir in unserem Folgebeitrag PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab.

Es gibt keine einzelne Logzeile und keinen einfachen Test, der zuverlässig beweist, dass PHP2Shell ausgenutzt wurde oder nicht. Die Bewertung muss mehrere Datenquellen und den konkreten Aufbau des Systems berücksichtigen.

Fazit des Updates

PHP2Shell bleibt eine kritische Sicherheitsmeldung, die eine schnelle Aktualisierung und eine sorgfältige Prüfung der betroffenen Umgebungen erfordert. Die korrigierten PHP-Versionen sind verfügbar; zusätzlich sollten Betreiber mögliche frühere Angriffe nicht allein deshalb ausschließen, weil das Update inzwischen installiert ist.

Wir unterscheiden dabei bewusst zwischen der Behebung der bekannten Schwachstelle und der separaten Frage, ob es vor dem Update Hinweise auf eine Ausnutzung gab.

EINORDNUNG

Was ist passiert?

Besonders brisant: Die Schwachstellen liegen im PHP-Laufzeitsystem selbst, nicht in einem einzelnen Plugin oder einer einzelnen Website. Damit können Webserver, Content-Management-Systeme und Anwendungen betroffen sein, bei denen PHP im Hintergrund läuft.

📅

20. Oktober 2026: Vorankündigung

Das PHP-Projekt kündigt ein außerplanmäßiges Sicherheitsupdate für zwei kritische Schwachstellen an. Zuvor waren Hinweise auf die Lücken vorzeitig öffentlich aufgetaucht, die Veröffentlichung wurde deshalb vorgezogen.

✅

21. Oktober 2026: Details und Updates

Das PHP-Projekt veröffentlicht die Details und die korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Schweregrad und Ausnutzung

Das PHP-Projekt bewertet beide Schwachstellen mit CVSS 4.0 9,2 (kritisch). Auch CERT-EU und das BSI nennen 9,2. Die Bewertung weist darauf hin, dass für einen Angriff weder eine Anmeldung noch eine Interaktion eines Nutzers nötig ist.

Zur Ausnutzung hat sich die Lage seit der Veröffentlichung weiterentwickelt. Die aktuellen Erkenntnisse fassen wir im Update vom 22. Oktober 2026 weiter oben zusammen.

Der Name PHP2Shell ist ein griffiger Begriff aus der Sicherheitsbranche, den das PHP-Projekt selbst nicht verwendet. Technisch maßgeblich sind die beiden CVE-Nummern.

DIE SCHWACHSTELLEN

Zwei Fehler im PHP-Kern

💥

CVE-2026-109618: Speichermangel

Wenn PHP während der Vorbereitung eines Requests nicht genug Speicher hat, kann der Request abgebrochen werden, obwohl interne Daten noch nicht vollständig initialisiert sind. Die anschließende Bereinigung behandelt diese Daten dann, als wären sie gültig. Das kann zu einer Speicherbeschädigung und im Ergebnis zu Codeausführung führen.

Das PHP-Projekt hat die Ausnutzung ohne Anmeldung über HTTP gegen mod_php mit Standardeinstellungen bestätigt.

🔄

CVE-2026-109619: veralteter Zustand

Interner Zustand eines Requests kann erhalten bleiben, obwohl der zugehörige Speicher bereits freigegeben wurde. Eine spätere Anfrage desselben Workers kann diesen veralteten Zustand verwenden, bevor er zurückgesetzt wird.

Mögliche Folgen sind Codeausführung mit den Rechten des Webserver-Prozesses und das Auslesen von Speicherinhalten, etwa Zugangsdaten oder Tokens aus anderen Requests.

Die genauen Voraussetzungen unterscheiden sich, deshalb muss nicht jede Installation auf identische Weise betroffen sein. Besonders hoch ist das Risiko laut PHP-Projekt bei Apache mit mod_php. Aber auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed müssen überprüft werden.

BETROFFENE VERSIONEN

Sind wirklich 20 Jahre PHP betroffen?

Der mögliche Versionsbereich reicht sehr weit zurück. Wiz und Sansec nennen PHP-Versionen ab 5.4 bis einschließlich 8.5.11 als betroffen. CERT-EU sprach in seiner Meldung allgemein von PHP ab Version 5. Das umfasst einen Zeitraum von etwa zwei Jahrzehnten.

Das heißt nicht, dass jede jemals veröffentlichte PHP-Version heute noch läuft oder auf gleiche Weise aktualisiert werden kann. Wichtig ist die Unterscheidung zwischen betroffen, noch unterstützt und bereits korrigiert:

Für die unterstützten Zweige PHP 8.2 bis 8.5 hat das PHP-Projekt Updates veröffentlicht. PHP 8.2 wird nur noch bis zum 31. Dezember 2026 mit Sicherheitsupdates versorgt.
Für PHP 8.1 und älter gibt es vom PHP-Projekt keine regulären Updates. Für 7.4, 8.0 und 8.1 hat das Sicherheitsteam allerdings minimale Quellcode-Backports bereitgestellt, gedacht für Nutzer, die PHP selbst bauen und keinen LTS-Anbieter haben.
Einige Linux-Distributionen und LTS-Anbieter liefern eigene Korrekturen. Ob eine konkrete Installation abgesichert ist, muss anhand des Paketstands und des Anbieters geprüft werden.

Gerade bei älteren Websites, gewachsenen Kundenprojekten und Anwendungen, die seit Jahren unverändert laufen, lohnt sich deshalb ein genauer Blick auf die eingesetzte PHP-Version.

KORRIGIERTE VERSIONEN

Welche PHP-Versionen schließen die Lücken?

Das PHP-Projekt hat am 21. Oktober 2026 diese Versionen veröffentlicht. Sie beheben CVE-2026-109618 und CVE-2026-109619:

PHP-Zweig	Korrigierte Version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Wer PHP selbst kompiliert oder über eigene Runtime-Images bereitstellt, muss sicherstellen, dass die korrigierte Version tatsächlich in das laufende System übernommen wird. Das gilt auch für Container, deren Image neu gebaut und ausgerollt werden muss.

🌀

Debian: Korrigierte Pakete verfügbar

Bei Debian kann die Korrektur in einem eigenen Paket stecken, dessen Versionsnummer von der Upstream-Version abweicht. Laut Debian Security Tracker (Stand 22.10.2026) gilt:

Debian 13 Trixie: PHP 8.4 ist mit 8.4.27-1~deb13u1 korrigiert (DSA-6574-1)
Debian 12 Bookworm: PHP 8.2 ist mit 8.2.35-1~deb12u1 korrigiert (DLA-4848-1)
Debian Unstable/Testing: PHP 8.4 war zum Prüfzeitpunkt noch nicht korrigiert

Der Stand kann sich ändern. Maßgeblich ist der Debian Security Tracker.

💡

Ubuntu: Korrekturen für unterstützte Releases

Ubuntu stuft CVE-2026-109618 mit der Priorität „Critical“ ein und hat am 21. Oktober 2026 die Sicherheitshinweise USN-8948-1 und USN-8948-2 veröffentlicht. Laut Ubuntu Security (Stand 22.10.2026) gibt es Korrekturen unter anderem für:

Ubuntu 22.04 LTS: PHP 8.1 mit 8.1.2-1ubuntu2.28
Ubuntu 24.04 LTS: PHP 8.3 mit 8.3.6-0ubuntu0.24.04.13
Ältere Releases (20.04 und früher): nur über Ubuntu Pro (ESM) bzw. Legacy Support

Maßgeblich ist die Seite Ubuntu Security.

📦

Drittanbieter-Repositories

Das ehrenamtlich gepflegte Repository rpms.remirepo.net wird zum Release keine Updates haben. Das PHP-Projekt empfiehlt in solchen Fällen Distributionspakete oder einen Build aus dem Quellcode.

Wer PHP über ein Drittanbieter-Repository, ein Hosting-Panel oder ein fertiges Image bezieht, sollte beim jeweiligen Anbieter den Stand erfragen.

BETROFFENE ANWENDUNGEN

Welche Websites und Anwendungen können betroffen sein?

PHP steckt in zahlreichen Content-Management-Systemen, Webanwendungen und Diensten. Auch wenn die Anwendung selbst aktuell ist, kann eine verwundbare PHP-Laufzeit ein Risiko darstellen. Dazu können beispielsweise gehören:

WordPress-Websites und deren Backend
Drupal-, Joomla- und TYPO3-Installationen
Nextcloud- und ownCloud-Umgebungen
MediaWiki und DokuWiki
Shopsysteme und individuell entwickelte PHP-Anwendungen
PHP-basierte Dienste in Docker-Containern
Weitere Webanwendungen, die PHP-FPM, mod_php oder eine andere betroffene Laufzeit verwenden

Die Liste ist nicht vollständig. Entscheidend ist, welche PHP-Version eine Anwendung tatsächlich verwendet und wie sie bereitgestellt wird. Ein Update des CMS allein reicht nicht, solange der PHP-Prozess eine verwundbare Version ausführt. Bei Containern muss zusätzlich das Image aktualisiert und die Anwendung damit neu bereitgestellt werden.

MASSNAHMEN

Was Betreiber jetzt tun sollten

Die Sicherheitsmeldungen empfehlen, betroffene Installationen unverzüglich zu aktualisieren. Ist das nicht sofort möglich, sollten öffentlich erreichbare Anwendungen bis zur Korrektur möglichst vom Netz genommen oder in ihrer Erreichbarkeit eingeschränkt werden.

Alle PHP-Installationen erfassen

Nicht nur der Hauptwebserver zählt. Auch zusätzliche PHP-FPM-Pools, alternative PHP-Versionen, Container, Verwaltungsoberflächen, Hosting-Panels und ältere Kundenanwendungen müssen berücksichtigt werden.

Tatsächlich verwendete Version prüfen

Die PHP-Version auf der Kommandozeile muss nicht der Version entsprechen, die eine Website über PHP-FPM oder Apache nutzt. Maßgeblich ist die Runtime, die den Webanfragen zugeordnet ist.

Sicherheitsupdate einspielen

Für unterstützte Upstream-Zweige stehen die oben genannten Releases bereit. Bei distributionsverwalteten Installationen die Updates des jeweiligen Anbieters verwenden.

Prozesse und Container neu starten

Ein installiertes Paket bedeutet nicht, dass alle laufenden Prozesse die korrigierte Version nutzen. Je nach Bereitstellung müssen PHP-FPM, Apache oder Container neu gestartet bzw. neu ausgerollt werden.

Ergebnis kontrollieren

Nach der Aktualisierung prüfen, welche Version tatsächlich läuft. Bei mehreren Hosts oder getrennten Umgebungen darf die Prüfung nicht auf einem einzelnen System enden.

Veraltete Versionen gesondert behandeln

Bei PHP 8.1 oder älter klären, ob ein bestätigter Backport des Anbieters verfügbar ist. Ist das nicht der Fall, eine Migration auf einen unterstützten Zweig einplanen.

PRAXIS

Praxisbefehle: Welche PHP-Version läuft wirklich?

Die Befehle sind Beispiele für Debian/Ubuntu-Systeme mit Paketinstallation. Bitte an die eigene Umgebung anpassen (PHP-Version, Dienstnamen) und Neustarts nur nach Wartungsplanung durchführen.

🔍

Installierte Versionen finden

Zeigt die CLI-Version und alle installierten PHP-Pakete. Die CLI-Version sagt noch nichts über die Webumgebung:

Bash

php -v
dpkg -l | grep -E '^ii\s+php'
ls /usr/sbin/php-fpm* 2>/dev/null

🖥

Laufende Webprozesse prüfen

Zeigt, welche PHP-Prozesse tatsächlich laufen, und ob sie noch das alte Binary nutzen. Steht hinter dem Pfad „(deleted)“, läuft der Prozess noch mit der Version vor dem Update:

Bash

ps aux | grep -E 'php-fpm|apache2|httpd' | grep -v grep
ls -l /proc/$(pgrep -o php-fpm)/exe
apache2ctl -M 2>/dev/null | grep -i php

🔄

Update einspielen und Dienste neu starten

Beispiel für PHP 8.4 mit PHP-FPM. Dienstnamen je nach Version und Setup anpassen:

Bash

apt update
apt list --upgradable 2>/dev/null | grep -i php
apt full-upgrade

# Dienste neu starten (nur nach Wartungsplanung):
systemctl restart php8.4-fpm
systemctl restart apache2   # bzw. nginx

# Prozesse mit veralteten Bibliotheken anzeigen:
needrestart

📦

Container prüfen

Zeigt, welche Container laufen und welche PHP-Version darin verwendet wird. Ein reines Update im Host reicht nicht, das Image muss neu gebaut und der Container neu gestartet werden:

Bash

docker ps --format '{{.Names}}  {{.Image}}'
docker exec  php -v

ÜBERGANGSMASSNAHMEN

Wenn ein Update nicht sofort möglich ist

Das PHP-Projekt stellt klar: Es gibt keinen vollständigen Schutz außer dem Update. Die folgenden Punkte verringern höchstens die Angriffsfläche und ersetzen die Aktualisierung nicht. Datadog weist zudem darauf hin, dass die Einstellung session.upload_progress.enabled=0 gegen CVE-2026-109618 nicht schützt. Maßnahmen sollten vor dem Einsatz geprüft werden, weil sie Nebenwirkungen haben können.

Für CVE-2026-109619

session.upload_progress.enabled=0 in php.ini, im FPM-Pool oder in der Serverkonfiguration setzen und alle Worker neu starten. ini_set() und .user.ini genügen dafür nicht.
Bei PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen und die Worker neu starten. Das blockiert nur einen bestätigten Pfad.

Für CVE-2026-109618

Anfragegrößen begrenzen, etwa post_max_size und upload_max_filesize, sowie auf dem Webserver oder Proxy die Zahl der Felder, Multipart-Teile und Header.
Das PHP-Projekt nennt außerdem memory_limit=-1 (vorzugsweise per php_admin_value) in Kombination mit einer Container- oder cgroup-Begrenzung, die nur den betroffenen Worker beendet. RLIMIT_AS und RLIMIT_DATA sollten nicht verwendet werden, weil sie den verwundbaren Fehlerfall auslösen können.

Zusätzlich

Nicht patchbare Anwendungen vom Internet trennen oder hinter VPN bzw. eine Web Application Firewall stellen. Einige Anbieter wie Cloudflare haben erste WAF-Regeln für bekannte Angriffswege bereitgestellt.

ERKENNUNG

Woran man einen Angriff erkennen könnte

Die Lücken liegen unterhalb der Anwendungsebene, Anwendungslogs zeigen deshalb oft wenig. Hinweise können laut Wiz und Huntress sein:

Ungewöhnliche Multipart-Anfragen, auf die Fehlermeldungen zum Speicherlimit folgen
Wiederholte HTTP-500-Antworten und ungewöhnlicher Neustart-Wechsel bei PHP-Workern
Ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies
Formular-Uploads (POST-Requests), die die Zeichenfolge PHP_SESSION_UPLOAD_PROGRESS enthalten (Hinweis von Amazon Threat Intelligence)
PHP-Worker oder Webserver-Prozesse, die Shells, Interpreter oder Download-Werkzeuge starten
Neue Dateien im Webroot, unerwartete Cron-Jobs oder neue Benutzerkonten

Bei einem Verdacht: System isolieren, Web- und PHP-Logs sichern und auf Webshells prüfen. Die Auswertung sollte nicht allein auf einem erfolgreichen Update beruhen, weil eine Kompromittierung schon vorher erfolgt sein kann.

BEI RDDZ

Was wir bei RDDZ unternommen haben

Wir haben unsere Systeme am 21. Oktober 2026 um 18:00 Uhr auf den korrigierten Stand gebracht.

Dabei betrachten wir nicht nur die offensichtlichen Webanwendungen, sondern auch die darunterliegenden Laufzeitumgebungen. PHP kann direkt auf einem Host, in einer getrennten Runtime oder innerhalb eines Containers installiert sein. Eine einzelne Aktualisierung deckt deshalb nicht automatisch jede Anwendung ab.

Das Einspielen der Korrektur ersetzt nicht die Frage, ob es vor dem Update Hinweise auf eine Ausnutzung gab. Dazu mehr im Update weiter oben. Bei produktiven Systemen prüfen wir nach Updates außerdem den ordnungsgemäßen Betrieb der Anwendungen.

FAZIT

Jetzt aktualisieren, nicht auf den Wartungstermin warten

PHP2Shell ist kein gewöhnliches Update-Thema. Die beiden kritischen Schwachstellen CVE-2026-109618 und CVE-2026-109619 können unter bestimmten Voraussetzungen eine Codeausführung ohne Anmeldung ermöglichen. Der große Versionsbereich und der Einsatz von PHP in unzähligen Webanwendungen machen eine systematische Prüfung wichtig.

Die korrigierten Versionen stehen bereit. Betreiber sollten ihre PHP-Runtimes und Anwendungen unverzüglich prüfen, passende Updates installieren und sicherstellen, dass die korrigierte Version tatsächlich läuft. Bei alten oder nicht mehr unterstützten Installationen muss zusätzlich geklärt werden, ob eine belastbare Sicherheitskorrektur verfügbar ist, oder eine Migration auf einen unterstützten Zweig anstehen.

QUELLEN

Weiterführende Quellen

PHP-Server und Webseiten sicher betreiben?

PHP-Versionen, Updates und Neustarts nicht allein im Blick behalten? Sprechen Sie uns an, wir unterstützen bei Betrieb, Wartung und Absicherung.

Der Beitrag PHP2Shell: Kritische PHP-Sicherheitslücken gefährden Websites und Server erschien zuerst auf RDDZ.

PwnEscape (CVE-2026-99999): Wenn eine virtuelle Maschine den Linux-Host gefährden kann

dennis_rddz — Tue, 20 Oct 2026 14:29:20 +0000

SICHERHEIT · LINUX-KERNEL · STAND 20.10.2026

PwnEscape (CVE-2026-99999): Wenn eine virtuelle Maschine den Linux-Host gefährden kann

Eine Sicherheitslücke im Linux-Kernel sorgt derzeit für Aufmerksamkeit: PwnEscape, geführt unter CVE-2026-99999, kann unter bestimmten Voraussetzungen dazu genutzt werden, aus einer virtuellen Maschine auf den zugrunde liegenden Host zuzugreifen. Betroffen sein können damit ausgerechnet Systeme, deren Aufgabe es ist, voneinander getrennte Umgebungen bereitzustellen.

PWNESCAPE · CVE-2026-99999

● CVE seit 15.10.2026

9,3

CVSS 3, kritisch

IPv4

Linux-Kernel

Gast → Host

KVM, virtio

Proxmox VE ✓ Kernel 7.0.14-24

Debian ✓ Fix für 12 und 13

Ubuntu ● Status prüfen

Entscheidend: korrigierten Host-Kernel installieren, neu starten und prüfen, ob er läuft.

✓ CVE veröffentlicht am 15. Oktober 2026

✓ Proxmox-Fix seit 16. Oktober 2026

✓ Korrigierte Debian-Kernel für 12 und 13

✓ Ubuntu: Status direkt prüfen

✓ Mit Praxisbefehlen für die Host-Prüfung

EINORDNUNG

Eine ernst zu nehmende Meldung für Virtualisierungshosts

Für Betreiber virtualisierter Server ist das eine ernst zu nehmende Meldung. Entscheidend ist allerdings nicht allein die Schwere der Schwachstelle, sondern auch, wie schnell die verfügbaren Korrekturen eingespielt werden.

Proxmox hat bereits einen korrigierten Kernel bereitgestellt. Auch Debian führt behobene Kernelpakete. Bei Ubuntu ist der Status der betroffenen Pakete gesondert zu prüfen.

Was steckt hinter PwnEscape?

PwnEscape betrifft die Verarbeitung von IPv4-Netzwerkpaketen im Linux-Kernel. Vereinfacht gesagt kann eine fehlerhafte Prüfung von Metadaten zur Prüfsummenberechnung dazu führen, dass der Kernel beim Verarbeiten eines Pakets Speicher beschädigt.

Das Problem ist deshalb besonders relevant, weil Netzwerkpakete auch innerhalb virtualisierter Umgebungen verarbeitet werden. Unter den entsprechenden Voraussetzungen kann ein Angreifer aus einer virtuellen Maschine heraus versuchen, die Sicherheitsgrenze zum Host zu überwinden. Die Proxmox-Sicherheitsmeldung beschreibt den Angriffsweg über den virtio-Netzwerkstack, die Forscher von PWNAI Research zeigen ihn in einem eigenen KVM-Testaufbau.

Die möglichen Folgen reichen von einem Absturz des Systems über das Offenlegen von Speicherinhalten bis hin zur Ausführung von Code mit weitreichenden Rechten auf dem Host. Der konkrete Erfolg eines Angriffs hängt allerdings von den jeweiligen technischen Voraussetzungen und der betroffenen Umgebung ab. Die Veröffentlichung bedeutet nicht, dass jede virtuelle Maschine auf jedem Linux-Host automatisch kompromittiert werden kann.

Die Schwachstelle wurde am 15. Oktober 2026 als CVE-2026-99999 veröffentlicht. In der CVSS-Version 3 wird sie mit einem Schweregrad von 9,3 von 10 – kritisch bewertet. Hersteller können für ihre jeweiligen Produkte zu abweichenden Bewertungen kommen, weil sie unterschiedliche Rahmenbedingungen berücksichtigen.

Technische Hintergründe finden sich in der Linux-Kernel-Sicherheitsmeldung und in der Analyse der Sicherheitsforscher.

⚖

Kritisch bewertet, aber nicht überall gleich

Der CVSS-Wert liegt bei 9,3. Ubuntu führt die CVE dennoch mit der Priorität „Medium“. Das zeigt, wie unterschiedlich Hersteller die Lücke für ihre Pakete einstufen.

🛡

Korrektur als Zusatzschutz

Der Upstream-Fix prüft checksum_start, bevor die Prüfsumme berechnet wird. Debian und Ubuntu beschreiben ihn als zusätzliche Schutzmaßnahme (Defense in Depth). Eine umfassendere Validierung beim Empfang ist laut den Angaben noch in Arbeit.

🔍

Keine Ausnutzung bei Anbietern behauptet

Die Forscher behaupten ausdrücklich keine Ausnutzung bei Produktionsanbietern. Ihre Angriffe zeigen sie in eigenen Testaufbauten.

VIRTUALISIERUNG

Warum die Lücke für Virtualisierung besonders relevant ist

Bei einem virtualisierten Server laufen mehrere voneinander getrennte Systeme auf derselben physischen Hardware. Der Hypervisor und der Host-Kernel übernehmen dabei eine zentrale Rolle: Sie stellen die Ressourcen bereit und setzen die Trennung zwischen den virtuellen Maschinen und dem Host durch. Genau diese Trennung ist bei einer möglichen Guest-to-Host-Schwachstelle der entscheidende Punkt.

Kann ein Angreifer aus einer Gast-VM heraus eine Schwachstelle im Host-Kernel ausnutzen, betrifft das nicht mehr nur das einzelne Gastsystem. Im ungünstigsten Fall könnte auch die darunterliegende Infrastruktur gefährdet sein. Je nach Umgebung wären damit weitere virtuelle Maschinen auf demselben Host betroffen.

Das macht PwnEscape für Betreiber von Virtualisierungsplattformen und für alle relevant, die eigene virtuelle Server betreiben. Die Sicherheitslücke ist jedoch kein Beleg dafür, dass sämtliche KVM-Systeme oder jede Proxmox-Installation gleichermaßen angreifbar sind. Entscheidend sind unter anderem der eingesetzte Kernel, der Patchstand und die konkreten Bedingungen der Umgebung.

DISTRIBUTIONEN

Proxmox, Debian und Ubuntu im Überblick

📦

Proxmox VE: Der korrigierte Kernel war schnell verfügbar

Für Betreiber von Proxmox VE gibt es bereits eine konkrete Korrektur. In der offiziellen Proxmox-Community wurde die Sicherheitsmeldung PSA-2026-00068-1 zu PwnEscape am 16. Oktober 2026 veröffentlicht.

Der Fix ist im Paket proxmox-kernel-7.0.14-24-pve sowie in der signierten Variante proxmox-kernel-7.0.14-24-pve-signed enthalten. Laut Proxmox-Team war das Paket zunächst im Repository pve-no-subscription verfügbar und sollte anschließend auch im Enterprise-Repository bereitgestellt werden. Ein Nutzer im Forum bestätigt es inzwischen auch dort.

Die CVE wurde am 15. Oktober offiziell veröffentlicht. Damit reagierte Proxmox sehr schnell und stellte die korrigierte Kernel-Version bereits kurz darauf bereit.

Wichtig ist dabei die Unterscheidung zwischen einem verfügbaren Update und einem tatsächlich aktualisierten Host: Ein Administrator muss sicherstellen, dass das passende Paket installiert ist und der Host anschließend mit dem korrigierten Kernel läuft. Ein bloßes Aktualisieren von Paketen garantiert nicht in jedem Fall, dass der neue Kernel bereits aktiv ist.

Ältere Installationen: Laut Proxmox-Team ist 7.0.14 die einzige aktuell unterstützte Kernel-Serie. Für Kernel-Serien, deren Support ausgelaufen ist, gibt es keine Updates. Das betrifft beispielsweise den Kernel 6.8 von Proxmox VE 8. Wer solche Hosts betreibt, sollte ein Upgrade auf eine unterstützte Version einplanen.

GPU-Treiber: Im Forum berichtet ein Nutzer, dass der NVIDIA-Treiber 615.78.08 auf dem Kernel 7.0.14-24-pve nicht kompiliert. Wer Treiber per DKMS einsetzt, sollte das Update vorher auf einem Testsystem prüfen.

Die offizielle Diskussion und die Angaben des Proxmox-Teams finden sich im Proxmox-Supportforum zur Sicherheitslücke.

🌀

Debian: Korrigierte Kernelpakete sind ausgewiesen

Debian ist für viele Server eine wichtige Grundlage – auch im Umfeld von Virtualisierung und Hosting. Der Debian Security Tracker weist für CVE-2026-99999 korrigierte Kernelpakete für mehrere Veröffentlichungszweige aus:

Debian 12 Bookworm: 6.1.190-1 im Security-Repository
Debian 13 Trixie: 6.12.113-1 im Security-Repository
Debian Testing beziehungsweise Unstable: korrigierte Pakete auf Basis von 7.2.11-1

Diese Angaben beziehen sich auf die vom Debian Security Tracker ausgewiesenen Paketstände. Bei Debian sollten Administratoren nicht einfach die Versionsnummer des unveränderten Linux-Kernels mit der installierten Paketversion vergleichen: Distributionen integrieren Sicherheitskorrekturen häufig in ihre eigenen Pakete und pflegen dafür entsprechende Paketversionen.

Die maßgebliche Anlaufstelle ist der Debian Security Tracker für CVE-2026-99999.

💡

Ubuntu: Den Status der eigenen Kernelpakete prüfen

Auch Ubuntu führt CVE-2026-99999 in seiner Sicherheitsdatenbank. Bei der Recherche am 20. Oktober 2026 war der Status für die dort aufgeführten Ubuntu-Versionen allerdings noch als „Needs evaluation“ angegeben.

Das ist kein Grund, die Meldung zu ignorieren. Es bedeutet vielmehr, dass sich aus diesem Eintrag zu diesem Zeitpunkt noch keine pauschale Aussage ableiten ließ, wonach für alle betroffenen Ubuntu-Versionen bereits ein korrigiertes Paket bereitsteht.

Wer Ubuntu auf einem Virtualisierungshost oder Server einsetzt, sollte deshalb den aktuellen Status der eigenen Version und des verwendeten Kernelpakets direkt bei Ubuntu kontrollieren. Dabei ist auch zu berücksichtigen, dass sich der Status nach Veröffentlichung einer Sicherheitsmeldung noch ändern kann.

Die offizielle Übersicht findet sich unter Ubuntu Security: CVE-2026-99999.

MASSNAHMEN

Was Administratoren jetzt tun sollten

Unabhängig von der verwendeten Distribution empfiehlt sich ein strukturierter Blick auf die eigenen Systeme. Dabei sollte vor allem der Host im Mittelpunkt stehen – nicht nur die virtuellen Maschinen.

Virtualisierungshosts inventarisieren

Zunächst sollte klar sein, welche physischen Systeme Linux als Host-Kernel verwenden und welche Virtualisierungsplattform dort läuft. Dazu gehören beispielsweise Proxmox VE und andere KVM-basierte Umgebungen.

Den Patchstand der Distribution prüfen

Maßgeblich sind die offiziellen Sicherheitsmeldungen und Paketversionen des jeweiligen Herstellers. Ein Vergleich allein anhand der Upstream-Kernelnummer reicht nicht immer aus, weil Distributionen Sicherheitskorrekturen zurückportieren können.

Korrigierte Pakete installieren

Sobald ein passendes Update für die eigene Distribution verfügbar ist, sollte es nach den üblichen Wartungs- und Freigabeprozessen eingespielt werden. Bei produktiven Hosts sind mögliche Auswirkungen auf laufende virtuelle Maschinen und die notwendige Wartungsplanung zu berücksichtigen.

Sicherstellen, dass der neue Kernel aktiv ist

Kernelupdates benötigen häufig einen Neustart, bevor der korrigierte Kernel tatsächlich läuft. Nach der Aktualisierung sollte deshalb kontrolliert werden, welcher Kernel aktiv ist und ob das System den erwarteten Patchstand erreicht hat.

Nicht nur die Gäste aktualisieren

Updates innerhalb einer virtuellen Maschine ersetzen nicht das Update des Host-Kernels. Die Sicherheitsgrenze, um die es bei PwnEscape geht, liegt zwischen Gast und Host. Deshalb muss die Korrektur auf dem betroffenen Host-System wirksam sein.

PRAXIS

Praxisbefehle: Welcher Kernel läuft auf dem Host?

Die folgenden Befehle sind Beispiele für die Prüfung. Bitte vor der Ausführung an die eigene Umgebung anpassen und produktive Hosts nur nach Wartungsplanung neu starten.

🔍

Laufenden Kernel prüfen

Zeigt, welcher Kernel tatsächlich läuft – unabhängig davon, was installiert ist:

Bash

uname -r
uname -v

Bei Debian enthält uname -v die Debian-Paketversion (z. B. 6.1.190-1) und lässt sich direkt mit dem Security Tracker vergleichen.

🖥

Proxmox VE

Installierte Kernel-Pakete prüfen, aktualisieren und nach dem Neustart kontrollieren:

Bash

pveversion -v | grep -i proxmox-kernel
apt update
apt full-upgrade
# Neustart nur nach Wartungsplanung:
# reboot

# Nach dem Neustart: sollte 7.0.14-24-pve zeigen
uname -r

Welches Repository genutzt wird (pve-no-subscription oder Enterprise), bestimmt, wann das Paket verfügbar ist.

💻

Debian und Ubuntu

Verfügbare Kernel-Updates anzeigen, einspielen und installierte Kernel auflisten:

Bash

apt update
apt list --upgradable 2>/dev/null | grep -i linux-image
apt full-upgrade
apt list --installed 'linux-image*'

# Falls installiert: prüft, ob ein Neustart wegen des Kernels nötig ist
needrestart -k

Bei Ubuntu zusätzlich den Status auf der Ubuntu-Sicherheitsseite kontrollieren, bevor man von einem verfügbaren Fix ausgeht.

🔄

Cluster: VMs vor dem Neustart verschieben

In einem Proxmox-Cluster lassen sich laufende VMs per Live-Migration auf einen bereits gepatchten Node verschieben, bevor der nächste Host neu startet:

Bash

qm migrate   --online

Ob das in der eigenen Umgebung funktioniert, hängt unter anderem von Storage und CPU-Kompatibilität ab. Vorher auf einer unkritischen VM testen.

BEI RDDZ

Was wir bei RDDZ unternommen haben

Sicherheitsmeldungen wie PwnEscape zeigen, warum es bei gemieteten oder selbst betriebenen Servern nicht ausreicht, Updates nur gelegentlich und ohne Blick auf ihre Bedeutung einzuspielen.

Wir haben unsere Host-Systeme im Zusammenhang mit dieser Schwachstelle überprüft und die verfügbare Kernel-Korrektur zeitnah nach der Veröffentlichung eingespielt.

Für Kunden ist dabei besonders wichtig, dass Sicherheitsmaßnahmen nicht an der Oberfläche enden. Bei einer Schwachstelle im Host-Kernel muss die zugrunde liegende Virtualisierungsinfrastruktur betrachtet werden – zusätzlich zu den Betriebssystemen und Anwendungen, die innerhalb der virtuellen Maschinen laufen.

Wie bei jeder Sicherheitslücke gilt: Eine zeitnahe Aktualisierung ist ein wesentlicher Schritt, ersetzt aber keine laufende Wartung und Überwachung. Wir behalten relevante Sicherheitsmeldungen deshalb im Blick und setzen notwendige Korrekturen auf unseren Systemen nach Verfügbarkeit und unter Berücksichtigung des jeweiligen Betriebsumfelds um.

FAZIT

Schnelle Updates sind entscheidend

PwnEscape ist ein gutes Beispiel dafür, dass Sicherheitslücken im Linux-Kernel auch die Isolation virtualisierter Systeme betreffen können. Die mögliche Auswirkung ist ernst, sollte aber nicht mit der pauschalen Behauptung verwechselt werden, jede KVM- oder Proxmox-Umgebung sei automatisch kompromittiert.

Die wichtigste Empfehlung für Betreiber eigener Server: Host-Kernel und Sicherheitsmeldungen der jeweiligen Distribution im Blick behalten, Updates zeitnah installieren und anschließend prüfen, ob der korrigierte Kernel tatsächlich aktiv ist. Die Befehle oben helfen dabei.

QUELLEN

Weiterführende Quellen

Eigene Server oder Proxmox-Hosts sicher betreiben?

Patchstand, Kernel-Updates und Wartungsfenster nicht allein im Blick behalten? Sprechen Sie uns an, wir unterstützen bei Betrieb, Wartung und Absicherung.

Der Beitrag PwnEscape (CVE-2026-99999): Wenn eine virtuelle Maschine den Linux-Host gefährden kann erschien zuerst auf RDDZ.

WG Tunnel Desktop: Mehr als nur ein WireGuard-Client für Windows, Linux und macOS

dennis_rddz — Mon, 19 Oct 2026 20:59:23 +0000

WG TUNNEL · DESKTOP · WINDOWS, LINUX, MACOS

WG Tunnel Desktop: Mehr als nur ein WireGuard-Client für Windows, Linux und macOS

Wer WireGuard nutzt, kennt das Prinzip: Konfiguration importieren, Verbindung einschalten, fertig. Für viele Einsatzzwecke reicht das völlig aus. Sobald man aber mehrere VPN-Verbindungen verwalten, den Datenverkehr gezielter steuern oder eine Verbindung beim Wechsel des Netzwerks automatisch anpassen möchte, stößt man mit einem einfachen VPN-Client schnell an Grenzen.

WG TUNNEL DESKTOP 2.4.1

● Seit 17.10.2026

MIT-Lizenz

Open Source

3 Plattformen

Windows, Linux, macOS

AmneziaWG

2.0 bis 3.1

Kill Switch ✓ systemweit

Auto-Tunneling ✓ nach Netzwerkbedingungen

Multihop ✓ seit Version 2.4.0

Lokaler Proxy ✓ HTTP, SOCKS4, SOCKS5

Kein VPN-Anbieter: Eine eigene WireGuard- oder AmneziaWG-Konfiguration wird weiterhin benötigt.

✓ Aktuell: Version 2.4.1 vom 17. Oktober 2026

✓ Open Source unter MIT-Lizenz

✓ Windows, Linux und macOS (Apple Silicon)

✓ Kill Switch, Auto-Tunneling, Proxy und DNS-Steuerung

✓ Mit Installationsanleitung für alle Plattformen

EINFÜHRUNG

Wenn ein einfacher Schalter nicht mehr reicht

Genau hier setzt WG Tunnel Desktop an. Das Open-Source-Projekt erweitert WireGuard um zahlreiche Funktionen, die man sonst eher aus umfangreicheren VPN-Lösungen kennt. Dazu gehören ein systemweiter Kill Switch, automatische Tunnelaktivierung, DNS-Steuerung, ein lokaler Proxy und inzwischen sogar Multihop-Verbindungen.

WG Tunnel ist übrigens kein neues Projekt. Die Android-App gibt es schon deutlich länger und sie hat sich dort mit zahlreichen Zusatzfunktionen etabliert. Mit der Desktop-Version bringt Entwickler Zane Schepke einen großen Teil dieses Funktionsumfangs auf den PC – inzwischen für Windows, Linux und macOS mit Apple Silicon.

Aktuell ist WG Tunnel Desktop 2.4.1, veröffentlicht am 17. Oktober 2026.

ÜBERBLICK

Was ist WG Tunnel Desktop eigentlich?

WG Tunnel Desktop ist ein alternativer, quelloffener Client für WireGuard und AmneziaWG. Die Anwendung verwendet weiterhin die bewährte VPN-Technik, ergänzt sie aber um Funktionen für Automatisierung, Sicherheit und komfortablere Verwaltung.

Das Projekt steht unter der MIT-Lizenz und wird auf GitHub entwickelt. Die Desktop-Version teilt sich wesentliche Teile ihrer Tunnel-, DNS- und Wiederherstellungslogik mit der Android-App. Dadurch kommen viele Funktionen, die man bisher vor allem vom Smartphone kannte, auch auf den Desktop.

Wichtige Unterscheidung

WG Tunnel ist kein eigener VPN-Anbieter und liefert nicht automatisch einen VPN-Server mit. Du benötigst weiterhin eine passende WireGuard- oder AmneziaWG-Konfiguration und einen erreichbaren VPN-Endpunkt – beispielsweise auf dem eigenen Router, einem Server zu Hause oder einem gemieteten VPS.

FUNKTIONEN

Diese Funktionen bringt WG Tunnel Desktop mit

Die Liste ist inzwischen ziemlich umfangreich. Nicht jede Funktion ist für jeden Nutzer notwendig. Gerade in Kombination können die einzelnen Möglichkeiten aber einen spürbaren Unterschied machen.

WireGuard und AmneziaWG

WG Tunnel unterstützt klassische WireGuard-Tunnel und AmneziaWG. AmneziaWG erweitert WireGuard um Möglichkeiten zur Verschleierung des Datenverkehrs, die in geeigneten Umgebungen helfen können, bestimmte Formen der Protokollerkennung zu umgehen.

Laut Projekt unterstützt die Desktop-Version AmneziaWG 2.0 bis 3.1. Ob das im eigenen Netzwerk einen Vorteil bringt, hängt unter anderem von der eingesetzten Gegenstelle und den jeweiligen Einschränkungen ab.

Auto-Tunneling: VPN automatisch aktivieren

Mit Auto-Tunneling lassen sich VPN-Verbindungen abhängig von den Eigenschaften des aktiven Netzwerks automatisch aktivieren. Die Desktop-Variante ist dabei etwas einfacher gehalten als die Android-Version.

Das ist beispielsweise praktisch, wenn ein Notebook im eigenen WLAN anders arbeiten soll als unterwegs oder in einem fremden Netzwerk. Statt jedes Mal manuell den richtigen Tunnel einzuschalten, kann WG Tunnel die Verbindung anhand der erkannten Netzwerkbedingungen verwalten.

Unter macOS wurde die WLAN-Erkennung in Version 2.4.1 weiter verbessert. Dafür benötigt die Anwendung entsprechende Standort- beziehungsweise WLAN-Berechtigungen.

Deferred Endpoint Bootstrapping: Schutz schon beim Start

Eine der interessantesten Funktionen steckt weniger in der Oberfläche als in der Art, wie WG Tunnel den Verbindungsaufbau behandelt. Viele VPN-Clients müssen zunächst die Adresse des Gegenübers auflösen, bevor der Tunnel vollständig gestartet werden kann. Wenn DNS gerade nicht funktioniert oder das Netzwerk langsam reagiert, kann sich der Aufbau verzögern.

WG Tunnel geht einen anderen Weg: Zunächst werden die Tunnel-Schnittstelle, Routen und Firewall-Regeln eingerichtet. Die Auflösung der Gegenstellen erfolgt anschließend im Hintergrund und wird bei Bedarf wiederholt.

Der Vorteil: Der Schutz soll nicht erst dann beginnen, wenn die Gegenstelle erfolgreich aufgelöst wurde. Das kann die Zeit verringern, in der der normale Netzwerkverkehr noch nicht durch den Tunnel geschützt ist. Das ist besonders interessant bei instabilen Verbindungen oder wenn ein VPN möglichst zuverlässig beim Systemstart verfügbar sein soll. Es ist allerdings kein Freifahrtschein: Die tatsächliche Schutzwirkung hängt weiterhin von der Konfiguration und den Firewall-Regeln ab.

Kill Switch: Verbindungen bei einem Ausfall blockieren

Ein Kill Switch soll verhindern, dass Netzwerkverkehr ungewollt über die normale Internetverbindung läuft, wenn ein VPN-Tunnel ausfällt oder nicht verfügbar ist. Bei WG Tunnel Desktop ist der Kill Switch eine eigenständige systemweite Einstellung. Er hängt also nicht ausschließlich davon ab, ob gerade ein bestimmter Tunnel aktiv ist.

Zusätzlich lässt sich der Schutz für den Systemstart wiederherstellen. Nach einem Neustart kann WG Tunnel die entsprechenden Regeln erneut anwenden.

Je nach Konfiguration kann es außerdem wichtig sein, lokalen LAN-Verkehr gezielt zu erlauben. Genau in diesem Bereich gab es in Version 2.4.0 und 2.4.1 weitere Fehlerkorrekturen. Wer den Kill Switch nutzt, sollte nach dem Update prüfen, ob die gewünschte Erreichbarkeit lokaler Geräte erhalten bleibt.

Tunnel und Gruppen verwalten

WG Tunnel bietet mehr als eine einfache Liste mit Einträgen zum Ein- und Ausschalten. Tunnel lassen sich importieren, exportieren und bearbeiten. Hinzu kommen Sortiermöglichkeiten, Live-Statistiken und Tunnel-Gruppen.

Gerade wer mehrere Standorte, Server oder unterschiedliche Einsatzzwecke hat, profitiert davon. Beispielsweise lassen sich Verbindungen für das Heimnetz, einen Serverstandort oder den Zugriff auf bestimmte interne Dienste übersichtlicher organisieren.

Die Statistiken zeigen unter anderem die Laufzeit der Verbindung. Im Proxy-Modus werden außerdem Informationen zur aktiven Proxy-Adresse und zum Authentifizierungsstatus angezeigt.

Multihop: VPN-Verbindungen hintereinander schalten

Mit Desktop-Version 2.4.0 kam die Unterstützung für Multihop-Verbindungen hinzu. Dabei wird ein Tunnel innerhalb eines anderen Tunnels verwendet. Vereinfacht gesagt läuft der Datenverkehr damit nicht nur über eine einzelne VPN-Verbindung, sondern über mehrere aufeinanderfolgende Stationen. Das kann für spezielle Netzwerktopologien oder bewusst getrennte Verbindungswege interessant sein.

Allerdings gilt auch hier: Mehr Hops bedeuten nicht automatisch mehr Sicherheit. Entscheidend ist, wer die einzelnen Endpunkte betreibt, wie die Routen eingerichtet sind und welchem Zweck die zusätzliche Station dient. Außerdem können zusätzliche Stationen Latenz und Komplexität erhöhen.

WEITERE FUNKTIONEN

Proxy, DNS, Systemdienst und mehr

Lokaler Proxy: VPN für ausgewählte Anwendungen nutzen

WG Tunnel kann eine VPN-Verbindung über einen lokalen HTTP- oder SOCKS-Proxy bereitstellen. Anwendungen, die einen solchen Proxy unterstützen, können den Tunnel dadurch gezielt verwenden. Das ist eine interessante Alternative, wenn nicht der gesamte Rechnerverkehr über das VPN laufen soll.

Die Desktop-Version unterstützt HTTP, SOCKS4 und SOCKS5. SOCKS4 wurde in Version 2.4.0 ergänzt; Version 2.4.1 behebt unter anderem Probleme im Proxy-Modus mit benutzerdefiniertem Tunnel-DNS.

Dabei sollte man die Grenzen kennen: Ein Proxy wirkt nur für Programme, die tatsächlich über ihn kommunizieren. Er ist nicht dasselbe wie ein systemweiter VPN-Tunnel.

Split DNS und verschlüsseltes DNS

DNS-Anfragen lassen sich durch den Tunnel leiten. WG Tunnel unterstützt dafür klassisches DNS sowie verschlüsselte Varianten über DNS-over-TLS (DoT) und DNS-over-HTTPS (DoH). Zusätzlich kann DNS anhand von Domain-Suffixen aufgeteilt werden. Bestimmte Domains können dadurch über den Tunnel aufgelöst werden, während andere die System-DNS-Konfiguration verwenden.

Das ist vor allem in Umgebungen mit internen Domains interessant. Ein Beispiel wäre ein Heimnetz, in dem interne Hostnamen nur über einen bestimmten VPN-Server aufgelöst werden können.

Eine wichtige Einschränkung: Die Desktop-Version bietet kein App-basiertes Split Tunneling wie die Android-App. Die DNS-Aufteilung nach Domains ist davon zu unterscheiden – sie legt fest, wie Namen aufgelöst werden, nicht pauschal, welche Anwendung welchen Netzwerkweg nimmt.

Dynamische DNS- und IPv6-Behandlung

Wer einen VPN-Endpunkt mit dynamischer IP-Adresse betreibt, kennt das Problem: Ändert sich die öffentliche Adresse, kann die bisherige Verbindung ins Leere laufen. WG Tunnel kann Änderungen erkennen und Endpunkte aktualisieren, ohne dass die Anwendung dafür komplett neu gestartet werden muss.

Auch IPv6 wird berücksichtigt. Je nach Netzwerkbedingungen kann WG Tunnel IPv6-Endpunkte bevorzugen oder auf IPv4 zurückfallen. Das soll Verbindungen robuster machen, wenn ein Netzwerk IPv6 nur teilweise oder gar nicht unterstützt.

Gerade bei wechselnden WLANs, mobilen Anschlüssen oder selbst betriebenen VPN-Endpunkten können solche Funktionen im Alltag helfen.

Systemdienst statt ausschließlich grafischer Anwendung

Ein weiterer Unterschied zu einer rein grafischen Anwendung: WG Tunnel Desktop besteht nicht nur aus dem sichtbaren Fenster. Ein eigenständiger Systemdienst kümmert sich um den Tunnelbetrieb.

Das bedeutet, dass der VPN-Tunnel weiterlaufen kann, auch wenn die grafische Oberfläche geschlossen ist. Zusammen mit der Wiederherstellung beim Systemstart ist das sinnvoll für Rechner, die dauerhaft erreichbar sein sollen oder auf denen ein VPN zuverlässig im Hintergrund laufen muss.

Die grafische Oberfläche kann außerdem in den System-Tray minimiert werden. Ein Statussymbol informiert über den Verbindungszustand.

Verschlüsselte Speicherung sensibler Daten

VPN-Konfigurationen enthalten sensible Informationen, etwa private Schlüssel und Endpunktdaten. WG Tunnel speichert Tunnelkonfigurationen und weitere vertrauliche Daten laut Projekt verschlüsselt in einer lokalen Datenbank mit AES-256-GCM. Der Schlüssel für diese Verschlüsselung wird im Schlüsselbund beziehungsweise im Anmeldeinformationsspeicher des Betriebssystems abgelegt.

Das ist eine sinnvolle zusätzliche Schutzmaßnahme. Sie ersetzt allerdings weder eine sichere Benutzerkontenverwaltung noch die Sicherung des Rechners selbst.

Automatische Updates und weitere Desktop-Funktionen

WG Tunnel besitzt einen integrierten Updater mit Update-Benachrichtigungen. Die automatische Aktualisierung ist laut Projekt für Windows-Installationen sowie direkt installierte .deb– und .rpm-Pakete vorgesehen. Andere Linux-Installationswege können manuelle Updates erfordern.

Außerdem wurde die Anwendung als natives Programm auf Basis von GraalVM umgesetzt, statt eine komplette Java-Laufzeitumgebung mitzuliefern. Der Entwickler nennt dadurch kürzere Startzeiten und einen geringeren Speicherbedarf als wichtige Ziele dieser Umstellung.

Unter Linux unterstützt die Anwendung Wayland nativ und kann bei Bedarf auf X11 zurückfallen.

AKTUELLE VERSION

Was ist in Version 2.4.1 neu?

Die aktuelle Version 2.4.1 erschien am 17. Oktober 2026. Sie ist vor allem ein Wartungs- und Verbesserungsupdate mit einigen wichtigen Korrekturen:

Langsame Tunnelstarts unter Windows wurden verbessert.
Unter macOS kamen Verbesserungen an der WLAN-Erkennung für Auto-Tunneling hinzu.
Das Verhalten der Anwendung im macOS-Dock wurde korrigiert.
Probleme im Proxy-Modus mit benutzerdefiniertem Tunnel-DNS wurden behoben.
Die Unterstützung für getunnelte virtuelle Maschinen unter macOS wurde ergänzt beziehungsweise verbessert.
Zusätzlich gab es weitere Korrekturen und Aktualisierungen.

Bereits Version 2.4.0 hatte Multihop, SOCKS4-Unterstützung, Verbesserungen bei Tunnel-Gruppen, Korrekturen am Kill Switch und Optimierungen für den Tunnelstart unter Windows eingeführt.

Wer WG Tunnel bereits einsetzt, sollte deshalb die Release Notes im Blick behalten. Gerade bei einem VPN-Client können Fehlerkorrekturen an Firewall-Regeln, DNS oder dem Verbindungsaufbau wichtiger sein als neue Funktionen auf der Oberfläche.

INSTALLATION

So kommt WG Tunnel auf den Rechner

Die Installation unterscheidet sich je nach Betriebssystem. Lade die Anwendung am besten direkt aus dem offiziellen GitHub-Projekt herunter. Dort findest du die passenden Pakete für Windows, Linux und macOS.

WG Tunnel Desktop – aktuelle Releases auf GitHub

🪟

Windows 10 und Windows 11

Voraussetzung ist Windows 10 ab Version 1803 oder neuer.

Öffne die Release-Seite auf GitHub.
Lade die aktuelle Windows-Installationsdatei mit der Endung .exe herunter.
Starte den Installer und bestätige die erforderliche Administratorabfrage.
Dadurch kann der Systemdienst eingerichtet werden, der für Tunnel, Routen und Firewall-Regeln benötigt wird.
Starte anschließend WG Tunnel und importiere deine vorhandene WireGuard-Konfiguration.

Alternativ kann die Installation über WinGet erfolgen:

PowerShell

winget install -e --id WGTunnel.WGTunnel

Wichtig bei einem Upgrade: Wer noch die alte Desktop-Version 1.x installiert hat, muss diese vor dem Wechsel auf Version 2.x deinstallieren. Die Installationsarchitektur wurde geändert; die alte und die neue Version können nicht parallel bestehen.

🍎

macOS auf Apple Silicon

Die Desktop-Version unterstützt macOS 13 (Ventura) oder neuer auf Macs mit Apple Silicon. Intel-Macs werden derzeit nicht unterstützt.

Lade die aktuelle .dmg-Datei von der GitHub-Release-Seite.
Öffne das Image und ziehe WG Tunnel in den Programme-Ordner.
Starte die Anwendung.
Erlaube den angeforderten Hintergrunddienst in den macOS-Systemeinstellungen.

Alternativ ist die Installation über Homebrew möglich:

Bash

brew tap wgtunnel/wgtunnel
brew trust wgtunnel/wgtunnel
brew install --cask wg-tunnel

Beim ersten Start muss macOS den Hintergrunddienst freigeben. Die Anwendung führt dich zu der entsprechenden Einstellung.

🐧

Linux: Debian und Ubuntu

Für Debian- und Ubuntu-basierte Systeme gibt es ein eigenes APT-Repository. Der Installationsweg laut Projekt:

Bash

wget -qO- https://apt.wgtunnel.com/install.sh | sh

Wie bei jedem Installationsskript aus dem Internet empfiehlt es sich, das Skript vor der Ausführung zu prüfen. Alternativ kannst du das .deb-Paket direkt von GitHub laden und lokal installieren:

Bash

sudo apt install ./wgtunnel*.deb

🎩

Linux: Fedora und RHEL

Für Fedora und RHEL steht ein COPR-Repository zur Verfügung:

Bash

sudo dnf copr enable zaneschepke/wgtunnel
sudo dnf install wgtunnel

Alternativ kannst du das aktuelle .rpm-Paket aus den GitHub-Releases herunterladen und installieren.

⚙

Linux: Arch Linux

Für Arch Linux ist das Paket über das AUR verfügbar:

Bash

yay -S wgtunnel-bin

Bei einer direkten Installation des .pacman-Pakets muss der Dienst anschließend aktiviert und gestartet werden:

Bash

sudo pacman -U wgtunnel*.pacman
sudo systemctl enable --now wgtunnel-daemon.service

⚠

Linux-Hinweise

Die Firewall muss nftables oder iptables mit dem nft-Backend verwenden. Bei systemd-basierten Distributionen startet der Dienst automatisch beim Systemstart. Bei anderen Init-Systemen ist zusätzliche Einrichtung erforderlich.

Snap, Flatpak und AppImage werden vom Projekt derzeit nicht angeboten.

ERSTER TUNNEL

Nach der Installation: Den ersten Tunnel einrichten

Wenn WG Tunnel installiert ist, brauchst du eine bestehende WireGuard- oder AmneziaWG-Konfiguration. Das ist in der Regel eine .conf-Datei, die du von deinem VPN-Server oder Router erhältst.

Konfiguration importieren

Öffne WG Tunnel und importiere deine Konfiguration über die Tunnelverwaltung.

Einstellungen prüfen

Prüfe die Gegenstellenadresse, die erlaubten IP-Bereiche und die DNS-Einstellungen.

Tunnel aktivieren

Aktiviere den Tunnel und kontrolliere, ob der Handshake zustande kommt.

Zugriff testen

Teste den Zugriff auf die gewünschten Ziele – zum Beispiel interne Server oder Dienste im Heimnetz.

Kill Switch bewusst testen

Wenn du den Kill Switch verwenden möchtest, richte ihn bewusst ein und teste anschließend, was bei einem getrennten Tunnel passiert. Prüfe dabei auch, ob lokaler LAN-Verkehr, Drucker oder andere interne Geräte weiterhin wie gewünscht erreichbar sind.

Bei einer Proxy-Konfiguration muss außerdem die jeweilige Anwendung auf die lokale Proxy-Adresse eingestellt werden. Ein aktivierter WG-Tunnel allein bedeutet nicht automatisch, dass jedes Programm den lokalen Proxy nutzt.

VERGLEICH

WG Tunnel Desktop oder der normale WireGuard-Client?

Der offizielle WireGuard-Client ist keineswegs schlecht. Im Gegenteil: Er ist eine gute Wahl, wenn du klassische WireGuard-Konfigurationen möglichst einfach importieren und aktivieren möchtest. Er konzentriert sich bewusst auf das Wesentliche. WG Tunnel Desktop richtet sich eher an Nutzer, die mehr Kontrolle über das Verhalten ihrer VPN-Verbindungen benötigen.

Funktion	Offizieller WireGuard-Client	WG Tunnel Desktop
Klassische WireGuard-Tunnel	Ja	Ja
AmneziaWG	Nein	Ja
Systemweiter Kill Switch	Nicht als vergleichbare integrierte Funktion	Ja
Auto-Tunneling nach Netzwerkbedingungen	Nicht in vergleichbarer Form integriert	Ja
Lokaler HTTP-/SOCKS-Proxy	Nicht integriert	Ja
Verschlüsseltes und aufgeteiltes DNS	Nicht in diesem Funktionsumfang integriert	Ja
Dynamische Endpunkt-Wiederherstellung	Nicht in diesem Funktionsumfang integriert	Ja
Multihop-Funktion in der Anwendung	Nicht integriert	Ja
Tunnel-Gruppen und erweiterte Verwaltung	Einfachere Verwaltung	Ja
Systemdienst und Wiederherstellung beim Booten	Abhängig vom Betriebssystem und der Integration	Als Desktop-Funktion vorgesehen

Der Vergleich bezieht sich auf die integrierten Funktionen der jeweiligen Anwendungen. WireGuard selbst ist das Protokoll; was sich mit dem offiziellen Client erreichen lässt, kann je nach Betriebssystem, Netzwerk und zusätzlichen Systemwerkzeugen variieren.

Wo WG Tunnel besonders punktet

Der größte Vorteil ist die Kombination der Funktionen. Wer mehrere Tunnel betreibt, DNS gezielt steuern möchte, einen Proxy benötigt oder sicherstellen will, dass bei einem Tunnel-Ausfall nicht einfach der normale Internetzugang übernimmt, bekommt mit WG Tunnel viele dieser Möglichkeiten in einer Oberfläche.

Auch die Wiederherstellung nach einem Neustart und die automatische Behandlung wechselnder Endpunktadressen sind für Rechner interessant, die nicht nur gelegentlich manuell verbunden werden.

Wer dagegen nur einen einzigen Tunnel benötigt, den er bei Bedarf einschaltet, braucht nicht unbedingt einen zusätzlichen Client. In diesem Fall bleibt die offizielle WireGuard-Anwendung eine schlanke und unkomplizierte Lösung.

ANDROID

Und was ist mit der Android-Version?

WG Tunnel wurde ursprünglich für Android entwickelt und ist dort schon länger verfügbar. Viele der erweiterten Funktionen – etwa Auto-Tunneling, Proxy-Modus, DNS-Steuerung und Kill-Switch-Funktionen – stammen aus dieser Entwicklung.

Die Desktop-Version bringt einen großen Teil dieser Ideen auf den PC, ist aber kein vollständiger Klon der Android-App. Unterschiede gibt es unter anderem bei Split Tunneling, den Systemberechtigungen und der Integration in das jeweilige Betriebssystem.

Wer WG Tunnel bisher nur vom Smartphone kennt, findet mit der Desktop-Version also eine interessante Ergänzung für den eigenen Rechner.

Passend dazu: Unseren bereits veröffentlichten Beitrag zu den Neuerungen von WG Tunnel für Android findest du im RDDZ-Newsbereich. Dort behandeln wir die Android-Version getrennt von der Desktop-Reihe.

FAZIT

Für wen lohnt sich WG Tunnel Desktop?

WG Tunnel Desktop ist besonders dann interessant, wenn WireGuard zwar die richtige Basis ist, die Standardfunktionen des Clients aber nicht mehr ausreichen.

Die Kombination aus Kill Switch, Auto-Tunneling, DNS-Steuerung, Proxy-Modus, dynamischer Endpunktbehandlung und Tunnel-Gruppen macht die Anwendung zu einer vielseitigen Alternative. Mit AmneziaWG und Multihop kommen zusätzliche Möglichkeiten für spezielle Anforderungen hinzu.

Die Software ist Open Source und für Windows, Linux sowie Apple-Silicon-Macs verfügbar. Gleichzeitig sollte man im Hinterkopf behalten, dass ein VPN-Client mit Systemdienst, Firewall-Regeln und automatischer Wiederherstellung mehr Verantwortung trägt als ein einfacher Schalter im Fenster. Wer die erweiterten Funktionen nutzt, sollte die eigene Konfiguration deshalb sorgfältig prüfen.

Für alle, die WireGuard bereits einsetzen und mehr Kontrolle über ihre Verbindungen möchten, ist WG Tunnel Desktop definitiv einen Blick wert.

QUELLEN

Quellen und Links

WireGuard-VPN für Team oder Standort einrichten?

Von der WireGuard-Anbindung bis zur Netzwerkplanung: Sprechen Sie uns an, wir unterstützen bei Konzept, Einrichtung und Betrieb.

Der Beitrag WG Tunnel Desktop: Mehr als nur ein WireGuard-Client für Windows, Linux und macOS erschien zuerst auf RDDZ.

WG Tunnel 5.8.2: AMOLED-Design, Ping-Tests und wichtige Fehlerkorrekturen

dennis_rddz — Mon, 19 Oct 2026 20:56:30 +0000

WG TUNNEL · ANDROID · 19.10.2026

WG Tunnel 5.8.2: AMOLED-Design, Ping-Tests und wichtige Fehlerkorrekturen

WG Tunnel für Android hat ein weiteres Update erhalten. Mit Version 5.8.2, veröffentlicht am 19. Oktober 2026, verbessert der Open-Source-VPN-Client nicht nur die Bedienung, sondern behebt auch mehrere Fehler aus den vorherigen Versionen. Dazu kommen ein dynamisches AMOLED-Design und eine neue Möglichkeit, Server direkt vom Hauptbildschirm aus anzupingen – auch dann, wenn gerade kein VPN-Tunnel aktiv ist.

WG TUNNEL 5.8.2

● Seit 19.10.2026

AMOLED

dynamisches Theme

Ping

ohne aktiven Tunnel

Fixes

TV, Split Tunneling

Neu ✓ AMOLED-Theme, Ping

Android TV ✓ Import & Backup korrigiert

Split Tunneling ✓ Speichern korrigiert

Empfehlung ✓ Update für Android-Nutzer

Update → Tunnel starten → Sonderfunktionen kurz prüfen

✓ Release: 19. Oktober 2026

✓ Dynamisches AMOLED-Theme

✓ Server-Ping ohne aktiven Tunnel

✓ Fixes für Android TV und Split Tunneling

✓ Open-Source-VPN-Client für Android

NEUERUNGEN

Was ist neu in WG Tunnel 5.8.2?

Bereits Version 5.8.0 hatte mit Multihop-Tunneln und Tunnel-Gruppen größere Neuerungen eingeführt. Die nachfolgenden Updates konzentrieren sich nun stärker auf Stabilität, Bedienkomfort und die Korrektur konkreter Probleme.

🌙

Dynamisches AMOLED-Design

Wer auf dem Smartphone ein dunkles Erscheinungsbild bevorzugt, bekommt mit 5.8.2 eine weitere Option: ein dynamisches AMOLED-Theme. Gerade auf Geräten mit OLED-Display kann eine konsequent dunkle Darstellung angenehm sein und den Energieverbrauch reduzieren, abhängig von Display und Nutzung.

Das neue Theme ist eine Ergänzung zu den vorhandenen Darstellungsmöglichkeiten und gehört zu den sichtbaren Neuerungen dieser Version.

📡

Server direkt vom Hauptbildschirm anpingen

Eine praktische Verbesserung für die Fehlersuche: WG Tunnel kann Server jetzt direkt vom Hauptbildschirm aus anpingen, selbst wenn kein Tunnel aktiv ist.

Das erleichtert die erste Diagnose bei Verbindungsproblemen. So lässt sich beispielsweise prüfen, ob ein Ziel grundsätzlich erreichbar ist, bevor man sich mit der VPN-Konfiguration beschäftigt. Ein erfolgreicher Ping beweist allerdings nicht automatisch, dass auch der WireGuard-Handshake oder der gesamte Tunnel funktioniert.

📺

Verbesserungen für Android TV

Auch Nutzer von Android TV profitieren vom Update. Die Entwickler haben Fehler beim Importieren von Konfigurationen korrigiert. Außerdem wurden Probleme rund um Backup und Wiederherstellung behoben und die Unterstützung für Android TV dabei verbessert.

Das ist insbesondere dann hilfreich, wenn Tunnel-Konfigurationen auf einem Fernseher oder einer TV-Box eingerichtet, gesichert oder auf ein anderes Gerät übertragen werden sollen.

🔀

Korrekturen bei Split Tunneling

Version 5.8.2 behebt außerdem Probleme mit veralteten beziehungsweise nicht korrekt gespeicherten Änderungen an der Split-Tunnel-Konfiguration. Die Bedienung wurde in diesem Bereich ebenfalls verbessert.

Beim Split Tunneling wird festgelegt, welche Apps oder Verbindungen den VPN-Tunnel verwenden und welche davon ausgenommen sind. Gerade bei solchen Einstellungen ist es wichtig, dass Änderungen zuverlässig gespeichert werden und anschließend tatsächlich der gewünschten Konfiguration entsprechen.

SEIT VERSION 5.8.0

Was wurde seit Version 5.8.0 korrigiert?

Nicht alle Änderungen stecken direkt in 5.8.2. Bereits die Zwischenversion 5.8.1 brachte eine wichtige Fehlerkorrektur mit.

WG Tunnel 5.8.1: SOCKS5-Proxy und Lockdown-DNS

In Version 5.8.0 waren Fehler bei der DNS-Auflösung im Zusammenhang mit dem SOCKS5-Proxy und dem Lockdown-Modus eingeführt worden. Version 5.8.1 korrigierte diese Probleme. Wer diese Funktionen nutzt, sollte deshalb mindestens eine korrigierte Version verwenden. Die aktuelle Version 5.8.2 enthält diese Korrektur ebenfalls.

Rückblick: Die größeren Neuerungen aus 5.8.0

Mit Version 5.8.0 kamen unter anderem folgende Funktionen hinzu:

Multihop-Tunnel

VPN-Verbindungen lassen sich hintereinander schalten.

Tunnel-Gruppen

Mehrere Tunnel können übersichtlicher organisiert und verwaltet werden.

IPv6- und Proxy-Korrekturen

Fehler beim lokalen Proxy und bei IPv6-bezogenen Einstellungen wurden behoben.

Auto-Tunnel

Verbesserungen bei der Netzwerkerkennung, bei Android Auto und bei gerätespezifischen Besonderheiten.

Bedienung

Überarbeitungen an Split-Tunnel- und DNS-Einstellungen.

Wer bereits Version 5.8.0 nutzt, erhält mit 5.8.2 also nicht nur neue Komfortfunktionen, sondern auch die nachfolgenden Fehlerkorrekturen.

EMPFEHLUNG

Sollte man auf WG Tunnel 5.8.2 aktualisieren?

Ja, das Update ist für bestehende Android-Nutzer empfehlenswert. Besonders interessant ist es für alle, die den SOCKS5-Proxy, den Lockdown-Modus, Split Tunneling oder Android TV verwenden.

Auch wer WG Tunnel nur mit einer einzelnen WireGuard-Verbindung nutzt, profitiert von den allgemeinen Verbesserungen und Fehlerkorrekturen. Die neuen Funktionen für AMOLED-Darstellung und Ping-Tests sind zusätzliche Vorteile, aber nicht für jeden Einsatzzweck zwingend erforderlich.

Nach einem Update lohnt es sich, kurz zu prüfen, ob die eigenen Tunnel wie erwartet starten und ob besondere Einstellungen – etwa Split Tunneling, DNS oder Proxy – weiterhin korrekt funktionieren.

DOWNLOAD

Wo gibt es WG Tunnel 5.8.2?

Die Android-Version ist über verschiedene Bezugsquellen verfügbar. Welche Version bereits angeboten wird, kann je nach Store und Veröffentlichungszeitpunkt variieren.

📦

GitHub

Die offiziellen Releases und die APK-Dateien direkt aus dem Projekt.

📱

IzzyOnDroid

Ein alternativer Store für freie Android-Apps.

▶

Google Play

Verfügbarkeit und Aktualisierungsstand bitte direkt im Store prüfen.

Wer die APK direkt herunterlädt, sollte darauf achten, dass sie aus dem offiziellen Projekt stammt. Für Version 5.8.2 nennt der Entwickler folgenden SHA-256-Fingerabdruck des Signaturzertifikats:

SHA-256 (Signaturzertifikat)

5204d82e766e8aa14dcbb06dc70aebae2bdd812d4d6203cd521a8a685d7d3d80

Die Signatur lässt sich nach dem Download beispielsweise mit apksigner prüfen:

Bash

apksigner verify --print-certs [Pfad zur APK] | grep SHA-256

Der ausgegebene Fingerabdruck muss mit dem vom Projekt veröffentlichten Wert übereinstimmen.

ANDROID & DESKTOP

Android und Desktop künftig getrennt betrachten

WG Tunnel ist inzwischen nicht mehr nur ein Android-Projekt. Mit dem Desktop-Client gibt es auch Varianten für Windows, Linux und macOS. Die Desktop-Version besitzt eigene Releases und plattformspezifische Installationswege.

Deshalb werden wir die beiden Varianten künftig getrennt behandeln: Dieser Beitrag konzentriert sich auf WG Tunnel für Android. Ein eigener Artikel für WG Tunnel Desktop kann dann die jeweiligen Neuerungen, Installationswege und Besonderheiten unter Windows, Linux und macOS behandeln.

QUELLEN

Quellen und Links

VPN, Netzwerk oder Fernzugriff einrichten?

Von WireGuard-Anbindungen bis zur Netzwerkplanung: Sprechen Sie uns an, wir unterstützen bei Konzept, Einrichtung und Betrieb.

Der Beitrag WG Tunnel 5.8.2: AMOLED-Design, Ping-Tests und wichtige Fehlerkorrekturen erschien zuerst auf RDDZ.