BitGo und Coinbase melden keine Betroffenheit von PHP-Lücken – eine unabhängige Prüfung fehlt

BitGo und Coinbase melden keine Betroffenheit von den PHP-Lücken

Der Krypto-Verwahrer BitGo erklärt laut Berichterstattung, seine Plattform sei von den kritischen PHP-Schwachstellen nicht betroffen. Coinbase habe nach einer Prüfung keine betroffenen PHP-Instanzen gefunden. Beide Angaben sind Selbstauskünfte. Bekannt werden sie über die Fachpresse, konkret über Berichte von bloomingbit und bit.fan. Das Originalstatement liegt nicht vor, sein Veröffentlichungsort ist unbekannt. Eine unabhängige Prüfung gibt es bislang nicht.

Die beiden Berichte weichen im Detail voneinander ab. Bloomingbit schreibt, eine vollständige Prüfung habe bei BitGo und Coinbase keine exponierten PHP-Instanzen ergeben. Bit.fan trennt die Aussagen: BitGo habe lediglich erklärt, nicht betroffen zu sein. Eine Prüfung nennt der Bericht nur für Coinbase. Ohne den Wortlaut von BitGo bleibt offen, ob das Unternehmen kein PHP einsetzt, PHP nicht exponiert betreibt oder bereits gepatcht hat.

BitGos öffentliche SDK-Dokumentation und das offizielle BitGoJS-Repository nennen JavaScript/Node.js als Basis (Node.js ab Version 22), dazu das Paket BitGo Express. PHP taucht dort nicht als Plattformbestandteil auf. Das erlaubt keinen Schluss darauf, ob BitGos eigene Server PHP einsetzen. Dass BitGo kein PHP nutzt, ist damit weder belegt noch widerlegt.

Es gibt außerdem einen PHP-Client für die BitGo-API: das Composer-Paket neto737/bitgosdk-php. Als offizielles BitGo-Produkt ist er im vorliegenden Material nicht ausgewiesen. Der Client läuft auf Kundenseite und gehört nicht zur BitGo-Plattform. Eine Aussage zur Plattform würde ihn daher nicht erfassen. Wer ihn oder ein eigenes PHP-Backend für die BitGo-Anbindung betreibt, muss die eigene PHP-Version prüfen, unabhängig davon, was BitGo über die eigene Infrastruktur sagt. Laut Projektbeschreibung verlangt der Client PHP 7.4 oder neuer mit cURL-Erweiterung und ist bis PHP 8.5 getestet. Die im Material genannten Patch-Versionen gehören zu den Zweigen 8.2 bis 8.5. Zu älteren Zweigen enthalten die vorliegenden Quellen keine Patchangabe, hier müssen Betreiber gesondert nachfragen.

Zwei kritische Lücken mit CVSS 9,2, gepatchte Versionen seit dem 21. Oktober

Das PHP-Projekt hat am 21. Oktober 2026 gegen 13:30 UTC die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie beheben CVE-2026-109618 und CVE-2026-109619. Beide Lücken erhalten nach CVSS v4.0 den Wert 9,2. Laut PHP-Advisory können beide unauthentifizierte Remote-Code-Ausführung ermöglichen.

CVE-2026-109618 ist eine Speicherkorruption bei der Behandlung von Speichermangel. PHP bricht Anfragen, die das memory_limit überschreiten, per longjmp() ab. Geschieht das, während Anfragedaten erst teilweise initialisiert sind, bleibt der Speicher in einem ungültigen Zustand zurück. Die anschließende Aufräumroutine kann die ungültigen Daten dann für gültig halten. Laut PHP-Projekt lässt sich dieser Punkt etwa beim Parsen von Multipart-Uploads erreichen, und zwar innerhalb der konfigurierten Grenzen. Der Angreifer braucht also keine Anmeldung, nur eine passend gebaute Anfrage. CVE-2026-109619 ist ein Use-after-free. Globaler Zustand, etwa zu Fehlern, Sessions, Objekten und Erweiterungen, bleibt in einem Worker erhalten, verweist aber auf Speicher, der nur einer Anfrage gehörte. Operationen vor der Initialisierung der nächsten Anfrage können diesen veralteten Zustand nutzen, nachdem der Speicher freigegeben wurde.

Warum daraus Codeausführung werden kann, erklären die Quellen nicht im Einzelnen. Allgemein gilt: Wenn Programmcode Speicher nutzt, der ungültig oder bereits neu vergeben ist, können von außen beeinflusste Daten dort landen, wo das Programm eigene Verwaltungsdaten erwartet. Das ist die übliche Grundlage solcher Angriffe. Bei Apache mod_php geschieht der kritische Schritt laut Advisory, bevor irgendein Anwendungscode läuft. Prüfungen, Filter oder Frameworks der Anwendung können dort nicht eingreifen. Für die übrigen Betriebsarten differenziert das vorliegende Material nicht. Laut Advisory sind alle PHP-Installationen gefährdet, die Webanfragen bedienen. Genannt werden PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed.

Bei der Einstufung gibt es eine Abweichung. Das kanadische Cyber Centre klassifiziert beide CVEs als Use-after-free (CWE-416). Die PHP-Beschreibung führt CVE-2026-109618 dagegen als Speicherkorruption bei der Behandlung von Speichermangel und nur CVE-2026-109619 ausdrücklich als Use-after-free. Die Klassifizierungen weichen also ab. Der Grund dafür ist nicht belegt.

Auch zum Alter des Problems ist die Lage unklar. Laut bit.fan meldeten Calif und OpenAI es am 11. August, und die Fehler seien bereits 2024 erstmals identifiziert worden. Das 2024-Datum stammt nur aus dieser einen Quelle. CERT-EU nennt lediglich die Ankündigung vom 20. Oktober und die Fixes vom 21. Oktober. Die Aussagen sind nicht abgeglichen, ein echter Widerspruch ist nicht belegt. Neu ist demnach vor allem die Veröffentlichung der Patches und die breite öffentliche Diskussion.

Warnungen von CERT-EU und Kanada, abgeschaltete Dienste, SlowMist-Stichprobe

CERT-EU meldet, dass technische Details bereits öffentlich diskutiert werden und erste Proofs of Concept kursieren. Das erhöhe die Wahrscheinlichkeit, dass Angreifer die Lücken schon ausnutzen. Die Behörde empfiehlt sofortiges Patchen, ersatzweise die Isolierung internetexponierter Anwendungen vom öffentlichen Netz, bis ein Fix eingespielt und geprüft ist. Das Canadian Centre for Cyber Security nennt die Lücken „php2shell“ und fordert im Alert AL26-026, betroffene Systeme zu identifizieren und sofort zu aktualisieren.

In der gemeinsamen Mitteilung mehrerer EU-Stellen kommen weitere Hinweise hinzu. Organisationen sollen ihre PHP-basierten Anwendungen erfassen, sich mit Hostern und Dienstleistern abstimmen und internetexponierte Systeme zuerst patchen. Viele kommerzielle und quelloffene Produkte nutzen PHP im Hintergrund. Sie können betroffen sein, auch wenn sie nach außen nicht danach aussehen. Für solche Drittsoftware verweist die Mitteilung auf das GitHub-Verzeichnis des NCSC-NL (NCSC-NL/php2shell).

Laut Fachpresse haben Behörden in mehreren Ländern einzelne Dienste vorübergehend offline genommen. Genannt werden die Niederlande, Finnland, Frankreich, Deutschland und Australien. Intersect hat seinen Mitgliederbereich zeitweise geschlossen. Die PHP Foundation bezeichnete die verzögerte Behebung als „strukturelles Versagen“, verursacht durch Zögern bei Entscheidungen und fehlende Ressourcen.

SlowMist fand bei 793 von 1.488 untersuchten Krypto-Domains direkte PHP-Fingerprints. Das widerspricht BitGos Aussage nicht. Die Stichprobe betrifft BitGo nicht erkennbar, und es ist unklar, welche Domains geprüft wurden.

Für Betreiber bleibt die Konsequenz: PHP auf eine der gepatchten Versionen aktualisieren, internetexponierte Systeme zuerst. Dazu gehört, Abhängigkeiten und eingebettete Drittsoftware zu prüfen und bei Hostern nachzufragen. Wer nicht sofort patchen kann, sollte betroffene Anwendungen vom öffentlichen Netz trennen.