Il 22 giugno 2026 Help Net Security ha pubblicato un'analisi video di Ax Sharma, Head of Research presso Manifold Security, su un caso di scope squatting nel registry ClawHub dedicato ai plugin per agenti AI. Ventitré plugin in grado di eseguire codice erano disponibili sotto gli scope ufficiali @openclaw e @clawhub, ma appartenevano a account non correlati ai legittimi proprietari del namespace.
Il caso riproduce un pattern consolidato nei registry software tradizionali, con una differenza critica: i plugin AI operano con i privilegi dell'agente autonomo, amplificando la superficie di danno di eventuali errori di installazione.
- 23 plugin code-executing su ClawHub erano pubblicati sotto scope
@openclawe@clawhubma controllati da account non autorizzati, secondo la fonte. - Gli scope ufficiali non erano riservati ai legittimi owner per ogni pacchetto già pubblicato, permettendo la sovrapposizione di namespace.
- Il rischio supply chain persiste anche in assenza di codice malevolo, poiché lo scope ufficiale-lookalike induce a fiducia ingiustificata.
- Il registry ha apportato modifiche dopo la disclosure, ma la fonte non specifica la natura esatta delle correzioni o la completezza del fix.
Il meccanismo: scope npm-style senza binding di proprietà
ClawHub adotta una convenzione di naming ereditata da npm: il prefisso @vendor/package funge da indicatore visivo di provenienza. La fonte documenta che questa struttura non implementava una prenotazione esclusiva dello scope al legittimo proprietario per i 23 pacchetti già esistenti. Il risultato è che terzi hanno potuto pubblicare plugin visivamente indistinguibili da quelli ufficiali.
La differenza rispetto a npm sta nel contesto di esecuzione. I plugin per agenti AI eseguono codice con i privilegi dell'agente, operando su dati di sessione. La fonte non dettaglia quali agenti specifici fossero interessati né il volume di installazioni, ma il pattern di namespace confusion in questo contesto espone a rischi di trust escalation automatica.
"23 code-executing plugins ended up under ClawHub's official @openclaw and @clawhub scopes while owned by unrelated accounts"
Perché il codice non malevolo resta un rischio
Una delle claim centrali del dossier è che il pericolo non dipende dalla presenza di payload dannoso. Ax Sharma enuncia il principio che uno scope dal nome ufficiale costituisce un rischio supply chain anche quando il codice è benigno. Il meccanismo è di natura epistemica: l'utente o l'agente AI che seleziona il plugin basa la decisione su un segnale di trust — lo scope — che non è garantito dalla piattaforma.
Questo aspetto è particolarmente rilevante per l'economia degli agenti autonomi. Un agente che risolve task in modo proattivo può selezionare e installare plugin senza intervento umano diretto, basandosi su metadati di registry. Se lo scope è squattato, l'agente non dispone di un criterio per discriminare tra publisher legittimo e impersonatore. La fonte non specifica se ClawHub implementi verifiche di binding tra identità e namespace.
La reazione del registry e i punti oscuri
Help Net Security riferisce che il registry ha effettuato modifiche dopo la disclosure, ma non fornisce dettagli tecnici sulle misurate adottate. Resta ignoto se le correzioni abbiano incluso: riservazione retroattiva degli scope ai legittimi owner, verifica manuale per i 23 publisher esistenti, introduzione di meccanismi di attestazione, o altre contromisure. La timeline completa non è documentata dalla fonte.
Il dossier non specifica nemmeno se i 23 plugin squatting siano stati rimossi, trasferiti, o se permangano accessibili con modifiche di visibilità. Questo limite informativo è significativo per chi valuta l'esposizione attuale: senza accesso al report primario di Manifold Security, la valutazione dello stato del rischio resta parziale.
Cosa fare adesso
Per chi opera con registry AI come ClawHub, il caso evidenzia azioni concrete e specifiche:
- Verificare il publisherID anziché lo scope visivo: la fonte documenta che gli scope
@openclawe@clawhuberano occupati da account "unrelated", quindi il nome del namespace non garantisce l'autenticità del publisher. - Controllare la data di pubblicazione rispetto alla timeline della disclosure del 22 giugno 2026: i 23 plugin squatting precedevano la correzione, quindi pacchetti con quella data di prima pubblicazione richiedono scrutinio aggiuntivo.
- Non installare plugin da scope ufficiali senza conferma cross-source: la fonte primaria è un video di Manifold Security su Help Net Security, non un advisory di ClawHub, quindi il registry non ha rilasciato guidance ufficiale su quali account siano legittimi.
- Monitorare il changelog di policy di ClawHub: la fonte cita modifiche non specificate, quindi eventuali aggiornamenti di binding scope-owner andrebbero verificati direttamente sulla piattaforma.
Il principio generale documentato dalla fonte — che "security gaps appear right alongside" nuovi registry AI — implica che questa verifica debba estendersi a ogni registry di plugin agentic con namespace simili, non solo a ClawHub.
Il pattern sistemico nei registry AI
Il caso ClawHub è un indicatore di pattern sistemico nei registry AI emergenti. La fonte esplicita che "as new AI tools, assets, and registries appear, security gaps appear right alongside them". Il parallelismo con npm pre-2016 è funzionale: i registry AI stanno replicando errori architetturali noti, con l'aggravante che gli agenti autonomi eseguono codice di terzi senza conferma umana.
Per le organizzazioni che integrano agenti AI tramite plugin registry, la combinazione di namespace trust non verificato e automazione dell'esecuzione costituisce un vettore distintivo rispetto all'ecosistema package manager tradizionale. La provenienza del codice non può essere inferita dalla sola struttura del nome.
Domande frequenti
Cos'è lo scope squatting e come si distingue dal typosquatting?
Lo scope squatting consiste nella pubblicazione di pacchetti sotto namespace ufficiali (@vendor/package) da parte di account non autorizzati, sfruttando l'assenza di binding esclusivo tra nome e proprietario legittimo. Il typosquatting sfrutta invece errori di digitatura del nome del pacchetto. La fonte documenta il primo caso per ClawHub; non menziona il secondo.
I 23 plugin contenevano codice malevolo?
La fonte non verifica la presenza di codice malevolo. Anzi, Ax Sharma enuncia esplicitamente che "an official-looking scope is a supply chain risk even when the code isn't malicious". Il rischio deriva dalla confusione di namespace, non dalla malignità del payload.
Il problema è stato risolto completamente?
La fonte cita "what the registry changed after the disclosure", ma non attesta la risoluzione completa. Non sono noti i dettagli delle modifiche né se i 23 plugin siano stati rimossi o trasferiti. La valutazione dello stato attuale resta parziale.
Quali agenti AI sono interessati?
La fonte non specifica quali agenti AI utilizzino i plugin di ClawHub né il volume di installazioni degli scope @openclaw e @clawhub. Il problema è architetturale del registry, non legato a una vulnerabilità di singoli agenti.
Fonti
Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.
Fonti
- https://schema.org/FAQPage
- https://schema.org/Question
- https://schema.org/Answer
- https://www.helpnetsecurity.com/view/features/
- https://www.helpnetsecurity.com/view/video/
- https://www.helpnetsecurity.com/view/industry-news/
- https://www.helpnetsecurity.com/view/reviews/