PinchTab, a lightweight HTTP server that gives AI agents control over a Chrome browser, contained incomplete request‑throttling protection for authentication‑checkable endpoints from versions 0.7.7 through 0.8.4. The RateLimitMiddleware existed but was not inserted into the production handler chain, and when present it keyed clients using the X‑Forwarded‑For header, allowing spoofing. In v0.8.4 the middleware was wired in and the key switched to the immediate peer IP, yet the /health and /metrics endpoints remained exempt from rate limiting even though /health could still be protected by a token. This flaw does not reveal tokens or bypass authentication, but it removes a crucial defense, allowing an attacker who can reach the API to brute‑force the token without limits. In the default local‑first deployment, the server listens on 127.0.0.1 and generates a random token, reducing practical risk, but the intrinsic weakness remains for any wider exposure. The issue was fully addressed in v0.8.5 by restoring the middleware in the production chain, deriving the client address from the immediate peer IP and removing the exemptions for auth‑checkable endpoints.

The affected product is PinchTab PinchTab. Versions from 0.7.7 through 0.8.4 are vulnerable. The vulnerability was closed in v0.8.5, which applied rate limiting to all relevant endpoints and used the immediate peer IP for client identification.

The CVSS base score of 4.8 indicates moderate severity. EPSS information is not available and the vulnerability is not listed in the CISA KEV catalog. The likely attack requires network reach to the PinchTab API; from such a position an attacker can send an unbounded number of requests to test or brute‑force the API token. If the token is weak, this could grant unauthorized control of the Chrome instance. Default local‑first configuration mitigates exposure, but any remote exposure or intentionally exposed deployment continues to be subject to this flaw.