CVE-2026-33621
Incomplete Rate Limiting in PinchTab HTTP Server Allows Request Flooding
Publication date: 2026-03-26
Last updated on: 2026-04-22
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| pinchtab | pinchtab | From 0.7.7 (inc) to 0.8.5 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-290 | This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks. |
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
CVE-2026-33621 involves incomplete and improperly applied rate limiting on API token authentication endpoints in PinchTab, allowing unbounded brute-force attacks on tokens. This weakness reduces defense-in-depth and increases the risk of unauthorized access attempts, especially if weak tokens are used.
While the vulnerability does not directly disclose tokens or bypass authentication, the increased risk of brute-force token guessing could potentially lead to unauthorized access to sensitive data or systems.
From a compliance perspective, such a vulnerability could impact adherence to standards and regulations like GDPR or HIPAA, which require appropriate access controls and protection of sensitive data. The lack of effective rate limiting weakens security controls designed to prevent unauthorized access, which may be considered a failure to maintain adequate security measures under these regulations.
However, the default deployment model of PinchTab is local-first with binding to 127.0.0.1 and a randomly generated token, which lowers practical risk unless the API is intentionally exposed. Operators exposing the API beyond this default setup should be aware of the increased risk and ensure proper mitigation.
Can you explain this vulnerability to me?
CVE-2026-33621 is a moderate severity vulnerability in PinchTab versions 0.7.7 through 0.8.4 caused by incomplete and improperly applied rate limiting on API token authentication endpoints.
The vulnerability arises because a rate limiting middleware was fully implemented but not integrated into the production HTTP handler chain in versions 0.7.7 through 0.8.3, so no rate limiting was enforced.
Additionally, the rate limiter initially keyed clients based on the X-Forwarded-For header, which can be spoofed by attackers to bypass per-IP rate limits.
In version 0.8.4, the middleware was integrated and client IP identification improved by using the immediate peer IP, but the /health and /metrics endpoints were exempted from rate limiting, even though /health required authentication.
This allowed attackers to perform unlimited brute-force attempts on API tokens, especially weak or human-chosen tokens, by targeting auth-checkable endpoints without triggering rate limits.
The issue was fully fixed in version 0.8.5 by properly applying rate limiting, securing IP identification, and removing exemptions for auth-checkable endpoints.
How can this vulnerability impact me? :
This vulnerability allows attackers who can reach the PinchTab API to perform unlimited brute-force guessing attacks on API tokens.
If weak or human-chosen tokens are used, attackers can repeatedly attempt to guess these tokens without being throttled, increasing the risk of unauthorized access.
Although it does not directly disclose tokens or bypass authentication, it significantly reduces the system's resistance to online guessing attacks.
The default deployment model of PinchTab is local-first, binding to 127.0.0.1 with a randomly generated token, which lowers practical risk unless the API is intentionally exposed to a wider network.
For deployments exposing the API beyond the local environment, this vulnerability weakens defense-in-depth and increases the potential for abuse.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unbounded or unusually high rates of requests to auth-checkable endpoints such as /health or /metrics, especially if no HTTP 429 (Too Many Requests) responses are observed.
A proof of concept demonstrated rapid brute-force attempts against the /health endpoint with no rate limiting responses, achieving around 180 requests per second.
To detect exploitation attempts, you can use network monitoring tools or logs to identify high-frequency requests from single IPs or spoofed IPs (via X-Forwarded-For headers in affected versions).
Suggested commands include using curl or similar HTTP clients in a loop to test rate limiting behavior, for example:
- curl -H "Authorization: Bearer <token>" http://<pinchtab-host>/health
- Use a script to send multiple requests rapidly and observe if HTTP 429 responses are returned.
- Check server logs for absence of rate limiting or presence of spoofed X-Forwarded-For headers.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade PinchTab to version 0.8.5 or later, where the RateLimitMiddleware is properly integrated into the production HTTP handler chain.
This update ensures that rate limiting is enforced on all auth-checkable endpoints, including /health and /metrics, and that client IPs are derived from the immediate peer IP rather than trusting the X-Forwarded-For header.
Additional recommended measures include implementing auth-failure throttling to limit repeated invalid token attempts and avoiding the use of weak or human-chosen tokens.
If upgrading immediately is not possible, restrict network exposure of the PinchTab API to trusted local environments (e.g., bind to 127.0.0.1) and ensure strong, randomly generated tokens are used.