PHP2Shell auf Synology: Wie wir sechs Websites an einem Tag gepatcht haben

PHP2Shell PHP2Shell ist die branchenübliche Bezeichnung für CVE-2026-109618 und CVE-2026-109619, zwei kritische Schwachstellen in der PHP-Engine, die die Ausführung von nicht authentifiziertem Remote-Code ermöglichen. Details wurden am 20. Oktober 2026, einen Tag vor der koordinierten Veröffentlichung, durchgesickert, und das PHP-Projekt veröffentlichte am 21. Oktober Notfall-Releases. Da der Fehler im Interpreter und nicht in einer Anwendung liegt, bringt das Patchen von WordPress, Joomla oder MediaWiki nichts. Die einzige Lösung ist ein neuer PHP-Build. Wir betreiben sechs öffentliche WordPress-Websites auf Synology-Hardware, und PHP2Shell bedeutete, dass alle innerhalb derselben Woche neu kompiliert werden mussten. Dieser Leitfaden erklärt den Fehler, wie er über das Paketzentrum auf DSM behoben wird, wie man damit umgeht, wenn die Website in einem Container läuft, und vergleicht die von Synology ausgelieferte Version mit den bisherigen Lösungen anderer NAS-Hersteller.

SynoPower Club-Punkt:Unsere sechs Websites wurden innerhalb eines Werktages nach Veröffentlichung der PHP2Shell-Warnung aktualisiert. Dies war nicht etwa Heldentaten zu verdanken, sondern der Tatsache, dass Synology die korrigierten Pakete zeitgleich mit der Warnung veröffentlichte. Synology-SA-26:14 wurde am 22. Oktober mit dem Status „Behoben“ und einer vollständigen Tabelle der korrigierten Versionen bis hinunter zu PHP 7.4 veröffentlicht. Am selben Tag veröffentlichte QNAP QSA-26-18 mit dem Status „Wird behoben“ und dem Hinweis „Wird noch bekannt gegeben“ in jeder einzelnen Zeile der korrigierten Versionen. ASUSTOR reagierte darauf, indem es die ältere PHP-Version aus App Central entfernte, anstatt sie zu patchen. Wenn Sie eine öffentliche Website auf einem NAS selbst hosten, ist diese Zeitspanne kein Marketing-Detail. Sie entscheidet darüber, ob Sie ein Paket aktualisieren oder Ihre Website während der Wartezeit offline nehmen müssen.

Was ist PHP2Shell und warum ist es anders?

PHP2Shell ist kein einzelner Fehler, sondern eine Reihe zusammenhängender Speichersicherheitsprobleme in der Art und Weise, wie PHP nach einer Anfrage, die nicht genügend Speicher hatte, aufräumt. PHP verwendet longjmp() Um schwerwiegende Fehler, einschließlich Speichermangel, zu vermeiden, wird ein Sprung ausgeführt, der den Aufräumcode überspringt, der die Engine normalerweise in einen definierten Zustand zurückversetzen würde. Teile dieses Zustands sind global und bleiben auch bei der nächsten Anfrage desselben Worker-Prozesses erhalten.

CVE-2026-109618 betrifft den Speichermangel. Eine speziell präparierte HTTP-Anfrage erschöpft das Speicherlimit, obwohl die Anfragedaten nur teilweise initialisiert sind. Die Bereinigungsroutine durchläuft daher Strukturen, die nie vollständig initialisiert wurden. CVE-2026-109619 betrifft die Verwendung von freigegebenem Speicher: Globale Zustände, die auf freigegebenen Anfragespeicher verweisen, können von einer späteren Anfrage desselben Workers gelesen werden. Dadurch kann der Fehler zur Codeausführung oder zum offenen Speicherzugriff führen.

Zwei Eigenschaften machen PHP2Shell gefährlicher als herkömmliche PHP-Sicherheitswarnungen. Erstens: Es handelt sich um eine Prä-Authentifizierung. Beide Schwachstellen treten auf, bevor eine Authentifizierung auf Anwendungsebene stattfindet. Daher bieten weder eine Anmeldesperre noch ein Mitgliedschafts-Plugin oder ein Administratorpasswort Schutz. Zweitens: Die Variante, die Speicher offenlegt, führt zu einem Speicherleck im Worker-Prozess. Ein PHP-Worker auf einer WordPress-Website speichert Datenbankzugangsdaten, API-Tokens und Zahlungsschlüssel. Ein erfolgreicher Lesevorgang muss nicht einmal zur Codeausführung führen, um Ihnen das ganze Jahr zu verderben.

Die beiden PHP2Shell-CVEs wurden vom PHP-Sicherheitsteam mit 9,2 Punkten auf CVSS v4.0 bewertet. Synology vergab in seiner eigenen Sicherheitswarnung 9,8 Punkte auf CVSS v3.1. Unterschiedliche Skalen, gleiches Ergebnis. Die Berichte über Ausnutzungen sind uneinheitlich: WatchTowr berichtet von Angriffen auf sein Honeypot-Netzwerk, während Bitdefender zum Zeitpunkt der Veröffentlichung keine entsprechenden Daten in seinen Telemetriedaten meldete. QNAP gibt an, keine Meldungen über Ausnutzungen erhalten zu haben, die speziell auf QNAP-Produkte abzielen.

PHP2Shell vs. ein normaler WordPress-Exploit

Die meisten Angriffe auf öffentliche WordPress-Websites sind auf Plugin-Schwachstellen zurückzuführen. Das Muster ist bekannt: Ein Plugin liefert einen fehlerhaften REST-Endpunkt aus, ein Scanner findet ihn, man aktualisiert das Plugin, und die Sicherheitslücke ist geschlossen. PHP2Shell durchbricht diese Vorgehensweise vollständig, und das reflexartige Überprüfen von Plugins ist hier überflüssig.

Aspekt	Typische Plugin-CVE	PHP2Shell
Wo der Käfer lebt	Anwendungscode (Plugin oder Theme)	Der PHP-Interpreter selbst
Wer kann es auslösen?	Oft ist eine Abonnenten- oder Administratorrolle erforderlich.	Niemand. Vorauthentifizierung, bevor die Anwendungslogik ausgeführt wird.
Hilft ein WordPress-Update?	Normalerweise ja	Nein. Core- und Plugin-Updates sind irrelevant.
Verhindert eine WAF das?	Normalerweise gilt: Sobald eine Regel existiert	Teilweise. Die Regeln für die Anforderungsstruktur übersehen den OOM-Pfad.
Was behebt das Problem tatsächlich?	Plugin-Update	Ein neuer PHP-Build, sonst nichts.
Explosionsradius	Ein Standort, ein Feature	Alle PHP-Websites auf dem Rechner, alle gleichzeitig

Diese letzte Zeile erklärt, warum PHP2Shell statt eines Nachmittags einen ganzen Arbeitstag in Anspruch nahm. Ein einzelnes gemeinsam genutztes PHP-Paket auf einem NAS kann hinter einem Dutzend virtueller Web-Station-Hosts liegen, und ein einzelnes Container-Image kann die Basis für mehrere Websites bilden. Patches werden nicht pro Website, sondern pro Laufzeitumgebung installiert, und man muss die Laufzeitumgebungen auflisten, bevor man sagen kann, dass etwas erledigt ist.

Wie Sie feststellen, ob Ihr NAS ungeschützt ist

Die Ermittlung der Sicherheitslücke in PHP2Shell beginnt mit der Unterscheidung zweier unterschiedlicher Fragen: Enthält das System eine angreifbare PHP-Version, und ist diese Version aus dem Internet erreichbar? Synology stellt diese Unterscheidung explizit dar: DSM liefert eine interne PHP-Komponente aus, die vom Betriebssystem verwendet wird. Laut Synology verfügt diese Komponente über keine extern zugänglichen Module und somit über keine Angriffsfläche. Das Risiko, das dieser Komponente zugeschrieben wird, ist minimal, und der Patch ist für eine spätere DSM-Version geplant, sodass Schwachstellenscans diese Komponente nicht mehr melden.

Für PHP2Shell sind nur die Pakete relevant, die PHP-Anwendungen im Web bereitstellen. Synology listet Calendar, IDrive, Joomla, KodExplorer, MailStation, MediaWiki, phpMyAdmin, vtigerCRM, Web Station und WordPress auf. Wenn eines dieser Pakete installiert und erreichbar ist, fallen Sie unter die Anwendungsbereiche.

Überprüfen Sie die Versionen direkt, anstatt sich auf ein Dashboard zu verlassen. Im Paketzentrum wird die Version der installierten PHP-Pakete auf der Kachel angezeigt, und die Aktualisierungsbenachrichtigung nennt den Ziel-Build. Fragen Sie in der Shell direkt die Laufzeitumgebung:

# Synology PHP-Paket (passen Sie den Pfad an Ihre Version an) /volume1/@appstore/PHP8.2/usr/local/bin/php -v # Eine containerisierte Website docker exec php -v

Der Grund, warum man darauf bestehen sollte php -v Bei der Überprüfung von PHP2Shell zeigt sich, dass alle anderen Signale irreführend sind. Die Build-Ausgabe kann Erfolg melden, obwohl eine zwischengespeicherte Ebene wiederverwendet wird; ein Dashboard kann ein Paket als aktuell anzeigen, obwohl der laufende Worker nicht aktuell ist; und ein HTTP-Antwortheader kann von einem CDN entfernt werden, bevor er überhaupt angezeigt wird. Zwei unserer sechs Websites wurden von ihren Administrationsoberflächen als fehlerfrei gemeldet, obwohl sie noch einen ungepatchten Interpreter verwendeten.

PHP2Shell auf Synology in 4 Schritten patchen

Für eine Web Station-Website unter DSM ist die vollständige PHP2Shell-Korrektur ein Update des Paketzentrums. Synology veröffentlicht PHP-Sicherheitsupdates für DSM 7.4, 7.3 und 7.2. Nach der Aktualisierung des PHP-Pakets werden die abhängigen Pakete automatisch neu gestartet, wodurch das Problem behoben wird. Mail Station bildet die dokumentierte Ausnahme und benötigt ein separates manuelles Update.

Der obige Screenshot stammt von einem unserer eigenen Rechner am Morgen nach der PHP2Shell-Warnung. Beachten Sie, dass im Bereich „Neuerungen“ die Upstream-Version direkt angegeben wird. So können Sie das Build-Suffix „Synology“ der PHP-Version zuordnen, ohne raten zu müssen. Der Synology-Kalender erscheint in derselben Update-Liste unter Version 3.0.4-21435, genau der Version, die in der Warnung empfohlen wird.

Eine wichtige PHP2Shell-Falle für Web Station-Nutzer: Auf einem DSM-Rechner können mehrere PHP-Branches gleichzeitig installiert sein, und jeder virtuelle Host ist an ein Profil gebunden. Die Aktualisierung des Standardprofils hilft nicht, wenn eine Website an einen anderen Branch gebunden ist. Listen Sie daher zunächst alle Profile auf, aktualisieren Sie sie und überprüfen Sie anschließend die Bindung jeder Website unter „Web Service“.

Welche DSM-Pakete sind betroffen?

Die Synology-Meldung in PHP2Shell ist präziser als die vorhergesagte Panic. Betroffen sind nur Systeme, auf denen bestimmte PHP-abhängige Pakete laufen, und Synology Drive gehört ausdrücklich nicht dazu. IDrive ist zwar auf der Liste, aber eine Drittanbietersoftware.

• Webseitig ausgerichtet und von höchster Priorität. Web Station, WordPress, Joomla, MediaWiki, vtigerCRM, KodExplorer und phpMyAdmin. Diese Dienste stellen PHP-Anwendungen für jeden bereit, der sie erreichen kann.
• E-Mails und Kalender. Mail Station benötigt nach der Installation des PHP-Pakets ein manuelles Update. Der Synology-Kalender verfügt über eine eigene, korrigierte Version (3.0.4-21435).
• Die interne DSM-Komponente. Vorhanden, aber nicht von außen erreichbar, Patch auf eine spätere DSM-Version verschoben, Risiko laut Synology als minimal eingestuft.
• Die Behälter sind nicht abgedeckt. Die PHP-Laufzeitumgebung im Container Manager kann von Ihnen selbst angepasst werden. Paketaktualisierungen greifen nicht darauf zu, was der häufigste Grund dafür ist, dass NAS-Besitzer fälschlicherweise annehmen, ihre Arbeit sei abgeschlossen.

Falls Sie noch eine DSM-Version vor 7.2 verwenden, empfiehlt Synology, die betroffenen Pakete vorübergehend zu deaktivieren, bis eine aktualisierte Version verfügbar ist. DSM 7.2 selbst wird in der Mitteilung als veraltet gekennzeichnet, obwohl es diese PHP-Updates erhalten hat.

Der schwierigste Fall für PHP2Shell betrifft PHP 7.3 und ältere Versionen. Synology wird PHP 7.3 nicht reparieren, da der Zweig nicht mehr unterstützt wird und die Entwickler keinerlei Updates für 7.3 und ältere Versionen veröffentlicht haben. Linux-Distributionen haben zwar Backports für einige ältere Zweige bereitgestellt, ein Synology-PHP-Paket ist jedoch kein Distributionspaket. Wenn eine Website PHP 7.3 oder 5.6 benötigt, ist kein Patch zu erwarten. Die sinnvollsten Optionen sind, die Website auf einen unterstützten Zweig umzustellen, sie hinter einer Web Application Firewall (WAF) zu betreiben oder sie vom öffentlichen Internet zu nehmen.

Wie Container-Site-Betreiber mit PHP2Shell umgehen

Fünf unserer sechs Websites nutzen WordPress in Docker statt in Web Station. Hier wird PHP2Shell interessant, denn das Paketzentrum kann hier nicht weiterhelfen. Die Laufzeitumgebung entspricht dem Inhalt des Images, und das Neuerstellen eines Images ist nicht dasselbe wie dessen Aktualisierung.

Der erste PHP2Shell-Fehler, auf den wir gestoßen sind und der höchstwahrscheinlich auch andere betreffen wird, besteht darin, dass beim Neuerstellen eines benutzerdefinierten Images die zwischengespeicherte Basisschicht wiederverwendet wird. Ein nicht fixierter AUS Ein Tag bedeutet nicht automatisch, dass die Version aktuell ist. Eines unserer Images war vier Tage zuvor neu erstellt worden und enthielt immer noch einen PHP-Build vom Juli 2025, der mehr als ein Jahr an Sicherheitsupdates zurücklag, da Docker nicht gezwungen worden war, die Basisversion erneut abzurufen.

# Falsch: Verwendet stillschweigend die lokal zwischengespeicherte Basisschicht wieder: `docker build -t mysite .` # Richtig: Das Basis-Image wird immer neu geladen: `docker build --pull -t mysite .` # Anschließend wird nur der gewünschte Dienst gestartet, ohne inaktive Dienste zu starten: `docker compose up -d --no-deps wordpress` # Und die relevanten Komponenten werden überprüft: `docker exec wordpress php -v`

Der zweite PHP2Shell-Fehler ist gravierender, da er Erfolg meldet. Weiterleitung der Build-Ausgabe durch Schwanz verschleiert einen Build-Fehler, da der Exit-Code einer Pipeline zum letzten Befehl in ihr gehört und set -e Wird nie ausgeführt. Der Compose-Schritt erstellt dann den Container aus dem alten Image neu, gibt „Gestartet“ aus, und Sie erhalten eine ungepatchte Website, die aussieht, als wäre sie gerade erst bereitgestellt worden. Überprüfen Sie das Build-Ergebnis separat und verifizieren Sie es mit php -v nachher.

Zwei kleinere Hinweise: Kennzeichnen Sie das alte Image vor dem Neuaufbau, da ein Image seine Kennzeichnung beibehält und Ihnen einen kostenlosen Rollback-Punkt bietet, der deutlich günstiger ist als ein Snapshot. Erwarten Sie außerdem nicht, dass ein Image-Upload die Anwendung aktualisiert: Der offizielle WordPress-Image-Einstiegspunkt kopiert die Kerndateien nur, wenn das Dokumentenverzeichnis leer ist. Das Neuerstellen eines Containers auf einem neueren Image lässt eine bestehende Installation also genau an ihrem vorherigen Zustand. Wir haben dies in einer Testumgebung überprüft, bevor wir die Produktionsumgebung angefasst haben, und die WordPress-Version hat sich nicht geändert.

Warum das Deaktivieren von session.upload_progress nur die Hälfte abdeckt

Die gängige PHP2Shell-Abhilfemaßnahme für Maschinen, die nicht gepatcht werden können, besteht darin, Folgendes einzustellen: session.upload_progress.enabled = 0, Und auf DSM befindet sich diese Einstellung in der Web Station unter „Skriptspracheneinstellungen“ im Reiter „Core“ des PHP-Profils. Es lohnt sich, dies zu tun. Es ist keine endgültige Lösung, und die Lücke ist relevant.

Der Upload-Fortschritt über die Session ist nur einer der möglichen Angriffswege. Die Variante, die den Speicherzugriff offenlegt, wird durch normale Multipart-Anfragen erreicht und benötigt die Session-Funktion überhaupt nicht. Daher bleibt dieser Angriffsweg offen, wenn die Session-Funktion deaktiviert wird. Das PHP-Projekt hat ausdrücklich erklärt, dass es keine vollständigen Schutzmaßnahmen gibt und ein Update die einzig sichere Lösung darstellt. Imunify360 berichtet, dass derzeit keine Regel den Speicherzugriffsweg von CVE-2026-109618 blockiert, und Elastic merkt an, dass die Upload-Fortschrittseinstellung zwar die bestätigten Session-Angriffswege schließt, aber nicht alle Varianten.

Sie werden auch sehen Speicherlimit = -1 Der Vorschlag basiert auf der Annahme, dass der Fehler durch einen Speichermangel verursacht wird. Dies sollte man als Kompromiss, nicht als Gewinn betrachten. Die Aufhebung des Speicherlimits auf einem öffentlichen Webserver ändert lediglich die Fehlerursache, und auf einem NAS mit gemeinsam genutztem Speicher führt sie dazu, dass die Worker den gesamten Speicherplatz des Systems auslasten.

Edge-Filterung ist die PHP2Shell-Schicht, die wirklich einen Mehrwert bietet, da sie entschlüsselten Datenverkehr erkennt, Ihr Router jedoch nicht. Cloudflare hat einen Schutz durch verwaltete Regeln für PHP2Shell implementiert, AWS hat in Version 2.3 seiner PHP-Regelgruppe die Abdeckung von CVE-2026-109619 hinzugefügt, und Azure Front Door hat die Regel 99006001 veröffentlicht, die standardmäßig deaktiviert ist. Community-Regeln für Snort und Suricata sind auf GitHub verfügbar, aber die offiziellen Snort- und Emerging Threats-Regelsätze hatten zum Zeitpunkt der Erstellung dieses Dokuments noch nichts veröffentlicht. Daher wird Ihnen eine NAS-Intrusion-Prevention-Funktion hier nicht helfen. Sie kann ohnehin nicht innerhalb von TLS-Protokollen lesen.

Welcher NAS-Anbieter hat tatsächlich einen Fix ausgeliefert?

Dieser Teil der PHP2Shell-Geschichte sollte Ihre Kaufentscheidung beeinflussen. Die PHP-Version wurde am 21. Oktober veröffentlicht. Die folgenden Informationen stammen von den vier wichtigsten NAS-Anbietern für Endverbraucher und ambitionierte Hobbyanwender und nicht aus Medienberichten.

Verkäufer	Beratung	Status	Korrigierte Versionen veröffentlicht
Synology	Synology-SA-26:14, 22. Okt. 2026	Gelöst	Ja. Alle Zweige von PHP 7.4 bis 8.4, plus Calendar und Mail Station.
QNAP	QSA-26-18, 22. Oktober 2026	Festsetzung	Nein. In jeder Zeile steht: Wird noch bekanntgegeben.
ASUSTOR	Einstellung der Unterstützung für ältere PHP-Versionen, 22. Oktober 2026	Ruhestand, nicht ein Flicken	Nein. PHP 7, 7.3, 7.4 und 8.1 wurden aus App Central entfernt.
UGRÜN	Keine gefunden	Unbekannt	Für UGOS Pro wurden keine Empfehlungen gefunden.

Synology veröffentlichte am selben Tag wie die Empfehlung eine vollständige PHP2Shell-Versionstabelle und markierte die Empfehlung als behoben. Ein DSM-Besitzer, der dies las, musste noch am selben Nachmittag Folgendes tun: Paketzentrum öffnen, auf „Aktualisieren“ klicken und die Version überprüfen. Dies war der gesamte Behebungsprozess, und deshalb waren unsere Web-Station-Maschinen innerhalb von Minuten statt Tagen fertig.

QNAP veröffentlichte am selben Tag eine Liste betroffener Produkte, darunter QTS 6.1.0, QTS 5.2.11 und ältere Versionen, QuTS hero h6.1.0, h6.0.x und h5.2.11 und ältere Versionen, QuTScloud c5.2.9 und ältere Versionen, Note Station 3, QNE ADRA, QVR Surveillance auf ARM32-Modellen und TVR OS. Für alle diese Produkte wird der Status „Wird behoben“ ohne Angabe einer festen Versionsnummer angezeigt. Da die PHP-Laufzeitumgebung Teil der QTS-Webkomponenten ist, kann kein separates Paket aktualisiert werden. Die Behebung des Problems muss daher über ein Firmware-Update erfolgen.

QNAP bietet Opfern von PHP2Shell in der Zwischenzeit eine Liste mit Abhilfemaßnahmen an, die aufgrund ihrer Empfehlungen unbedingt gelesen werden sollte: Router-Portweiterleitung und UPnP deaktivieren, myQNAPcloud-Dienste abschalten, Fernzugriff über ein VPN abwickeln, Management-Ports auf vertrauenswürdige Subnetze beschränken, nicht benötigte PHP-basierte Anwendungen beenden, den integrierten Webserver bei Nichtgebrauch deaktivieren und das QuLog Center auf Anzeichen einer Kompromittierung überprüfen. Dies sind sinnvolle Ratschläge für ein ungepatchtes System. Für alle, die eine öffentliche Website betreiben, bedeutet dies außerdem, die Website vorübergehend offline zu nehmen.

ASUSTOR wählte einen dritten Weg. In einer Mitteilung vom 22. Oktober mit dem Titel „Ankündigung der Abschaffung von Legacy-PHP“ werden PHP 7, PHP 7.3, PHP 7.4 und PHP 8.1 mit sofortiger Wirkung aus App Central entfernt. ASUSTOR empfiehlt, wichtige Daten zu sichern und fordert Anwender auf, ab sofort nur noch PHP 8.3 oder 8.4 zu verwenden. Diese Begründung ist nachvollziehbar, da die Entwickler nur noch Versionen ab 8.2 patchen. Für Anwender älterer PHP-Anwendungen bedeutet dies, dass die Laufzeitumgebung nicht repariert, sondern aus dem Store entfernt wird. ASUSTOR gibt zudem nicht an, dass eine gepatchte Version von 8.3 oder 8.4 veröffentlicht wurde. Im Gegensatz dazu veröffentlichte Synology eine korrigierte Version 7.4.33-0131 für genau die Anwender, zu deren Migration ASUSTOR aufruft.

Für UGREEN konnten wir keinerlei PHP2Shell-Warnung für UGOS Pro finden. Das Fehlen einer öffentlichen Stellungnahme beweist nicht zwangsläufig, dass ein Produkt angreifbar ist, und UGOS Pro liefert möglicherweise einfach keine webbasierte PHP-Laufzeitumgebung aus. Wenn Sie jedoch der Inhaber sind, ist Schweigen keine Lösung, auf die Sie reagieren können, und stellt an sich ein Sicherheitsrisiko dar.

Nichts davon macht Synology perfekt. Es behebt PHP 7.3 nicht, kennzeichnet DSM 7.2 als veraltet und die eigene interne PHP-Komponente wird weiterhin geplant statt gepatcht. Der springende Punkt ist jedoch spezifischer und nützlicher als ein Markenargument: Als ein Fehler bei der Remote-Code-Ausführung vor der Authentifizierung in der PHP-Engine auftrat, bot ein Anbieter die Behebung per Knopfdruck im Paketzentrum an, während die anderen auf Geduld setzten.

Wo finde ich weitere offizielle Ressourcen?

PHP2Shell ist zum Zeitpunkt der Veröffentlichung dieses Artikels zwei Tage alt und die Situation entwickelt sich noch. Daher sollten Sie sich an die Originalquellen halten und nicht an Zusammenfassungen. Bisher gibt es von keinem der Anbieter offizielle Videoanleitungen. Die folgende Liste dient daher eher der Dokumentation als der praktischen Umsetzung.

• Synology-SA-26:14 Dies ist die maßgebliche Versionstabelle. Überprüfen Sie sie erneut, bevor Sie Patches installieren, da die Empfehlungen aktualisiert werden.
• Die Synology PSIRT-Erklärung listet die betroffenen Pakete auf und erläutert die interne DSM-Komponente sowie die Ausnahme der Mail Station.
• Die Upstream-GitHub-Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp sind vom Synology-Advisory verlinkt und beschreiben das Verhalten der Engine und nicht die Verpackung durch den Hersteller.
• QNAP QSA-26-18 Hier wird die korrigierte Firmware-Version angezeigt, wenn Sie QTS oder QuTS Hero verwenden. Diese Seite sollten Sie im Auge behalten, nicht einen Nachrichtenartikel.
• Ihr eigenes Paketzentrum gibt die endgültige Auskunft darüber, was installiert ist. Die Empfehlung informiert Sie über die Zielversion, die Kachel zeigt Ihnen, was Sie tatsächlich installiert haben, und nur php -v zeigt Ihnen an, was gerade läuft.

Hintergrundinformationen zum Betrieb öffentlicher Websites auf virtuellen Synology-Maschinen finden Sie in unserer Anleitung unter Verschieben eines Docker-Stacks zwischen VDSM-Gästen behandelt die Snapshot- und Rollback-Gewohnheiten, die das Überleben in diesem Notfall ermöglichten.

PHP2Shell-Beschränkungen und Sicherheitshinweise

Das Patchen von PHP2Shell ist auf DSM unkompliziert, auf allen anderen Plattformen jedoch trügerisch. Daher sollten einige Einschränkungen klar benannt werden, bevor man die Arbeit als abgeschlossen erklärt.

Ein PHP2Shell-Paketupdate ist kein Website-Audit. Durch das PHP-Update wird die Sicherheitslücke zwar ab diesem Zeitpunkt geschlossen, aber wenn der Rechner zwischen dem 20. und 22. Oktober aus dem Internet erreichbar war, war dies auch der Fall, als eine funktionierende Sicherheitslücke öffentlich war. Überprüfen Sie die Logs auf unerwartet hohes POST-Volumen, suchen Sie nach Dateien in beschreibbaren Verzeichnissen und ändern Sie alle Zugangsdaten, die ein PHP-Worker möglicherweise verwendet hat. Bei der Variante mit Speicherzugriffsverletzung ist die Änderung der Zugangsdaten eine sinnvolle Vorsichtsmaßnahme und keine übertriebene Paranoia.

Die PHP2Shell-Verifizierung muss den laufenden Interpreter berücksichtigen. Dashboards, Build-Logs und Antwort-Header haben uns in dieser Runde mindestens einmal im Stich gelassen. Ein CDN kann den Header entfernen, der die Version angegeben hätte, ein Build kann Erfolg melden, während eine zwischengespeicherte Ebene wiederverwendet wird, und eine Paketkachel kann die aktuelle Version anzeigen, während ein alter Worker noch aktiv ist. Nur php -v Das System, das die Anfragen bearbeitet, regelt die Angelegenheit.

Container werden von keiner Hersteller-Empfehlung für PHP2Shell abgedeckt. Dies muss wiederholt werden, da es sich um einen häufigen Trugschluss bei der Sicherheit von NAS-Systemen handelt. Wenn Ihre Website im Container Manager läuft, sagt Ihnen die Meldung des Paketzentrums, dass alles auf dem neuesten Stand ist, nichts über den Zustand Ihrer Website aus. Dasselbe gilt für alle Drittanbieteranwendungen, die ihre eigene Laufzeitumgebung mitbringen.

Konfigurationsmaßnahmen sind systembedingt nur teilweise wirksam. Das Deaktivieren des Upload-Fortschritts von Sitzungen hilft zwar, das Aufheben der Speicherbegrenzung birgt jedoch ein Risiko, das durch ein anderes ersetzt wird, und die Intrusion-Prevention-Funktion eines Routers kann TLS-Verkehr, der an anderer Stelle endet, nicht untersuchen. Betrachten Sie all dies als Zeitgewinn, während Sie einen echten Patch entwickeln, nicht als Ersatz dafür.

Für veraltete Laufzeitumgebungen gibt es keinen PHP2Shell-Pfad mehr. PHP 7.3 und ältere Versionen erhielten weder Updates vom Upstream-Projekt noch von Synology. Benötigt eine Website tatsächlich einen nicht mehr unterstützten Zweig, bleibt Ihnen nur die Wahl zwischen Migration, Isolation oder dem Rückzug aus dem öffentlichen Internet. Es gibt keine vierte Option, und wer das Gegenteil behauptet, riskiert, dass eine veraltete Website zum Einfallstor für alle anderen Anwendungen auf demselben System wird.

Beachten Sie abschließend die offizielle Sicherheitswarnung und nicht die Nachrichtenlage. Synology hat SA-26:14 als behoben markiert und innerhalb von sechs Minuten nach Veröffentlichung einmal überarbeitet. QNAP hat mitgeteilt, dass QSA-26-18 aktualisiert wird, sobald korrigierte Versionen verfügbar sind. Beide Seiten werden sich ändern; die Versionsnummern in diesem Artikel entsprechen denen vom 22. Oktober 2026.

Verweise

• Synology-SA-26:14 PHP2Shell-Sicherheitshinweis, veröffentlicht am 22. Oktober 2026, Status: Gelöst, mit korrigierten Versionen für PHP 7.4 bis 8.4.
• Synology-Erklärung zu PHP2Shell-Schwachstellen, die PSIRT-Notiz mit einer Auflistung der betroffenen Pakete und der DSM-Abdeckung.
• QNAP QSA-26-18, Status: In Bearbeitung, betroffene Produkte mit korrigierten Versionen werden noch bekannt gegeben.
• ASUSTOR Legacy PHP-Abkündigung, wodurch PHP 7, 7.3, 7.4 und 8.1 aus App Central entfernt werden.
• Hilfe zu Net Security bei den Upstream-PHP2Shell-Releases, einschließlich PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie der reinen Quellcode-Backports für ältere Zweige.

Häufig gestellte Fragen