Onderzoekers van Tel Aviv University, Technion en Intuit hebben aangetoond dat de aanvallen slopsquatting, phantom domains en hallusquatting in feite dezelfde onderliggende kwetsbaarheid in AI-coding agents misbruiken. Deze AI-modellen vertrouwen namelijk op gegenereerde namen die niet geverifieerd zijn, wat aanvallers in staat stelt om schadelijke software of domeinen te registreren en zo geautomatiseerde processen te compromitteren.

De aanval werkt doordat een aanvaller voorspelbare, door een taalmodel gegenereerde namen van softwarebibliotheken, domeinen of repositories vastlegt en vervolgens een val zet. Dit vereist geen diefstal van wachtwoorden, phishing of menselijke interactie; het enige wat nodig is, is dat een geautomatiseerd proces toestemming geeft om iets op te halen. Uit tests met diverse AI-coding agents zoals GitHub Copilot en Gemini CLI bleek dat deze modellen tot 85% dezelfde fictieve namen genereren bij repository-aanvragen en zelfs 100% bij skill-installaties.

De onderzoekers benadrukken dat deze aanvalsmethode, die zij hallusquatting noemen, verder gaat dan eerdere varianten zoals slopsquatting en phantom squatting. Waar die aanvallen gericht waren op het infecteren van één machine per keer, kan hallusquatting op grote schaal een botnet creëren zonder dat er sprake is van gestolen credentials of wormachtige verspreiding. Elke machine met een kwetsbare AI-agent kan zo een doelwit worden.

Deze kwetsbaarheid is het gevolg van een ontwerpprincipe dat bekend staat als late binding: taalmodellen genereren output op basis van waarschijnlijkheden, waardoor voorspelbare maar niet geverifieerde namen ontstaan. Dit probleem werd eerder al drie keer in zes maanden vastgesteld, waarbij onder meer nep-npm-pakketten en honderdduizenden domeinnamen werden geregistreerd voordat ze door AI-modellen werden gegenereerd.

De onderzoekers waarschuwen dat traditionele scanners en workflowcontroles deze aanval niet detecteren, omdat het probleem ligt in de samenstelling van processen en niet in individuele bestanden. Het is daarom noodzakelijk om de controle te verleggen naar het moment van binnenkomst in de build pipeline en niet alleen te vertrouwen op scans achteraf.