Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Vulnerabilidad en pinchtab (CVE-2026-33619)

Gravedad CVSS v3.1:
MEDIA
Tipo:
CWE-918 Falsificación de solicitud en servidor (SSRF)
Fecha de publicación:
26/03/2026
Última modificación:
26/03/2026

Descripción

PinchTab es un servidor HTTP autónomo que otorga a los agentes de IA control directo sobre un navegador Chrome. PinchTab v0.8.3 contiene un problema de falsificación de petición del lado del servidor en la ruta de entrega de webhook del programador opcional. Cuando se envía una tarea a 'POST /tasks' con una 'callbackUrl' controlada por el usuario, el programador v0.8.3 envía un 'POST' HTTP saliente a esa URL cuando la tarea alcanza un estado terminal. En esa versión, la ruta del webhook validaba solo el esquema de la URL y no rechazaba destinos de bucle invertido, privados, de enlace local u otros no públicos. Debido a que la implementación v0.8.3 también utilizaba el comportamiento predeterminado del cliente HTTP, se seguían las redirecciones y el destino no estaba fijado a IPs validadas. Esto permitía SSRF ciego desde el servidor PinchTab a objetivos HTTP(S) elegidos por el atacante accesibles desde el servidor. Este problema es más limitado que un SSRF general no autenticado y expuesto a internet. El programador es opcional y está desactivado por defecto, y en implementaciones protegidas por token el atacante ya debe ser capaz de enviar tareas utilizando el token maestro de la API del servidor. En el modelo de implementación previsto de PinchTab, ese token representa control administrativo en lugar de un rol de bajo privilegio. Las implementaciones sin token reducen aún más la barrera, pero eso es un estado de configuración inseguro separado en lugar del impacto creado por el propio error del webhook. El modelo de implementación predeterminado de PinchTab es local-first y controlado por el usuario, con enlace de bucle invertido y acceso basado en token en la configuración recomendada. Eso reduce el riesgo práctico en el uso predeterminado, aunque no elimina el problema subyacente del webhook cuando el programador está habilitado y es accesible. Esto se abordó en la v0.8.4 validando los objetivos de callback antes del envío, rechazando rangos de IP no públicos, fijando la entrega a IPs validadas, deshabilitando el seguimiento de redirecciones y validando 'callbackUrl' durante el envío de tareas.