Die Anfälligkeit (GitHub-Tracking-Nummer GHSA-xq3m-2v4x-88gg) betrifft Protobuf.js-Versionen 8.0.0, 7.5.4 und alle älteren Versionen. Das Kernproblem liegt in der unsicheren dynamischen Code-Generierung: Die Bibliothek erstellt JavaScript-Funktionen, indem sie Strings aus Protobuf-Schemas konkateniert und diese dann über den Function()-Konstruktor ausführt. Dabei werden Schema-abgeleitete Bezeichner wie Message-Namen nicht validiert.
Dies eröffnet Angreifern eine perfekte Angriffsfläche. Durch eine manipulierte Protokoll-Definition können sie beliebigen JavaScript-Code in die generierten Funktionen einschleusen. Sobald die Anwendung eine Nachricht mit diesem bösartigen Schema verarbeitet, wird der injizierte Code automatisch ausgeführt. Die Folgen sind gravierend: Angreifer erhalten Zugriff auf Umgebungsvariablen, gespeicherte Anmeldeinformationen, Datenbankverbindungen und können auf interne Systeme zugreifen oder sich seitlich innerhalb der IT-Infrastruktur bewegen.
Eskalierend kommt hinzu, dass auch Entwicklermaschinen gefährdet sind, wenn diese lokal untrusted Schemas laden und dekodieren. Endor Labs betont, dass die Ausnutzung dieser Lücke unkompliziert ist — der minimale Proof-of-Concept in der Sicherheitsempfehlung zeigt die alarmierende Einfachheit der Attacke.
Die gute Nachricht: Protobuf.js-Maintainer haben schnell reagiert. Versionen 8.0.1 (veröffentlicht am 4. April) und 7.5.5 (15. April) beheben das Problem durch eine Sanitierung von Typnamen — nicht-alphanumerische Zeichen werden entfernt, wodurch Angreifer die synthetische Funktion nicht mehr schließen können. Endor Labs merkt allerdings kritisch an, dass eine längerfristige Lösung wäre, problematische Bezeichner gar nicht erst über Function-Konstruktoren zu verarbeiten.
Zum heutigen Zeitpunkt wurden keine aktiven Ausnutzungen in der Praxis beobachtet. Dennoch empfehlen Experten sofort zu handeln: Ein Update auf die gepatchten Versionen ist essentiell. Darüber hinaus sollten Systemadministratoren ihre transitorischen Abhängigkeiten überprüfen, Schema-Ladevorgänge als untrusted Input behandeln und in Produktionsumgebungen vorcompilierte oder statische Schemas bevorzugen.