PinchTab versions 0.7.8 through 0.8.3 accepted an API bearer token supplied in a URL query string named token, which meant that the token was embedded in the exact request URI; because many systems record full request URLs in logs, browser history, shell history, clipboard history, or tracing systems, the token could be inadvertently exposed to anyone who could read those records. This flaw is an unsafe credential transport pattern (CWE-598) and results in a loss of confidentiality of the credential without directly granting authentication bypass or remote code execution. The exposure depends on whether a bearer token is configured and a client actually uses the query‑parameter form, and it is limited to deployments that adhere to the example flows that generate URLs containing the token.

All installations of PinchTab from version 0.7.8 through 0.8.3 that have a bearer token configured and have clients that send the token via the token query parameter are affected; this includes deployments that use the provided examples or helper scripts that generate URLs with the token.

The CVSS score of 4.3 denotes moderate severity; exploitation requires access to logs or history that contain the full request URL, which may occur via reverse‑proxy access logs, browser history, or other tracing systems that capture full URLs. Because the token can be read from these logs, an attacker could later use it to authenticate to the PinchTab API and issue arbitrary commands to the controlled Chrome instance. The EPSS score is not available and the vulnerability is not listed in CISA’s KEV catalog, suggesting a lower likelihood of widespread exploitation, but any environment that logs URLs or stores request history remains at risk until it is remediated. The likely attack vector is inferred from the description to be the compromise or reading of logs or user history that hold the token.