Nach Darstellung von Intruder liegt die zentrale Schwierigkeit beim Zusammenspiel von KI und Code-Scanning in der Fokussierung. Große Sprachmodelle seien gut darin, kleine Codeausschnitte oder klar umrissene Probleme zu analysieren. Bei großen Codebasen verschlechtere sich die Trefferqualität jedoch, weil zu viel irrelevanter Kontext verarbeitet werde. Gerade bei komplexeren Fehlern, die mehrere Schritte erfordern, führe das nach den Erfahrungen des Unternehmens eher zu schwachen Ergebnissen als zu belastbaren Funden.

Deshalb kombiniert Intruder die Modelle mit klassischer statischer Codeanalyse. Verwendet wird laut dem Bericht Joern. Die Pipeline nimmt eine Codebasis, lässt sie von der Scan-Engine analysieren, erzeugt zu jedem Fund relevante Programmausschnitte und übergibt diese dann an ein Sprachmodell zur Triage und Ausnutzungsprüfung. Inspiriert sei der Aufbau von der Arbeit von nooperator an Slice, wobei Intruder Joern statt CodeQL einsetzt und den Slicing-Algorithmus nach eigenen Angaben deutlich anders ausgelegt hat.

Für den Versuch richtete Intruder den Blick auf unauthentifizierte Angriffsflächen in WordPress-Plugins. Joern sollte dafür alle Stellen identifizieren, an denen ein Skript durch Nutzereingaben beeinflusst werden kann, darunter REST-Routen, Template-Hooks und nopriv-AJAX-Aufrufe. Für jeden WordPress-Hook erzeugt das System dann einen Programmausschnitt, der die aufgerufene Funktion und die nachgelagerte Aufrufkette umfasst. Eine einfache Taint-Analyse filtert dabei Funktionen aus, die als offensichtlich sicher gelten, etwa wenn Eingaben für SQL oder XSS durch bekannte sichere Sanitizer laufen.

Diese Ausschnitte gehen zunächst an ein kleineres Triage-Modell, in den Tests Sonnet, das offenkundig uninteressante Fälle aussortiert. Was übrig bleibt, wird laut Intruder an ein leistungsstärkeres Modell namens Opus übergeben, das die Ausnutzbarkeit mit vollständigem relevantem Aufrufkontext bewerten soll. Falls eine Schwachstelle als ausnutzbar eingestuft wird, übernimmt ein letzter Agent die Exploit-Entwicklung. Dieser hat bei Bedarf wieder Zugriff auf den vollständigen Quelltext und startet zudem einen Docker-Container mit der Software, um die Versuche zu testen.

Der erste auf diesem Weg entdeckte Fehler war laut Intruder CVE-2026-3985 in Creative Mail. Das Unternehmen stuft die Schwachstelle als folgenschwer ein, weil sie Lesezugriff auf die Datenbank ermöglichen soll, einschließlich Administrator-Hashes und geheimer Token. Zugleich sei die Ausnutzung mehrstufig und erfordere mehrere verkettete Anfragen, was sie für herkömmliche Werkzeuge schwerer erkennbar mache. Als zusätzliche Besonderheit nennt Intruder, dass die eigentliche Ursache durch einen Fehler im Code vor der statischen Analyse des Entwicklers verborgen geblieben sei.

Für die Ausnutzung muss WooCommerce neben Creative Mail installiert sein. Laut Intruder ist diese Kombination verbreitet, weil WooCommerce mehr als 7 Millionen aktive Installationen habe. Der Exploit-Agent habe auf Anhieb einen funktionierenden Proof of Concept erzeugt, darunter eine Prüfroutine zum Nachweis der Schwachstelle und eine vollständige Methode, um Passwort-Hashes aus der Datenbank auszulesen.

Unabhängig davon wurde die Schwachstelle laut Quelltext auch von Dmitrii Ignatyev von CleanTalk Inc. gefunden, der sie an Wordfence meldete. Das Plugin wurde bis zur Überprüfung aus dem WordPress-Store entfernt. Intruder erklärt zudem, bereits weitere Schwachstellen mit derselben Pipeline zu finden und sie an die betroffenen Hersteller zu melden; diese Fälle seien noch im Offenlegungsprozess.