CVE-2026-33620
Insecure Token Exposure via URL in PinchTab HTTP Server
Publication date: 2026-03-26
Last updated on: 2026-03-31
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.8 (inc) to 0.8.4 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-598 | The web application uses the HTTP GET method to process a request and includes sensitive information in the query string of that request. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-33620 is a security vulnerability in PinchTab versions 0.7.8 through 0.8.3 where the API bearer token could be supplied via a URL query parameter (?token=) in addition to the recommended Authorization header.
This practice exposed sensitive API tokens to potential leakage through server logs, intermediary systems, and client-side tools that record full request URIs, such as reverse proxy access logs, browser history, shell history, clipboard history, and tracing systems.
The vulnerability is not a direct authentication bypass but an unsafe credential transport pattern that increases the risk of token exposure if the token is included in URLs.
PinchTab's dashboard and setup wizard in version 0.8.3 generated URLs containing the token in the query string for convenience, which further increased the risk of accidental token exposure.
This issue was fixed in version 0.8.4 by removing support for token authentication via query parameters and requiring safer header- or session-based authentication flows.
How can this vulnerability impact me? :
The vulnerability can lead to exposure of valid API tokens through URLs, which lowers the barrier for credential compromise.
If an attacker gains access to logs, browser history, shell history, clipboard history, or tracing systems that recorded URLs containing the token, they could use the token to authenticate as a legitimate user.
This exposure increases the risk of unauthorized access to the PinchTab service, potentially allowing attackers to control the Chrome browser instances managed by PinchTab.
However, the vulnerability only affects deployments where the query-parameter token authentication is used; deployments using only the Authorization header are not affected.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring network traffic and logs for API tokens passed via URL query parameters, specifically the `?token=` parameter.
You can look for HTTP requests containing URLs with the `token` query parameter, such as `GET /health?token=<secret>`.
Commands to detect this might include searching reverse proxy or load balancer logs for URLs containing `?token=`.
- Use grep or similar tools on logs: `grep -r '\?token=' /var/log/nginx/`
- Capture and inspect network traffic with tools like tcpdump or Wireshark filtering for URLs containing `token=`.
- Search shell history or clipboard history for commands or URLs containing `token=`.
A proof of concept request to test the vulnerability is: `curl -i 'http://localhost:9867/health?token=supersecrettoken'` which should return HTTP 200 if vulnerable.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading PinchTab to version 0.8.4 or later, which removes support for token authentication via URL query parameters.
Stop using URLs that include API tokens in the query string and switch to using the Authorization header with the Bearer token.
Rotate any API tokens that may have been exposed through logs, browser history, or other means.
Avoid generating or sharing URLs containing live credentials.
Implement session-based or header-based authentication flows as recommended in the updated documentation.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability involves the exposure of API bearer tokens via URL query parameters, which can be recorded in logs, browser history, and other client-side tools. Such exposure of sensitive credentials increases the risk of unauthorized access to protected data.
From a compliance perspective, this unsafe credential transport pattern could lead to violations of data protection standards like GDPR or HIPAA, which require safeguarding sensitive information and ensuring secure authentication mechanisms.
Specifically, the leakage of tokens through logs or histories may result in unauthorized access to personal or protected health information, undermining confidentiality requirements mandated by these regulations.
The vulnerability was addressed in PinchTab v0.8.4 by removing support for token authentication via URL query parameters and enforcing safer header- or session-based authentication flows, which aligns better with compliance requirements for secure credential handling.