{"id":22083,"date":"2026-10-23T05:56:32","date_gmt":"2026-10-22T21:56:32","guid":{"rendered":"https:\/\/synopower.club\/?p=22083"},"modified":"2026-10-23T05:56:32","modified_gmt":"2026-10-22T21:56:32","slug":"synology-php2shell-emergency-patch","status":"publish","type":"post","link":"https:\/\/synopower.club\/de\/synology-php2shell-emergency-patch\/","title":{"rendered":"PHP2Shell auf Synology: Wie wir sechs Websites an einem Tag gepatcht haben"},"content":{"rendered":"

PHP2Shell<\/strong> PHP2Shell ist die branchen\u00fcbliche Bezeichnung f\u00fcr CVE-2026-109618 und CVE-2026-109619, zwei kritische Schwachstellen in der PHP-Engine, die die Ausf\u00fchrung von nicht authentifiziertem Remote-Code erm\u00f6glichen. Details wurden am 20. Oktober 2026, einen Tag vor der koordinierten Ver\u00f6ffentlichung, durchgesickert, und das PHP-Projekt ver\u00f6ffentlichte 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\u00f6sung ist ein neuer PHP-Build. Wir betreiben sechs \u00f6ffentliche WordPress-Websites auf Synology-Hardware, und PHP2Shell bedeutete, dass alle innerhalb derselben Woche neu kompiliert werden mussten. Dieser Leitfaden erkl\u00e4rt den Fehler, wie er \u00fcber das Paketzentrum auf DSM behoben wird, wie man damit umgeht, wenn die Website in einem Container l\u00e4uft, und vergleicht die von Synology ausgelieferte Version mit den bisherigen L\u00f6sungen anderer NAS-Hersteller.<\/p>\n\n\n\n

\n

SynoPower Club-Punkt:<\/strong>Unsere sechs Websites wurden innerhalb eines Werktages nach Ver\u00f6ffentlichung der PHP2Shell-Warnung aktualisiert. Dies war nicht etwa Heldentaten zu verdanken, sondern der Tatsache, dass Synology die korrigierten Pakete zeitgleich mit der Warnung ver\u00f6ffentlichte. Synology-SA-26:14 wurde am 22. Oktober mit dem Status \u201eBehoben\u201c und einer vollst\u00e4ndigen Tabelle der korrigierten Versionen bis hinunter zu PHP 7.4 ver\u00f6ffentlicht. Am selben Tag ver\u00f6ffentlichte QNAP QSA-26-18 mit dem Status \u201eWird behoben\u201c und dem Hinweis \u201eWird noch bekannt gegeben\u201c in jeder einzelnen Zeile der korrigierten Versionen. ASUSTOR reagierte darauf, indem es die \u00e4ltere PHP-Version aus App Central entfernte, anstatt sie zu patchen. Wenn Sie eine \u00f6ffentliche Website auf einem NAS selbst hosten, ist diese Zeitspanne kein Marketing-Detail. Sie entscheidet dar\u00fcber, ob Sie ein Paket aktualisieren oder Ihre Website w\u00e4hrend der Wartezeit offline nehmen m\u00fcssen.<\/p>\n<\/blockquote>\n\n\n\n

Was ist PHP2Shell und warum ist es anders?<\/h2>\n\n\n\n

PHP2Shell ist kein einzelner Fehler, sondern eine Reihe zusammenh\u00e4ngender Speichersicherheitsprobleme in der Art und Weise, wie PHP nach einer Anfrage, die nicht gen\u00fcgend Speicher hatte, aufr\u00e4umt. PHP verwendet longjmp()<\/code> Um schwerwiegende Fehler, einschlie\u00dflich Speichermangel, zu vermeiden, wird ein Sprung ausgef\u00fchrt, der den Aufr\u00e4umcode \u00fcberspringt, der die Engine normalerweise in einen definierten Zustand zur\u00fcckversetzen w\u00fcrde. Teile dieses Zustands sind global und bleiben auch bei der n\u00e4chsten Anfrage desselben Worker-Prozesses erhalten.<\/p>\n\n\n\n

CVE-2026-109618 betrifft den Speichermangel. Eine speziell pr\u00e4parierte HTTP-Anfrage ersch\u00f6pft das Speicherlimit, obwohl die Anfragedaten nur teilweise initialisiert sind. Die Bereinigungsroutine durchl\u00e4uft daher Strukturen, die nie vollst\u00e4ndig initialisiert wurden. CVE-2026-109619 betrifft die Verwendung von freigegebenem Speicher: Globale Zust\u00e4nde, die auf freigegebenen Anfragespeicher verweisen, k\u00f6nnen von einer sp\u00e4teren Anfrage desselben Workers gelesen werden. Dadurch kann der Fehler zur Codeausf\u00fchrung oder zum offenen Speicherzugriff f\u00fchren.<\/p>\n\n\n\n

Zwei Eigenschaften machen PHP2Shell gef\u00e4hrlicher als herk\u00f6mmliche PHP-Sicherheitswarnungen. Erstens: Es handelt sich um eine Pr\u00e4-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\u00fchrt zu einem Speicherleck im Worker-Prozess. Ein PHP-Worker auf einer WordPress-Website speichert Datenbankzugangsdaten, API-Tokens und Zahlungsschl\u00fcssel. Ein erfolgreicher Lesevorgang muss nicht einmal zur Codeausf\u00fchrung f\u00fchren, um Ihnen das ganze Jahr zu verderben.<\/p>\n\n\n\n

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 \u00fcber Ausnutzungen sind uneinheitlich: WatchTowr berichtet von Angriffen auf sein Honeypot-Netzwerk, w\u00e4hrend Bitdefender zum Zeitpunkt der Ver\u00f6ffentlichung keine entsprechenden Daten in seinen Telemetriedaten meldete. QNAP gibt an, keine Meldungen \u00fcber Ausnutzungen erhalten zu haben, die speziell auf QNAP-Produkte abzielen.<\/p>\n\n\n\n

\"Synology-SA-26:14
Synology-SA-26:14, ver\u00f6ffentlicht am 22. Oktober 2026 um 19:45 UTC+8 mit dem Status \u201eGel\u00f6st\u201c.<\/figcaption><\/figure>\n\n\n\n

PHP2Shell vs. ein normaler WordPress-Exploit<\/h2>\n\n\n\n

Die meisten Angriffe auf \u00f6ffentliche WordPress-Websites sind auf Plugin-Schwachstellen zur\u00fcckzuf\u00fchren. Das Muster ist bekannt: Ein Plugin liefert einen fehlerhaften REST-Endpunkt aus, ein Scanner findet ihn, man aktualisiert das Plugin, und die Sicherheitsl\u00fccke ist geschlossen. PHP2Shell durchbricht diese Vorgehensweise vollst\u00e4ndig, und das reflexartige \u00dcberpr\u00fcfen von Plugins ist hier \u00fcberfl\u00fcssig.<\/p>\n\n\n\n

Aspekt<\/th>Typische Plugin-CVE<\/th>PHP2Shell<\/th><\/tr><\/thead>
Wo der K\u00e4fer lebt<\/td>Anwendungscode (Plugin oder Theme)<\/td>Der PHP-Interpreter selbst<\/td><\/tr>
Wer kann es ausl\u00f6sen?<\/td>Oft ist eine Abonnenten- oder Administratorrolle erforderlich.<\/td>Niemand. Vorauthentifizierung, bevor die Anwendungslogik ausgef\u00fchrt wird.<\/td><\/tr>
Hilft ein WordPress-Update?<\/td>Normalerweise ja<\/td>Nein. Core- und Plugin-Updates sind irrelevant.<\/td><\/tr>
Verhindert eine WAF das?<\/td>Normalerweise gilt: Sobald eine Regel existiert<\/td>Teilweise. Die Regeln f\u00fcr die Anforderungsstruktur \u00fcbersehen den OOM-Pfad.<\/td><\/tr>
Was behebt das Problem tats\u00e4chlich?<\/td>Plugin-Update<\/td>Ein neuer PHP-Build, sonst nichts.<\/td><\/tr>
Explosionsradius<\/td>Ein Standort, ein Feature<\/td>Alle PHP-Websites auf dem Rechner, alle gleichzeitig<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Diese letzte Zeile erkl\u00e4rt, 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\u00fcr 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.<\/p>\n\n\n\n

Wie Sie feststellen, ob Ihr NAS ungesch\u00fctzt ist<\/h2>\n\n\n\n

Die Ermittlung der Sicherheitsl\u00fccke in PHP2Shell beginnt mit der Unterscheidung zweier unterschiedlicher Fragen: Enth\u00e4lt 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\u00fcgt diese Komponente \u00fcber keine extern zug\u00e4nglichen Module und somit \u00fcber keine Angriffsfl\u00e4che. Das Risiko, das dieser Komponente zugeschrieben wird, ist minimal, und der Patch ist f\u00fcr eine sp\u00e4tere DSM-Version geplant, sodass Schwachstellenscans diese Komponente nicht mehr melden.<\/p>\n\n\n\n

F\u00fcr 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.<\/p>\n\n\n\n

\u00dcberpr\u00fcfen 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:<\/p>\n\n\n\n

# 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<\/code><\/pre>\n\n\n\n
Der Grund, warum man darauf bestehen sollte php -v<\/code> Bei der \u00dcberpr\u00fcfung von PHP2Shell zeigt sich, dass alle anderen Signale irref\u00fchrend 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 \u00fcberhaupt angezeigt wird. Zwei unserer sechs Websites wurden von ihren Administrationsoberfl\u00e4chen als fehlerfrei gemeldet, obwohl sie noch einen ungepatchten Interpreter verwendeten.<\/p>\n\n\n\n
PHP2Shell auf Synology in 4 Schritten patchen<\/h2>\n\n\n\n
F\u00fcr eine Web Station-Website unter DSM ist die vollst\u00e4ndige PHP2Shell-Korrektur ein Update des Paketzentrums. Synology ver\u00f6ffentlicht PHP-Sicherheitsupdates f\u00fcr DSM 7.4, 7.3 und 7.2. Nach der Aktualisierung des PHP-Pakets werden die abh\u00e4ngigen Pakete automatisch neu gestartet, wodurch das Problem behoben wird. Mail Station bildet die dokumentierte Ausnahme und ben\u00f6tigt ein separates manuelles Update.<\/p>\n\n\n
\n
\n\n<\/div>\n\n
\n
\n
Beachten Sie die Hinweise.<\/h3>\n
\u00d6ffnen Sie Synology-SA-26:14 und notieren Sie sich die korrigierte Version f\u00fcr jeden installierten PHP-Zweig. Die Zielversionen sind 7.4.33-0131, 8.0.30-0122, 8.1.34-0120, 8.2.35-0171, 8.3.36-0051 und 8.4.27-0051. F\u00fcr PHP 7.3 gibt es keine Korrektur, da es das Ende seines Lebenszyklus erreicht hat.<\/p>\n<\/div>\n<\/div>\n
\n
Aktualisierung \u00fcber das Paketzentrum<\/h3>\n
\u00d6ffnen Sie in DSM das Paketzentrum und sehen Sie unter \u201eInstalliert\u201c nach. Bei jedem anf\u00e4lligen PHP-Paket wird ein Update mit der neuen Online-Version angezeigt. Klicken Sie bei jedem aufgelisteten PHP-Zweig auf \u201eAktualisieren\u201c und aktualisieren Sie gegebenenfalls Synology Calendar und Mail Station.<\/p>\n<\/div>\n<\/div>\n
\n
Lasst die Abh\u00e4ngigen neu starten<\/h3>\n
Pakete, die von PHP abh\u00e4ngen, werden nach Abschluss der PHP-Paketaktualisierung automatisch neu gestartet. Dieser Neustart bewirkt die Fehlerbehebung. Mail Station bildet die Ausnahme und muss manuell \u00fcber das Paketzentrum aktualisiert werden.<\/p>\n<\/div>\n<\/div>\n
\n
\u00dcberpr\u00fcfen Sie den laufenden Interpreter.<\/h3>\n
Vertrauen Sie nicht dem Dashboard. F\u00fchren Sie `php -v` im Paketpfad oder innerhalb des Containers aus und vergewissern Sie sich, dass die Build-Nummer mit der Empfehlung \u00fcbereinstimmt. Pr\u00fcfen Sie anschlie\u00dfend, ob jeder virtuelle Host der Web Station an ein Profil gebunden ist, das Sie tats\u00e4chlich aktualisiert haben.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n\n\n\n\n
\"Das
Das Paketzentrum bietet PHP 8.2.35-0171 an, die im Sicherheitshinweis genannte Version.<\/figcaption><\/figure>\n\n\n\n
Der obige Screenshot stammt von einem unserer eigenen Rechner am Morgen nach der PHP2Shell-Warnung. Beachten Sie, dass im Bereich \u201eNeuerungen\u201c die Upstream-Version direkt angegeben wird. So k\u00f6nnen Sie das Build-Suffix \u201eSynology\u201c der PHP-Version zuordnen, ohne raten zu m\u00fcssen. Der Synology-Kalender erscheint in derselben Update-Liste unter Version 3.0.4-21435, genau der Version, die in der Warnung empfohlen wird.<\/p>\n\n\n\n
\"Synology
Der Aktualisierungsdialog mit der Bezeichnung PHP 8.2.35-0171, ver\u00f6ffentlicht von Synology Inc.<\/figcaption><\/figure>\n\n\n\n
Eine wichtige PHP2Shell-Falle f\u00fcr Web Station-Nutzer: Auf einem DSM-Rechner k\u00f6nnen 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\u00e4chst alle Profile auf, aktualisieren Sie sie und \u00fcberpr\u00fcfen Sie anschlie\u00dfend die Bindung jeder Website unter \u201eWeb Service\u201c.<\/p>\n\n\n\n
Welche DSM-Pakete sind betroffen?<\/h2>\n\n\n\n
Die Synology-Meldung in PHP2Shell ist pr\u00e4ziser als die vorhergesagte Panic. Betroffen sind nur Systeme, auf denen bestimmte PHP-abh\u00e4ngige Pakete laufen, und Synology Drive geh\u00f6rt ausdr\u00fccklich nicht dazu. IDrive ist zwar auf der Liste, aber eine Drittanbietersoftware.<\/p>\n\n\n\n