In den meisten Firmen steht es im Technikraum, im Serverschrank oder unter einem Schreibtisch: ein Synology-NAS. Zwei oder vier Platten, eine blaue Leuchtdiode, seit Jahren unauffällig. Dort liegen die Sicherungen, die Freigaben der Buchhaltung, manchmal die Überwachungsaufzeichnungen.
Was dabei selten jemand mitdenkt: Dieses Gerät ist ein vollwertiger Linux-Server mit Weboberfläche. Und je nachdem, was darauf installiert ist, führt es PHP aus.
Am 22. Oktober hat Synology dazu einen Hinweis veröffentlicht. Einstufung: kritisch.
Was Synology tatsächlich geschrieben hat
Der Hinweis trägt die Nummer Synology-SA-26:14 und den Titel „PHP2Shell". Veröffentlicht am 22.10.2026 um 19:45 Uhr (UTC+8), Status: behoben.
Betroffen sind laut Synology mehrere Pakete in DSM:
| Paket | Behoben ab |
|---|---|
| PHP 7.3 | Kein Update. Diese Fassung hat ihr Lebensende erreicht. |
| PHP 7.4 | 7.4.33-0131 |
| PHP 8.0 | 8.0.30-0122 |
| PHP 8.1 | 8.1.34-0120 |
| PHP 8.2 | 8.2.35-0171 |
| PHP 8.3 | 8.3.36-0051 |
| PHP 8.4 | 8.4.27-0051 |
| Mail Station | 30000002.3.19-20333 |
| Synology Calendar | 3.0.4-21435 |
Die Zahlen hinter dem Bindestrich sind Synologys eigene Paketstände, nicht Teil der PHP-Versionsnummer. Wer in der Paketverwaltung „8.2.35" liest, hat deshalb noch nicht zwangsläufig „8.2.35-0171".
Der Satz, auf den es ankommt
Im Hinweis steht ein Halbsatz, der die ganze Einordnung trägt:
> „The built-in PHP in OS is not exposed to external attack surfaces, and the risk of exploitation is considered very low."
Übersetzt: Das PHP, das DSM für sich selbst mitbringt, ist nicht von außen erreichbar. Für die reine Weboberfläche Ihres NAS ist die Gefahr nach Herstellerangabe sehr gering.
Das ist eine Entwarnung, und sie ist ernst zu nehmen. Sie gilt aber ausschließlich für das eingebaute PHP. Sobald Sie selbst ein PHP-Paket aus dem Paket-Zentrum installiert haben – und genau das tut man, wenn man Web Station nutzt, eine kleine Anwendung betreibt oder ein Portal auf dem NAS laufen lässt –, gilt die Einstufung „kritisch" ohne Einschränkung.
Dasselbe für Mail Station und Synology Calendar: Beide sind nicht Teil des Betriebssystems, beide sind ausdrücklich als kritisch gelistet, und beide sind in kleineren Unternehmen weit verbreitet.
PHP 7.3: Es kommt kein Update
Das ist der unangenehmste Punkt des ganzen Hinweises, und er steht dort in einem Satz: No fix will be provided as this version has reached end of life.
Wenn auf Ihrem NAS PHP 7.3 installiert ist, können Sie diese Lücke nicht schließen. Es gibt keinen Patch und es wird keinen geben.
Das klingt nach einem Randfall, ist aber keiner. PHP 7.3 liegt auf vielen Geräten, weil irgendwann eine Anwendung installiert wurde, die eine ältere Fassung verlangte – ein Wiki, ein Ticketsystem, ein Bildarchiv, eine selbstgebaute Seite. Danach lief es, und niemand hat es wieder angefasst.
Drei Wege bleiben:
Entfernen. Wenn Sie nicht mehr wissen, wofür PHP 7.3 installiert wurde, brauchen Sie es vermutlich nicht. Deinstallieren ist hier die beste Lösung, nicht die faule.
Die Anwendung umziehen. Lässt sie sich auf eine neuere PHP-Fassung heben, tun Sie das. Oft genügt ein Versionswechsel im Profil von Web Station.
Abschotten. Geht beides nicht, muss das Gerät aus dem Internet verschwinden und auch im eigenen Netz vom Rest getrennt werden. Das ist eine Übergangslösung, kein Zustand.
In fünf Minuten nachsehen
Sie brauchen dafür keinen Dienstleister. Melden Sie sich an Ihrem DSM an.
Erstens: Welche PHP-Pakete sind installiert? Paket-Zentrum, Reiter Installiert. Suchen Sie nach allem, was mit „PHP" beginnt. Finden Sie dort nichts, betrifft Sie der kritische Teil dieses Hinweises nicht – dann bleibt nur das eingebaute PHP, und dafür gilt die Entwarnung.
Zweitens: Mail Station oder Synology Calendar? Ebenfalls unter Installiert. Beide gehören aktualisiert, auch wenn Sie sie selten benutzen.
Drittens: Alles aktualisieren. Im Paket-Zentrum unter Aktualisieren. Prüfen Sie danach, ob der Stand wirklich der Tabelle oben entspricht – manche Pakete melden ein Update, ohne es eingespielt zu haben, solange ein abhängiges Paket läuft.
Viertens – und das ist der wichtigste Punkt: Ist das Gerät von außen erreichbar? Systemsteuerung, Externer Zugriff. Prüfen Sie, ob QuickConnect aktiv ist und ob in Ihrem Router Weiterleitungen auf das NAS zeigen. Ein NAS, das nur im eigenen Netz steht, ist in einer völlig anderen Lage als eines, das unter einer eigenen Adresse im Internet hängt.
Warum ein NAS der ungünstigste Ort für eine Lücke ist
Bei einer Website ist die Rechnung bitter genug. Bei einem NAS kommt eine zweite Ebene dazu.
Es hält alles. Freigaben, Archive, oft die einzige Kopie bestimmter Unterlagen. Wer dort Code ausführen kann, steht nicht vor einer Website, sondern vor dem Aktenschrank.
Es ist gleichzeitig das Sicherungsziel. Genau dort, wo Sie hinspielen, wenn etwas anderes ausfällt. Wird das Sicherungsziel selbst übernommen, verlieren Sie beide Seiten der Rechnung auf einmal. Warum ein NAS allein deshalb keine ausreichende Sicherung ist, steht in Cyberversicherung und Backup: welches NAS nicht reicht.
Es wird nicht gepflegt. Server bekommen Wartungsfenster, Arbeitsplätze bekommen Updates. Das NAS bekommt Strom. Es steht in keinem Patch-Plan, weil es als Gerät wahrgenommen wird und nicht als Server – derselbe blinde Fleck, der in Firmware-Updates vergessen beschrieben ist.
Und es hängt oft am Internet. QuickConnect ist bequem, Portweiterleitungen sind schnell eingerichtet, und beides überlebt die Person, die es eingerichtet hat.
Was die Lücke technisch ist – und warum das hier zählt
Beide Schwachstellen drehen sich um dasselbe: um Speicher, der nicht mehr gilt.
Bei CVE-2026-109618 (CVSS 9.8) verlässt PHP bei Speichermangel den laufenden Vorgang abrupt. In manchen Fällen bleibt Anfragespeicher dabei in einem nicht festgelegten Zustand zurück – und der Aufräumvorgang danach liest ihn trotzdem. Bei CVE-2026-109619 zeigen interne Verweise nach dem Aufräumen weiter auf Speicher, der längst freigegeben ist; die nächste Anfrage stolpert darüber.
Für Sie ist daran eines wichtig: Bei dieser Art von Fehler kann Speicherinhalt nach außen gelangen, ohne dass eine Datei verändert wird. Auf einem NAS liegt in diesem Speicher nicht irgendetwas, sondern Sitzungen angemeldeter Benutzer und Zugangsdaten zu Freigaben. Was daraus folgt, steht in Zugangsdaten können weg sein, ohne dass eine Datei angefasst wurde.
Wenn das Gerät am Internet hing
Dann reicht Aktualisieren nicht. Dann gehört nachgesehen, ob vorher jemand da war – und zwar bevor die Protokolle rotieren.
Auf einem Synology-Gerät finden Sie die Spuren im Protokollzentrum und, sofern installiert, in den Zugriffsprotokollen von Web Station. Worauf dabei zu achten ist, steht in PHP2Shell-Angriff erkennen. Unser kostenloses Prüfwerkzeug ist für Linux und Windows Server gebaut; auf einem NAS mit aktiviertem SSH-Zugang läuft es ebenfalls, sofern dort ein PHP-Paket installiert ist.
Und falls ein Kunde oder Ihre Versicherung danach fragt, ob Sie betroffen waren: Die Antwort auf diese Frage will vorbereitet sein. Wie, steht in Ihr Kunde verlangt einen Nachweis.
Checkliste: erste Schritte
- Im Paket-Zentrum nachsehen, welche PHP-Pakete installiert sind
- Mail Station und Synology Calendar prüfen und aktualisieren
- Paketstände gegen die Tabelle oben abgleichen, nicht nur die PHP-Versionsnummer
- PHP 7.3 entfernen, die Anwendung umziehen oder das Gerät abschotten
- Prüfen, ob QuickConnect aktiv ist und ob Portweiterleitungen bestehen
- Bei Erreichbarkeit von außen: Protokolle sichern, bevor sie rotieren
- Administratorkonten und Freigabezugänge erneuern, wenn das Gerät offen stand
- Das NAS in den Patch-Plan aufnehmen – dauerhaft, nicht nur diesmal
Wie DAVINCI unterstützt
Wir sehen uns an, welche Pakete auf Ihren Geräten laufen, bringen sie auf den Stand aus dem Hinweis und prüfen, ob das NAS überhaupt von außen erreichbar sein muss – in den meisten Fällen muss es das nicht. Wenn PHP 7.3 im Spiel ist, klären wir mit Ihnen, ob die Anwendung dahinter noch gebraucht wird. Eine erste Einschätzung von außen gibt der kostenlose PHP-Sicherheitscheck, die Sicht von innen das Prüfwerkzeug für den eigenen Server. Bei Hinweisen auf einen Zugriff übernimmt unser Incident Response die Aufarbeitung. Erreichbar sind wir über die Kontaktseite.
Häufige Fragen
Ich habe nie PHP installiert. Bin ich betroffen?
Dann gilt die Einordnung von Synology selbst: Das eingebaute PHP ist nicht von außen erreichbar, das Risiko wird als sehr gering eingestuft. Prüfen Sie trotzdem im Paket-Zentrum nach – PHP wird manchmal als Abhängigkeit anderer Pakete mitinstalliert, ohne dass man es bewusst ausgewählt hat.
Reicht es, DSM zu aktualisieren?
Nein. Die betroffenen PHP-Fassungen, Mail Station und Synology Calendar sind eigenständige Pakete. Ein DSM-Update rührt sie nicht an; sie werden im Paket-Zentrum aktualisiert.
Was mache ich mit PHP 7.3, wenn die Anwendung darauf angewiesen ist?
Erst prüfen, ob sie wirklich darauf angewiesen ist – häufig lief sie nur nie auf etwas Neuerem. Geht es nicht, muss das Gerät vom Internet getrennt und im internen Netz abgegrenzt werden, bis eine Lösung steht. Eine Anwendung, die eine seit Jahren abgekündigte Laufzeitumgebung verlangt, ist ohnehin ein eigenes Thema.
Unser NAS ist nur im Büronetz erreichbar. Müssen wir trotzdem etwas tun?
Ja, aber mit weniger Eile. Die Lücke lässt sich dann nicht aus dem Internet ausnutzen, sehr wohl aber von einem befallenen Rechner im selben Netz. Aktualisieren Sie beim nächsten regulären Durchgang.
Woran erkenne ich, ob jemand das Gerät angegriffen hat?
An den Zugriffsprotokollen, sofern sie weit genug zurückreichen, und an gehäuften Abstürzen von PHP-Prozessen im Protokollzentrum. Fehlen die Protokolle, lässt sich für die Vergangenheit nichts sagen – das ist eine ehrliche Antwort und keine schlechte.
Betrifft das auch QNAP, Asustor oder TrueNAS?
Die Lücke steckt in PHP selbst, nicht in Synology. Jeder Hersteller, der PHP ausliefert, ist in der Pflicht, und jeder veröffentlicht eigene Hinweise. Prüfen Sie beim Hersteller Ihres Geräts, ob und ab welcher Fassung korrigiert wurde.
Wir nutzen das NAS als Sicherungsziel. Ändert das etwas?
Es verschärft die Lage. Ein übernommenes Sicherungsziel nimmt Ihnen genau die Möglichkeit, auf die Sie sich im Ernstfall verlassen. Spätestens hier gehört eine zweite, getrennte Kopie dazu, die nicht am selben Netz hängt.
Verwandte Themen: Wer hier weiterdenkt, liest bei PHP-Sicherheitslücke, PHP2Shell betroffen und Nachweis Sicherheitsvorfall weiter.
