Der Kern des Problems liegt in einer standardisierten web.config-Datei, die der Hersteller mitlieferte und die fest hinterlegte machineKey-Werte enthielt. Diese Schlüssel verwendet das ASP.NET-Framework, um Daten zu verschlüsseln und zu signieren, darunter auch ViewState-Inhalte. Da alle Installationen dieselben Werte nutzten, konnte ein Angreifer, der die Schlüssel aus einer einzigen Installation erbeutete, damit weitere über das Internet erreichbare KnowledgeDeliver-Instanzen kompromittieren.

Google erläutert den technischen Ablauf: Der ASP.NET-ViewState hält den Seitenzustand über sogenannte Postbacks hinweg vor. Ist der machineKey bekannt, lässt sich ein manipulierter ViewState erzeugen. Wird dieser über den Parameter __VIEWSTATE in einer HTTP-Anfrage übermittelt, deserialisiert ihn der Server – und führt damit den eingeschleusten Code aus.

In den im Zusammenhang mit CVE-2026-5426 beobachteten Angriffen brachten die Täter die Webshell Godzilla (auch BLUEBEAM genannt) ein, über die sie Befehle ausführen oder weitere Schadprogramme nachladen konnten. Unter den ausgeführten Befehlen fanden sich Anweisungen, die Kontrolle über das Dateisystem des Webservers auszuweiten, indem dem Konto „Jeder" Vollzugriff auf das Verzeichnis der Webanwendung gewährt wurde.

Anschließend manipulierte der Akteur eine JavaScript-Datei der Anwendung. Der eingefügte Code zeigte Besuchern eine gefälschte Sicherheitswarnung an, die sie zur Installation eines vermeintlichen „Sicherheits-Authentifizierungs-Plugins" drängte. Zugleich ermöglichten die Änderungen, unbemerkt ein Schadskript von einer durch die Angreifer kontrollierten Domain nachzuladen. Dieses Skript bewegte die Nutzer dazu, einen gefälschten Installer herunterzuladen, der die Rechner schließlich mit Cobalt Strike Beacon infizierte.

Auf eine gezielte Vorbereitung deutet laut Google die Verschlüsselung der Schadlast hin: „Die Nutzlast wurde mit einem Schlüssel verschlüsselt, der den Namen der kompromittierten Organisation verwendete, was darauf hindeutet, dass der Angreifer diese Nutzlast eigens für die betroffene Organisation vorbereitet hatte."

Google ordnet den Fall als Beispiel für die Risiken gemeinsam genutzter Geheimnisse in Bereitstellungsvorlagen ein: Ein einziger durchgesickerter Schlüssel könne ein ganzes Ökosystem von Installationen kompromittieren. Mit individuellen Geheimnissen und einer belastbaren Überwachung der Endpunkte ließen sich solche Deserialisierungsangriffe abwehren.