PHP enthüllt eine „internetweite“ Hochrisiko-Sicherheitslücke – wie lässt sich die „off-chain-Schwachstelle“ von Web3 beheben?

Originaltitel: „PHP enthüllt kritische ‚internetweite‘ Sicherheitslücke: Wie wird Web3s ‚off-chain-Schwachstelle‘ behoben?‘ Autor: SlowMist-Sicherheitsteam

Was geschah

Am 21. Oktober veröffentlichte das PHP-Projekt ein Not-Sicherheitsupdate zur Behebung zweier kritischer Schwachstellen, CVE-2026-109618 und CVE-2026-109619, die zu nicht-authentifizierter Remote-Code-Ausführung (RCE) führen können; beide erhielten die Bewertung CVSS v4.0 9.2. PHP bestätigte offiziell, dass vor dem Patch alle PHP-Installationen mit externen Webdiensten betroffen sein konnten.

Am 20. Oktober wurden Details zur Schwachstelle vor der offiziellen Veröffentlichung bekannt. Der Patch war noch nicht verfügbar, weshalb das PHP-Sicherheitsteam den geplanten Not-Release vom ursprünglich vorgesehenen 22. auf den 21. Oktober, 14:00 Uhr UTC, vorzog.

Besonders besorgniserregend ist, dass Angriffe bereits vor der Veröffentlichung stattgefunden haben könnten. Amazons Threat-Intelligence-Team berichtete, am 17. Oktober Angriffsversuche gegen php2shell in seinem MadPot-Honeypot-Netzwerk beobachtet zu haben – vier Tage vor der öffentlichen Bekanntgabe.

SlowMist veröffentlichte unmittelbar nach der Vorankündigung durch PHP Sicherheitshinweise und Empfehlungen.

Welche beiden Schwachstellen sind es?

CVE-2026-109618 (OOM-Speicherverletzung): Wenn PHP beim Speicher knapp wird, wird der Verarbeitungsablauf unterbrochen, und die aktuell verarbeiteten Daten sind nur halbfertig. Bei der Bereinigung behandelt PHP diese unvollständigen Daten fälschlicherweise als vollständig, was zu einer Speicherverletzung führt.

CVE-2026-109619 (veralteter globaler Zustand): Nach Abschluss einer Anfrage wird der Speicher freigegeben, doch der zugehörige Zustand „bleibt erhalten“. Wenn derselbe Worker-Prozess die nächste Anfrage verarbeitet, kann er diesen abgelaufenen Zustand nutzen, bevor die normale Initialisierung erfolgt. Offiziell bestätigt wurde, dass dies zur Ausnutzung von PHP-FPM und zur Remote-Code-Ausführung genutzt werden kann.

Aus Sicht des Angriffspfads liegt die Gefahr dieser Schwachstellen darin, dass Angreifer weder Zugangsdaten für eine Website benötigen noch Geschäftslogik wie Login-, Berechtigungs- oder API-Key-Prüfungen umgehen müssen. Ein gezielter Request an eine öffentlich zugängliche PHP-Anwendung kann beliebigen Code mit den Rechten des Webdienstprozesses ausführen.

Betroffene Versionen: PHP 5.4 bis 8.5.11. Behoben in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und ältere Versionen erhalten keine reguläre Support-Patches mehr; ein Wechsel auf unterstützte Versionen ist erforderlich.

Warum ist die ganze Welt nervös?

Weil PHP schlichtweg allgegenwärtig ist. Laut W3Techs nutzen 69,3 % aller Websites mit identifizierbarer Server-Seitensprache PHP. Bekannte Systeme wie WordPress, WooCommerce und Magento laufen alle darauf.

Reaktionen verschiedener Länder verdeutlichen das Problem: Die niederländische Nationale Cyber-Sicherheitszentrale stellte vorsorglich Websites offline; das südkoreanische Präsidialamt rief ein Not-Cybersecurity-Treffen ein und erhöhte die Cyber-Sicherheitswarnstufe.

Berichten zufolge waren zudem fast sämtliche offizielle nordkoreanische Websites – darunter staatliche Medien und Regierungsportale – über 24 Stunden lang offline; ob dies mit der Schwachstelle zusammenhängt, ist unklar.

Auswirkungen auf Web3

Dies ist kein Problem, das nur den Betrieb und die Wartung traditioneller Websites betrifft. Für Web3 gilt: Selbst wenn On-Chain-Smartverträge keine Schwachstellen aufweisen, sind die zahlreichen „off-chain-Komponenten“ rund um Vertragsausführungen – darunter Frontend-Seiten, APIs, verwahrte Wallets, Signierdienste, Airdrop-Claim-Seiten, Betriebs-Backends und Datendienste – häufig mit PHP (WordPress, WooCommerce, Magento etc.) realisiert. Fehlende Schwachstellen im Vertrag selbst bedeuten nicht automatisch Sicherheit dieser Komponenten.

Laut Statistiken des Threat-Intelligence-Systems MistEye von SlowMist zeigten von 1.488 kryptoindustriebezogenen Domains, die gescannt wurden, 793 direkt PHP-Fingerabdrücke – etwa 53,3 %. Dies weist lediglich auf die Nutzung von PHP hin; es bedeutet nicht, dass diese Websites verwundbar oder kompromittiert sind.

1. Plattformseite: Typische Risikopfade

Frontend-Manipulation zur Täuschung der Nutzer beim Signieren.

Wird der Server einer DeFi-, Wallet- oder Airdrop-Seite kompromittiert, können Angreifer RPC-Adressen, Autorisierungsziele, Vertragsadressen oder Signierhinweise auf der Seite austauschen – so wird eine normale Transaktion zu einer schädlichen Autorisierung, einem bösartigen Vertragsaufruf oder einem gefälschten Einzahlungsprozess. Angreifer müssen den Vertrag nicht brechen; sie brauchen nur, dass Nutzer selbst eine schädliche Autorisierung signieren.

Leckage von Schlüsseln und Anmeldedaten.

Nach einer Kompromittierung des Servers können Angreifer Konfigurationsdateien, Datenbankpasswörter, API-Tokens, Umgebungsvariablen u. Ä. auslesen. Nutzt das Backend PHP zur Verbindung mit Node-RPC- oder Hot-Wallet-Diensten, kann ein Leak von API-Schlüsseln oder Session-Tokens zur Übertragung von Hot-Wallet-Assets oder zum Missbrauch von Signierrechten führen.

Übernahme von Backend und APIs.

Handelsplattformen, NFT-Marktplätze, Cross-Chain-Bridges, Zahlungsgateways und Node-Dienstanbieter verfügen meist über operative Backends sowie KYC-/Risikosteuerungs-Schnittstellen, Einzahlungsadresszuweisung, Auszahlungsprüfung, Ticketing-Systeme u. Ä. Nach Erhalt entsprechender Berechtigungen können Angreifer Konfigurationen manipulieren, Nutzerdaten stehlen, Konten mit hohen Privilegien erstellen oder Geschäftsprozesse umgehen.

Seitliche Bewegung über die Lieferkette.

Die Rechte eines PHP-Prozesses entsprechen normalerweise nicht den höchsten Serverrechten; doch wenn er CI/CD-Schlüssel, Container-Runtime-Sockets, Datenbankanmeldedaten oder Cloud-Zugriffstoken lesen kann, kann sich der Angriffsbereich von einem einzelnen Web-Node auf Datenbanken, Build-Systeme oder sogar das gesamte Produktionskonto ausdehnen.

Zahlungsplugins und Drittanbieterdienste.

Es ist bekannt, dass Krypto-Zahlungslösungen wie Binance Pay, Crypto.com Pay, BitPay, CoinGate und CoinPayments alle WooCommerce-Integrationen bieten; ungeschützte Server bergen dabei erhebliche Expositionsrisiken. Auch Drittdienste wie RPC-Anbieter, Block-Explorer oder Datenanalyseplattformen können Einstiegspunkte werden, falls ihre Backends oder Betriebssysteme auf betroffenen PHP-Umgebungen laufen. RPC-Knoten, Smart Contracts, Block-Explorer und Wallets selbst hängen jedoch nicht grundsätzlich von PHP ab – dies hängt vom konkreten Technologie-Stack des Produkts ab.

Allerdings ist zu beachten: Eine kompromittierte Serverumgebung bedeutet nicht zwangsläufig, dass On-Chain-Assets gestohlen wurden. Vom Webdienst-Bruch bis zum tatsächlichen finanziellen Verlust hängt es davon ab, ob Angreifer Zugriff auf sensible Anmeldedaten, Signierprozesse, Administratorrechte oder Nutzerinteraktionspunkte erhalten. Ob Hot Wallets vom Web-Layer isoliert sind, ob Schlüssel in HSMs/KMSs gespeichert werden und ob Berechtigungen minimiert sind, bestimmt direkt die Obergrenze möglicher Verluste.

2. Regelmäßige Nutzer: Sollten Sie Ihre Coins abheben?

Nicht nötig.

Der Grund ist einfach:

Diese Schwachstelle betrifft nur Serverumgebungen mit bestimmten Voraussetzungen; sie bedeutet nicht, dass alle Nutzer-Wallets gefährdet sind.

Das Besuchen einer Website und das Verbinden einer Wallet ist nicht gleichbedeutend mit einer Offenlegung des privaten Schlüssels. Die Schwachstelle selbst kann Nutzer-Wallets oder Signaturen nicht direkt knacken.

Dass ein Projekt PHP nutzt, heißt nicht automatisch, dass es bereits kompromittiert ist. Es gibt keinen Grund anzunehmen, jede Handelsplattform sei betroffen – geschweige denn, alle Vermögenswerte wegen dieser Schwachstelle abzuheben. Was Nutzer wirklich beachten sollten, ist, ob die besuchten Websites bereits kompromittiert wurden. Da Nutzer nicht prüfen können, ob eine Website gepatcht ist, dient dieser Vorfall als Mahnung: Vertrauen Sie Website-Oberflächen nicht blind. Angreifer könnten zudem öffentliche Aufmerksamkeit nutzen, um gefälschte Login-Seiten, Schein-Ausgleichsportale oder bösartige Wallet-Verbindungsanfragen zu verbreiten.

Falls ein Projekt offiziell bestätigt, dass seine Website oder sein Backend kompromittiert wurde, sollten Nutzer die offengelegte tatsächliche Auswirkung prüfen, um zu entscheiden, ob Interaktionen pausiert, ungewöhnliche Transaktionen überprüft und verdächtige Genehmigungen widerrufen werden müssen. Ist bestätigt, dass Signatur-Privatschlüssel oder Seed-Phrasen geleakt wurden, muss dies als Schlüsselkompromittierung behandelt werden – lediglich Passwörter zu ändern oder sich von der Website abzumelden, reicht nicht aus. Nutzer von Handels-Bots, automatisierten Ausführungstools oder Cloud-Bereitstellungsdiensten sollten zudem prüfen, ob betroffene Versionen oder Hinweise zur Anmeldeinformationserneuerung veröffentlicht wurden.

So reagieren Sie

1. Plattformen und Projektteams:

Schritt 1: Bestand Ihrer Assets erfassen und umgehend aktualisieren

Erfassen Sie sämtliche PHP-Assets im öffentlichen und internen Netz: Hosts, Container-Images, Kubernetes-Workloads, veraltete CMS, Admin-Backends, Umgebungen bei Partnern sowie Plug-ins und verwaltete Dienste von Drittanbietern. Technische Fingerabdrücke dienen nur als Hinweis und dürfen nicht unmittelbar als „bestätigte Schwachstelle“ gewertet werden.

Aktualisieren Sie auf 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 oder wenden Sie die entsprechenden Patches von Distributionen, Cloud-Anbietern oder Managed-Service-Providern an. Nutzer von Version 8.1 und älter sollten beim Anbieter einen Backport anfordern oder möglichst rasch migrieren. Weder „die Legacy-Umgebung ist stabil“ noch „die Anwendung wird selten aktualisiert“ mindern das Risiko dieser Schwachstelle.

Nach der Aktualisierung bauen Sie Container-Images neu, führen Rolling-Restarts durch oder ersetzen sämtliche PHP-Worker-Prozesse und prüfen die tatsächlich in Produktion für Anfragen genutzte Laufzeitversion – nicht nur die Version auf dem Build-Server oder in der Kommandozeile.

Schritt 2: Was tun, wenn eine Aktualisierung vorerst nicht möglich ist

Reduzieren Sie zunächst die Angriffsfläche, um Zeit zu gewinnen – dies ersetzt jedoch keine Patching-Maßnahme:

Isolieren Sie PHP-Anwendungen mit Internetzugang oder fügen Sie auf Ingress-Ebene Netzwerkauthentifizierung und Zugriffssteuerung hinzu.

Deaktivieren Sie unnötige Dateiuploads und lehnen Sie am WAF- oder Webserver-Level nicht benötigte multipart/form-data-Anfragen ab.

Zu weiteren Sicherheitsempfehlungen zählen u. a.: memory_limit=-1 setzen, session.upload_progress.enabled deaktivieren und bei PHP 8.5 zusätzlich fatal_error_backtraces ausschalten. Diese Konfigurationen wirken sich auf Geschäftsbetrieb und Verfügbarkeit aus; testen Sie sie daher vorab und starten Sie alle PHP-Worker nach jeder Änderung neu.

Schritt 3: Kompromittierung prüfen und Anmeldeinformationen erneuern

Für betroffene Dienste, die jemals öffentlich zugänglich waren, untersuchen Sie Logdateien, Endpunkt-Monitoring und ungewöhnliche Netzwerkverbindungen – etwa plötzliches Ausführen von Systembefehlen durch PHP-Prozesse. Bei Verdacht auf Kompromittierung bewahren Sie zunächst Beweise auf und handeln dann gemäß dem Incident-Response-Prozess.

Gehen Sie vom worst-case-Szenario aus: Rotieren Sie für nicht rechtzeitig gepatchte Server API-Schlüssel, Sitzungsschlüssel, TLS-Zertifikate, Datenbankpasswörter, Cloud-Zugriffstoken, CI/CD-Anmeldeinformationen, RPC/API-Schlüssel, Webhook-Geheimnisse und Token von Drittanbietern – und prüfen Sie auf ungewöhnliche Nutzungsnachweise.

Falls eine bestätigt kompromittierte Softwareversion in der Umgebung installiert oder ausgeführt wurde, beweist allein ein Upgrade oder eine Neuinstallation nicht, dass das Risiko beseitigt ist; Sie müssen zudem Lecks bei Anmeldeinformationen und Persistenz-Backdoors untersuchen und ggf. eine saubere Umgebung neu aufbauen.

Schritt 4: Die Asset-Control-Ebene sichern

Das Patchen von PHP darf nicht die einzige Maßnahme sein. Wichtiger ist, sicherzustellen, dass „eine kompromittierte Web-Maschine das Funds-System nicht mitzureißen vermag“:

Isolieren Sie die Privatschlüssel von Hot-Wallets, Sammel-Wallets und kritischen Signierdiensten vollständig von Web-Knoten. Nutzen Sie HSMs, MPC, dedizierte Signiernetzwerke oder KMS-Richtlinien mit minimalem Zugriff.

Platzieren Sie Web-Dienste, Signierdienste, On-Chain-Knoten, Datenbanken und Build-Systeme in getrennten Netzwerksegmenten und Identitätsbereichen.

Während Vorfällen vorübergehend risikoreiche Operationen wie Auszahlungen, Änderungen der Adress-Whitelist, Erhöhung administrativer Berechtigungen, Erstellung von API-Schlüsseln und Modifikationen von Risikosteuerungsregeln verschärfen; manuelle Prüfung oder verzögerte Aktivierung bei Bedarf ermöglichen.

Für Dienste mit automatischer On-Chain-Ausführung unabhängige Signierung, Mehrfachsignaturfreigabe, Transaktionsbetragsbegrenzungen und Notabschaltmechanismen entsprechend geschäftlicher Anforderungen einsetzen.

Statische Website-Ressourcen, JavaScript-Pakete, Reverse-Proxy-Konfigurationen, DNS/CDN-Regeln und Transaktionsaufbau-Dienste prüfen, um sicherzustellen, dass keine bösartigen Skripte eingefügt oder ausgetauscht wurden.

2. Reguläre Nutzer:

Offizielle Zugangspunkte nutzen: Kürzlich Plattformen bevorzugt über Lesezeichen oder offizielle Kanäle aufrufen und auf Links achten, die unter dem Vorwand eines „Sicherheitsvorfalls“ versendet werden.

Nicht nur Domain und Oberfläche betrachten: Selbst bei bekannten dApp-Domains können Seitenskripte, Transaktionsparameter und RPC-Konfigurationen serverseitig durch Angreifer ersetzt worden sein.

Vor jeder Signatur einzeln prüfen: Empfängeradresse, Blockchain, Genehmigungsbetrag, aufgerufener Vertrag und Simulationsergebnis. Besondere Vorsicht bei approve und setApprovalForAll – bei unbegrenzten Genehmigungsbeträgen noch mehr.

Vor „Entschädigung“, „Migration“ und „Neuverifizierung“ warnen: Während Vorfälle können Hinweise wie „erneut anmelden“, „Wallet neu verifizieren“, „Assets migrieren“ oder „Entschädigung beanspruchen“ auftauchen. Nicht allein auf Popup-Meldungen im Portal reagieren, sondern stets über mehrere offizielle Projekt-Kanäle abgleichen.

Assets staffeln: Hardware-Wallets für größere Bestände, getrennte Wallets mit begrenztem Budget für tägliche Interaktionen nutzen und Genehmigungen regelmäßig bereinigen. So bleibt bei Kompromittierung einer Frontend- oder Plattformkomponente der Schaden begrenzt.

Bei Unklarheiten erst einmal stoppen: Bei ungewöhnlichen Signieranfragen, unerwarteten Genehmigungshinweisen oder verdächtigem Website-Verhalten zunächst innehalten und über offizielle Kanäle verifizieren.

Abschließende Gedanken

Anmeldungslose Remote-Code-Ausführungs-Schwachstellen wie PHP2Shell können nach Durchbrechen der Web-Schicht herkömmliche Server-Einbrüche in Frontend-Vergiftung, Identitätsimitation, Missbrauch von Signierberechtigungen, Hot-Wallet-Risiken und sogar laterale Bewegung auf Lieferketten-Ebene verwandeln.

Für Plattformen stehen drei Maßnahmen an erster Stelle: Aktualisierung auf gepatchte Versionen, Isolierung nicht aktualisierbarer Legacy-Umgebungen und Überprüfung von Schlüsseln sowie Asset-Kontrollsystemen. Nach dem Update gehört die Suche nach Spuren eines Einbruchs zur Vorfallreaktion. Für Nutzer gilt in dieser Zeit: Die Seitenoberfläche etwas weniger blind vertrauen und vor jeder Transaktion einen zusätzlichen Blick werfen. Doch keine Panik: Eine Schwachstelle bedeutet nicht zwangsläufig eine Gefährdung der Assets; ein Server-Einbruch führt nicht automatisch zu Verlusten auf der Blockchain. Entscheidend für das Risikomaß sind vielmehr die von Angreifern erlangten Anmeldeinformationen, deren Berechtigungsumfang und die Geschwindigkeit, mit der das Projekt diese Berechtigungen isolieren und widerrufen kann. Für Web3-Projekte geht Sicherheit nicht nur darum, Angriffe zu verhindern, sondern auch darum: Wenn eine Komponente tatsächlich kompromittiert ist, lässt sich der Schaden dann lokal begrenzen, sodass das Risiko nicht auf Kerngeschäfte und Asset-Operationen übergreift?

Original-Link