PinchTab up to 0.8.4 middleware.go authentication spoofing

Summaryinfo

A vulnerability identified as critical has been detected in PinchTab up to 0.8.4. The affected element is an unknown function of the file internal/handlers/middleware.go. Performing a manipulation results in authentication spoofing. This vulnerability was named CVE-2026-33621. The attack may be initiated remotely. There is no available exploit. You should upgrade the affected component.

Detailsinfo

A vulnerability was found in PinchTab up to 0.8.4. It has been classified as critical. This affects some unknown functionality of the file internal/handlers/middleware.go. The manipulation with an unknown input leads to a authentication spoofing vulnerability. CWE is classifying the issue as CWE-290. This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

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 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.

The advisory is shared at github.com. This vulnerability is uniquely identified as CVE-2026-33621 since 03/23/2026. The exploitability is told to be difficult. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Technical details are known, but no exploit is available.

Upgrading to version 0.8.5 eliminates this vulnerability. The upgrade is hosted for download at github.com. Applying the patch c619c43a4f29d1d1a481e859c193baf78e0d648b is able to eliminate this problem. The bugfix is ready for download at github.com. The best possible mitigation is suggested to be upgrading to the latest version.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Name

• PinchTab

Version

• 0.8.0
• 0.8.1
• 0.8.2
• 0.8.3
• 0.8.4

License

• open-source

Website

• Product: https://github.com/pinchtab/pinchtab/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion