Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:NSummary
CVE-2026-33621 is a medium-severity Authentication Bypass by Spoofing (CWE-290) vulnerability in Pinchtab Pinchtab. Its CVSS base score is 4.8 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Brute Force (T1110); ranked at the 23th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
This vulnerability is AI-related — categorised as AI Agent Protocols and Integrations; in the Supply Chain and Deployment risk domain.
The strongest mitigations our analysis identified map to AC-7 (Unsuccessful Logon Attempts) and SC-5 (Denial-of-service Protection) — see the control section below for these in your framework.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-16403
Vulnerability Data
PinchTab is a standalone HTTP server that gives AI agents direct control over a Chrome browser. PinchTab `v0.7.7` through `v0.8.4` contain incomplete request-throttling protections for auth-checkable endpoints. In `v0.7.7` through `v0.8.3`, a fully implemented `RateLimitMiddleware` existed in `internal/handlers/middleware.go` but was…
more
not inserted into the production HTTP handler chain, so requests were not subject to the intended per-IP throttle. In the same pre-`v0.8.4` range, the original limiter also keyed clients using `X-Forwarded-For`, which would have allowed client-controlled header spoofing if the middleware had been enabled. `v0.8.4` addressed those two issues by wiring the limiter into the live handler chain and switching the key to the immediate peer IP, but it still exempted `/health` and `/metrics` from rate limiting even though `/health` remained an auth-checkable endpoint when a token was configured. This issue weakens defense in depth for deployments where an attacker can reach the API, especially if a weak human-chosen token is used. It is not a direct authentication bypass or token disclosure issue by itself. PinchTab is documented as local-first by default and uses `127.0.0.1` plus a generated random token in the recommended setup. PinchTab's default deployment model is a local-first, user-controlled environment between the user and their agents; wider exposure is an intentional operator choice. This lowers practical risk in the default configuration, even though it does not by itself change the intrinsic base characteristics of the bug. This was fully addressed in `v0.8.5` by applying `RateLimitMiddleware` in the production handler chain, deriving the client address from the immediate peer IP instead of trusting forwarded headers by default, and removing the `/health` and `/metrics` exemption so auth-checkable endpoints are throttled as well.
- CWE(s)
AI Security AnalysisAI
- AI Category
- AI Agent Protocols and Integrations
- Risk Domain
- Supply Chain and Deployment
- OWASP Top 10 for LLMs 2025
- None mapped
- Classification Reason
- Matched keywords: ai
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Missing/bypassable rate limiting on auth endpoints directly facilitates brute-force attempts (T1110) against tokens and resource exhaustion (T1499).
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Directly enforces throttling of authentication attempts on the auth-checkable endpoints that lacked rate limiting.
Supplies the missing per-IP request throttling that was never wired into the handler chain or was bypassed via headers/exemptions.
Boundary protection mechanisms can enforce equivalent rate limiting at the network ingress before requests reach the vulnerable endpoints.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Protecting, conveying, and verifying identity assertions specifically prevents the spoofing that enables authentication bypass.
Requiring authentication of users/services/hardware directly counters spoofing-based bypass when strong methods are used.
Monitoring capacity and taking action to maintain availability directly reduces unchecked resource allocation.
Proofing and binding identities reduces spoofing opportunities during enrollment but does not address runtime authentication implementation flaws.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Secure authentication control directly mitigates authentication bypass by spoofing.
Authentication information management directly addresses credential handling that prevents spoofing.
Baseline comparison of CPU, memory and bandwidth usage helps surface uncontrolled resource allocations before they cause service degradation.
Security testing can detect spoofing vulnerabilities but does not prevent them by itself.
Capacity projections and elasticity measures ensure that allocation requests are bounded and can be throttled, reducing the window in which an attacker can force unbounded resource reservations.
Access control policy reduces spoofing opportunities but does not prescribe authentication mechanisms.