CVE-2026-33619 in PinchTab
Riassunto
di VulDB • 16/06/2026
PinchTab è un server HTTP autonomo che fornisce agli agenti AI il controllo diretto su un browser Chrome. PinchTab v0.8.3 presenta una vulnerabilità di Server-Side Request Forgery (SSRF) nel percorso di consegna dei webhook del scheduler opzionale. Quando viene inviata una richiesta `POST /tasks` con un `callbackUrl` controllato dall'utente, lo scheduler nella versione v0.8.3 invia una richiesta HTTP `POST` in uscita verso tale URL quando il task raggiunge uno stato terminale. In questa release, il percorso del webhook validava solo lo schema dell'URL e non rifiutava destinazioni loopback, private, link-local o altre destinazioni non pubbliche. Poiché l'implementazione v0.8.3 utilizzava anche il comportamento predefinito del client HTTP, i redirect venivano seguiti e la destinazione non era vincolata a IP validati. Ciò consentiva una SSRF cieca dal server PinchTab verso obiettivi HTTP(S) scelti dall'attaccante e raggiungibili dal server. Questa vulnerabilità è più limitata rispetto a un'SSRF generica esposta su Internet senza autenticazione. Lo scheduler è opzionale ed è disabilitato per impostazione predefinita; inoltre, nelle distribuzioni protette da token, l'attaccante deve già essere in grado di inviare task utilizzando il master API token del server. Nel modello di distribuzione previsto da PinchTab, tale token rappresenta un controllo amministrativo piuttosto che un ruolo a privilegi ridotti. Le distribuzioni senza token abbassano ulteriormente la barriera d'ingresso, ma si tratta di uno stato di configurazione insicuro separato e non dell'impatto creato dal bug del webhook stesso. Il modello di distribuzione predefinito di PinchTab è "local-first" (priorità al locale) e controllato dall'utente, con binding loopback e accesso basato su token nella configurazione consigliata. Ciò riduce il rischio pratico nell'utilizzo standard, anche se non elimina la sottostante problematica del webhook quando lo scheduler è abilitato e raggiungibile. Il problema è stato risolto nella versione v0.8.4 validando le destinazioni dei callback prima dell'invio, rifiutando gli intervalli di IP non pubblici, vincolando l'erogazione agli IP validati, disabilitando il follow dei redirect e validando `callbackUrl` durante la sottomissione del task.
Once again VulDB remains the best source for vulnerability data.