CVE-2026-33621 in PinchTab
Riassunto
di VulDB • 17/06/2026
PinchTab è un server HTTP autonomo che fornisce agli agenti AI il controllo diretto su un browser Chrome. Le versioni di PinchTab da `v0.7.7` a `v0.8.4` presentano protezioni incomplete per la limitazione della frequenza delle richieste (request-throttling) sugli endpoint verificabili tramite autenticazione. Nelle versioni da `v0.7.7` a `v0.8.3`, era presente un'implementazione completa di `RateLimitMiddleware` in `internal/handlers/middleware.go`, ma non veniva inserito nella catena dei gestori HTTP (handler chain) di produzione, pertanto le richieste non erano soggette alla limitazione per IP prevista. Nello stesso intervallo precedente a `v0.8.4`, il limiter originale utilizzava l'intestazione `X-Forwarded-For` come chiave per identificare i client; ciò avrebbe consentito lo spoofing delle intestazioni controllato dal cliente se il middleware fosse stato abilitato. La versione `v0.8.4` ha affrontato questi due problemi collegando il limiter alla catena dei gestori in esecuzione e passando l'utilizzo dell'IP del peer immediato come chiave, ma ha comunque escluso gli endpoint `/health` e `/metrics` dalla limitazione della frequenza, nonostante `/health` rimanesse un endpoint verificabile tramite autenticazione quando era configurato un token. Questa vulnerabilità indebolisce la difesa in profondità per le distribuzioni in cui un attaccante può raggiungere l'API, specialmente se viene utilizzato un token scelto dall'utente con bassa complessità. Di per sé, non si tratta di una violazione diretta dell'autenticazione o di una divulgazione del token. PinchTab è documentato come "local-first" (priorità all'uso locale) per impostazione predefinita e utilizza `127.0.0.1` insieme a un token casuale generato automaticamente nella configurazione consigliata. Il modello di distribuzione predefinito di PinchTab prevede un ambiente controllato dall'utente tra l'operatore e i suoi agenti, con priorità all'uso locale; una maggiore esposizione è una scelta intenzionale dell'operatore. Ciò riduce il rischio pratico nella configurazione predefinita, anche se non modifica di per sé le caratteristiche intrinseche alla base del bug. Il problema è stato completamente risolto in `v0.8.5` applicando `RateLimitMiddleware` nella catena dei gestori di produzione, derivando l'indirizzo del client dall'IP del peer immediato invece di fidarsi delle intestazioni inoltrate per impostazione predefinita e rimuovendo l'esclusione degli endpoint `/health` e `/metrics`, in modo che anche gli endpoint verificabili tramite autenticazione siano soggetti a limitazione della frequenza.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.