{ "document": { "category": "csaf_base", "csaf_version": "2.0", "distribution": { "tlp": { "label": "WHITE" } }, "lang": "en", "notes": [ { "category": "legal_disclaimer", "text": "The Netherlands Cyber Security Center (henceforth: NCSC-NL) maintains this portal to enhance access to its information and vulnerabilities. The use of this information is subject to the following terms and conditions:\n\nThe vulnerabilities disclosed in this portal are gathered by NCSC-NL from a variety of open sources, which the user can retrieve from other platforms. NCSC-NL makes every reasonable effort to ensure that the content of this portal is kept up to date, and that it is accurate and complete. Nevertheless, NCSC-NL cannot entirely rule out the possibility of errors, and therefore cannot give any warranty in respect of its completeness, accuracy or real-time keeping up-to-date. NCSC-NL does not control nor guarantee the accuracy, relevance, timeliness or completeness of information obtained from these external sources. The vulnerabilities disclosed in this portal are intended solely for the convenience of professional parties to take appropriate measures to manage the risks posed to the cybersecurity. No rights can be derived from the information provided therein.\n\nNCSC-NL and the Kingdom of the Netherlands assume no legal liability or responsibility for any damage resulting from either the use or inability of use of the vulnerabilities disclosed in this portal. This includes damage resulting from the inaccuracy of incompleteness of the information contained in it.\nThe information on this page is subject to Dutch law. All disputes related to or arising from the use of this portal regarding the disclosure of vulnerabilities will be submitted to the competent court in The Hague. This choice of means also applies to the court in summary proceedings." } ], "publisher": { "category": "coordinator", "contact_details": "cert@ncsc.nl", "name": "National Cyber Security Centre", "namespace": "https://www.ncsc.nl/" }, "title": "CVE-2026-33620", "tracking": { "current_release_date": "2026-03-31T16:26:32.786508Z", "generator": { "date": "2026-02-17T15:00:00Z", "engine": { "name": "V.E.L.M.A", "version": "1.7" } }, "id": "CVE-2026-33620", "initial_release_date": "2026-03-25T00:59:59.802996Z", "revision_history": [ { "date": "2026-03-25T00:59:59.802996Z", "number": "1", "summary": "CVE created.| Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (3).| CWES updated (1)." }, { "date": "2026-03-25T01:00:01.529612Z", "number": "2", "summary": "NCSC Score created." }, { "date": "2026-03-25T18:12:49.672034Z", "number": "3", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products created (1).| References created (2).| CWES updated (1)." }, { "date": "2026-03-25T18:12:51.940370Z", "number": "4", "summary": "NCSC Score updated." }, { "date": "2026-03-26T21:27:25.887491Z", "number": "5", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (2).| CWES updated (1)." }, { "date": "2026-03-26T21:27:33.117139Z", "number": "6", "summary": "NCSC Score updated." }, { "date": "2026-03-26T21:38:41.994702Z", "number": "7", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products connected (1).| References created (2).| CWES updated (1)." }, { "date": "2026-03-26T21:38:50.074493Z", "number": "8", "summary": "NCSC Score updated." }, { "date": "2026-03-27T00:14:12.329467Z", "number": "9", "summary": "Source created.| CVE status created. (valid)| Description created for source.| References created (2)." }, { "date": "2026-03-27T20:56:41.532197Z", "number": "10", "summary": "Source connected.| CVE status created. (valid)| EPSS created." }, { "date": "2026-03-27T20:56:45.653613Z", "number": "11", "summary": "NCSC Score updated." }, { "date": "2026-03-28T07:57:44.290373Z", "number": "12", "summary": "References created (1)." }, { "date": "2026-03-30T15:39:47.532539Z", "number": "13", "summary": "Unknown change." }, { "date": "2026-03-31T16:24:57.532835Z", "number": "14", "summary": "Products connected (1).| Product Identifiers created (1).| Exploits created (1)." }, { "date": "2026-03-31T16:25:06.889773Z", "number": "15", "summary": "NCSC Score updated." } ], "status": "interim", "version": "15" } }, "product_tree": { "branches": [ { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:unknown/>=0.7.8|<0.8.4", "product": { "name": "vers:unknown/>=0.7.8|<0.8.4", "product_id": "CSAFPID-5907192", "product_identification_helper": { "cpe": "cpe:2.3:a:pinchtab:pinchtab:*:*:*:*:*:*:*:*" } } } ], "category": "product_name", "name": "pinchtab" } ], "category": "vendor", "name": "pinchtab" } ] }, "vulnerabilities": [ { "cve": "CVE-2026-33620", "cwe": { "id": "CWE-598", "name": "Use of GET Request Method With Sensitive Query Strings" }, "notes": [ { "category": "description", "text": "### Summary\nPinchTab `v0.7.8` through `v0.8.3` accepted the API token from a `token` URL query parameter in addition to the `Authorization` header. When a valid API credential is sent in the URL, it can be exposed through request URIs recorded by intermediaries or client-side tooling, such as reverse proxy access logs, browser history, shell history, clipboard history, and tracing systems that capture full URLs.\n\nThis issue is an unsafe credential transport pattern rather than a direct authentication bypass. It only affects deployments where a token is configured and a client actually uses the query-parameter form. PinchTab's security guidance already recommended `Authorization: Bearer `, but `v0.8.3` still accepted `?token=` and included first-party flows that generated and consumed URLs containing the token.\n\nThis was addressed in v0.8.4 by removing query-string token authentication and requiring safer header- or session-based authentication flows.\n\n### Details\n**Issue 1 — Query-string token accepted in `v0.7.8` through `v0.8.3` (`internal/handlers/middleware.go`):**\nThe `v0.8.3` authentication middleware accepted credentials from the URL query string:\n\n```\n// internal/handlers/middleware.go — v0.8.3\nauth := r.Header.Get(\"Authorization\")\nqToken := r.URL.Query().Get(\"token\")\n\nif auth == \"\" && qToken == \"\" {\n web.ErrorCode(w, 401, \"missing_token\", \"unauthorized\", false, nil)\n return\n}\n\nprovided := strings.TrimPrefix(auth, \"Bearer \")\nif provided == auth {\n if qToken != \"\" {\n provided = qToken\n } else {\n provided = auth\n }\n}\n\nif subtle.ConstantTimeCompare([]byte(provided), []byte(cfg.Token)) != 1 {\n web.ErrorCode(w, 401, \"bad_token\", \"unauthorized\", false, nil)\n return\n}\n```\n\nThis means any client sending `GET /health?token=` in `v0.8.3` would authenticate successfully without using the `Authorization` header. I verified the same query-token auth pattern is present in the historical tag range starting at `v0.7.8`, and it is removed in `v0.8.4`.\n\n**Issue 2 — First-party setup and dashboard flows in `v0.8.3` generated and consumed `?token=` URLs:**\nThe `v0.8.3` setup flow generated dashboard URLs containing the token in the query string:\n\n```\n// cmd/pinchtab/cmd_wizard.go — v0.8.3\nfunc dashboardURL(cfg *config.FileConfig, path string) string {\n host := orDefault(cfg.Server.Bind, \"127.0.0.1\")\n port := orDefault(cfg.Server.Port, \"9867\")\n url := fmt.Sprintf(\"http://%s:%s%s\", host, port, path)\n if cfg.Server.Token != \"\" {\n url += \"?token=\" + cfg.Server.Token\n }\n return url\n}\n```\n\nThe `v0.8.3` dashboard frontend also supported one-click login from that same query-string token:\n\n```\n// dashboard/src/App.tsx — v0.8.3\nconst params = new URLSearchParams(window.location.search);\nconst urlToken = params.get(\"token\");\nif (urlToken) {\n setStoredAuthToken(urlToken);\n clean.searchParams.delete(\"token\");\n window.history.replaceState({}, \"\", clean.pathname + clean.hash);\n window.location.reload();\n}\n```\n\nThat combination materially increased the chance that users would open, copy, paste, bookmark, or log URLs containing live credentials before the token was scrubbed from the visible address bar.\n\n**Issue 3 — Exposure depends on surrounding systems recording the URL:**\nPinchTab's own request logger records `r.URL.Path`, not the full raw query string, so the leak is not primarily through PinchTab's structured application log. The risk comes from surrounding systems or client tooling that record the full request URI, such as:\n\n1. reverse proxies and load balancers\n2. browser history or bookmarks\n3. shell history containing full `curl` commands\n4. clipboard or terminal history when the wizard prints and copies a tokenized URL\n5. tracing or monitoring systems that capture full request URLs\n\n### PoC\n**Step 1 — Confirm auth is required**\n\n```bash\ncurl -i http://localhost:9867/health\n```\n\nExpected in token-protected affected deployments:\n\n```http\nHTTP/1.1 401 Unauthorized\n```\n\n**Step 2 — Authenticate using the vulnerable query-parameter pattern**\n\n```bash\ncurl -i \"http://localhost:9867/health?token=supersecrettoken\"\n```\n\nExpected:\n\n```http\nHTTP/1.1 200 OK\n```\n\nThis demonstrates that the token is accepted from the URL.\n\n**Step 3 — Observe the exposure vector**\nIf the request traverses a system that records the full URI, the token may appear in logs or local history, for example:\n\n```text\nGET /health?token=supersecrettoken HTTP/1.1\n```\n\nIn `v0.8.3`, a first-party reproduction path also exists without any external proxy: run the setup wizard, copy the printed dashboard URL containing `?token=...`, and note that the live credential is now present in clipboard history and any place that URL is pasted.\n\n### Impact\n1. Exposure of a valid API token through unsafe URL-based transport when a client uses the `?token=` authentication form.\n2. Lower barrier for credential compromise where reverse proxies, browser history, shell history, clipboard history, or tracing systems retain full request URIs.\n3. The `v0.8.3` wizard/dashboard flow increased the practical likelihood of this exposure by generating and consuming tokenized URLs as a first-party login pattern.\n4. Practical risk depends on actual use of the query-token pattern; deployments that use only `Authorization: Bearer ` are not affected by this issue in practice.\n5. This is not a direct authentication bypass. An attacker still needs access to a secondary source that captured the URL containing the token.\n\n### Suggested Remediation\n1. Reject query-string token authentication and accept credentials only through the `Authorization` header or controlled session mechanisms.\n2. Avoid generating user-facing URLs that contain live credentials.\n3. Document header-based auth as the only supported non-browser API authentication pattern.\n4. Recommend token rotation for users who may previously have used query-parameter authentication.\n\n**Screenshot Capture**\n\"ภาพถ่ายหน้าจอ", "title": "github - https://api.github.com/advisories/GHSA-mrqc-3276-74f8" }, { "category": "description", "text": "### Summary\nPinchTab `v0.7.8` through `v0.8.3` accepted the API token from a `token` URL query parameter in addition to the `Authorization` header. When a valid API credential is sent in the URL, it can be exposed through request URIs recorded by intermediaries or client-side tooling, such as reverse proxy access logs, browser history, shell history, clipboard history, and tracing systems that capture full URLs.\n\nThis issue is an unsafe credential transport pattern rather than a direct authentication bypass. It only affects deployments where a token is configured and a client actually uses the query-parameter form. PinchTab's security guidance already recommended `Authorization: Bearer `, but `v0.8.3` still accepted `?token=` and included first-party flows that generated and consumed URLs containing the token.\n\nThis was addressed in v0.8.4 by removing query-string token authentication and requiring safer header- or session-based authentication flows.\n\n### Details\n**Issue 1 — Query-string token accepted in `v0.7.8` through `v0.8.3` (`internal/handlers/middleware.go`):**\nThe `v0.8.3` authentication middleware accepted credentials from the URL query string:\n\n```\n// internal/handlers/middleware.go — v0.8.3\nauth := r.Header.Get(\"Authorization\")\nqToken := r.URL.Query().Get(\"token\")\n\nif auth == \"\" && qToken == \"\" {\n web.ErrorCode(w, 401, \"missing_token\", \"unauthorized\", false, nil)\n return\n}\n\nprovided := strings.TrimPrefix(auth, \"Bearer \")\nif provided == auth {\n if qToken != \"\" {\n provided = qToken\n } else {\n provided = auth\n }\n}\n\nif subtle.ConstantTimeCompare([]byte(provided), []byte(cfg.Token)) != 1 {\n web.ErrorCode(w, 401, \"bad_token\", \"unauthorized\", false, nil)\n return\n}\n```\n\nThis means any client sending `GET /health?token=` in `v0.8.3` would authenticate successfully without using the `Authorization` header. I verified the same query-token auth pattern is present in the historical tag range starting at `v0.7.8`, and it is removed in `v0.8.4`.\n\n**Issue 2 — First-party setup and dashboard flows in `v0.8.3` generated and consumed `?token=` URLs:**\nThe `v0.8.3` setup flow generated dashboard URLs containing the token in the query string:\n\n```\n// cmd/pinchtab/cmd_wizard.go — v0.8.3\nfunc dashboardURL(cfg *config.FileConfig, path string) string {\n host := orDefault(cfg.Server.Bind, \"127.0.0.1\")\n port := orDefault(cfg.Server.Port, \"9867\")\n url := fmt.Sprintf(\"http://%s:%s%s\", host, port, path)\n if cfg.Server.Token != \"\" {\n url += \"?token=\" + cfg.Server.Token\n }\n return url\n}\n```\n\nThe `v0.8.3` dashboard frontend also supported one-click login from that same query-string token:\n\n```\n// dashboard/src/App.tsx — v0.8.3\nconst params = new URLSearchParams(window.location.search);\nconst urlToken = params.get(\"token\");\nif (urlToken) {\n setStoredAuthToken(urlToken);\n clean.searchParams.delete(\"token\");\n window.history.replaceState({}, \"\", clean.pathname + clean.hash);\n window.location.reload();\n}\n```\n\nThat combination materially increased the chance that users would open, copy, paste, bookmark, or log URLs containing live credentials before the token was scrubbed from the visible address bar.\n\n**Issue 3 — Exposure depends on surrounding systems recording the URL:**\nPinchTab's own request logger records `r.URL.Path`, not the full raw query string, so the leak is not primarily through PinchTab's structured application log. The risk comes from surrounding systems or client tooling that record the full request URI, such as:\n\n1. reverse proxies and load balancers\n2. browser history or bookmarks\n3. shell history containing full `curl` commands\n4. clipboard or terminal history when the wizard prints and copies a tokenized URL\n5. tracing or monitoring systems that capture full request URLs\n\n### PoC\n**Step 1 — Confirm auth is required**\n\n```bash\ncurl -i http://localhost:9867/health\n```\n\nExpected in token-protected affected deployments:\n\n```http\nHTTP/1.1 401 Unauthorized\n```\n\n**Step 2 — Authenticate using the vulnerable query-parameter pattern**\n\n```bash\ncurl -i \"http://localhost:9867/health?token=supersecrettoken\"\n```\n\nExpected:\n\n```http\nHTTP/1.1 200 OK\n```\n\nThis demonstrates that the token is accepted from the URL.\n\n**Step 3 — Observe the exposure vector**\nIf the request traverses a system that records the full URI, the token may appear in logs or local history, for example:\n\n```text\nGET /health?token=supersecrettoken HTTP/1.1\n```\n\nIn `v0.8.3`, a first-party reproduction path also exists without any external proxy: run the setup wizard, copy the printed dashboard URL containing `?token=...`, and note that the live credential is now present in clipboard history and any place that URL is pasted.\n\n### Impact\n1. Exposure of a valid API token through unsafe URL-based transport when a client uses the `?token=` authentication form.\n2. Lower barrier for credential compromise where reverse proxies, browser history, shell history, clipboard history, or tracing systems retain full request URIs.\n3. The `v0.8.3` wizard/dashboard flow increased the practical likelihood of this exposure by generating and consuming tokenized URLs as a first-party login pattern.\n4. Practical risk depends on actual use of the query-token pattern; deployments that use only `Authorization: Bearer ` are not affected by this issue in practice.\n5. This is not a direct authentication bypass. An attacker still needs access to a secondary source that captured the URL containing the token.\n\n### Suggested Remediation\n1. Reject query-string token authentication and accept credentials only through the `Authorization` header or controlled session mechanisms.\n2. Avoid generating user-facing URLs that contain live credentials.\n3. Document header-based auth as the only supported non-browser API authentication pattern.\n4. Recommend token rotation for users who may previously have used query-parameter authentication.\n\n**Screenshot Capture**\n\"ภาพถ่ายหน้าจอ", "title": "osv - https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/Go%2FGHSA-mrqc-3276-74f8.json?alt=media" }, { "category": "description", "text": "PinchTab: API Bearer Token Exposed in URL Query Parameter via Server Logs and Intermediary Systems in github.com/pinchtab/pinchtab", "title": "osv - https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/Go%2FGO-2026-4822.json?alt=media" }, { "category": "description", "text": "PinchTab is a standalone HTTP server that gives AI agents direct control over a Chrome browser. PinchTab `v0.7.8` through `v0.8.3` accepted the API token from a `token` URL query parameter in addition to the `Authorization` header. When a valid API credential is sent in the URL, it can be exposed through request URIs recorded by intermediaries or client-side tooling, such as reverse proxy access logs, browser history, shell history, clipboard history, and tracing systems that capture full URLs. This issue is an unsafe credential transport pattern rather than a direct authentication bypass. It only affects deployments where a token is configured and a client actually uses the query-parameter form. PinchTab's security guidance already recommended `Authorization: Bearer `, but `v0.8.3` still accepted `?token=` and included first-party flows that generated and consumed URLs containing the token. This was addressed in v0.8.4 by removing query-string token authentication and requiring safer header- or session-based authentication flows.", "title": "nvd - https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-33620" }, { "category": "description", "text": "PinchTab is a standalone HTTP server that gives AI agents direct control over a Chrome browser. PinchTab `v0.7.8` through `v0.8.3` accepted the API token from a `token` URL query parameter in addition to the `Authorization` header. When a valid API credential is sent in the URL, it can be exposed through request URIs recorded by intermediaries or client-side tooling, such as reverse proxy access logs, browser history, shell history, clipboard history, and tracing systems that capture full URLs. This issue is an unsafe credential transport pattern rather than a direct authentication bypass. It only affects deployments where a token is configured and a client actually uses the query-parameter form. PinchTab's security guidance already recommended `Authorization: Bearer `, but `v0.8.3` still accepted `?token=` and included first-party flows that generated and consumed URLs containing the token. This was addressed in v0.8.4 by removing query-string token authentication and requiring safer header- or session-based authentication flows.", "title": "cveprojectv5 - https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/33xxx/CVE-2026-33620.json" }, { "category": "other", "text": "0.00042", "title": "EPSS" }, { "category": "other", "text": "3.8", "title": "NCSC Score" }, { "category": "other", "text": "There is exploit data available from source Nvd, Exploit code publicly available", "title": "NCSC Score top decreasing factors" } ], "product_status": { "known_affected": [ "CSAFPID-5907192" ] }, "references": [ { "category": "external", "summary": "Source - github", "url": "https://api.github.com/advisories/GHSA-mrqc-3276-74f8" }, { "category": "external", "summary": "Source - osv", "url": "https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/Go%2FGHSA-mrqc-3276-74f8.json?alt=media" }, { "category": "external", "summary": "Source - nvd", "url": "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-33620" }, { "category": "external", "summary": "Source - cveprojectv5", "url": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/33xxx/CVE-2026-33620.json" }, { "category": "external", "summary": "Source - osv", "url": "https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/Go%2FGO-2026-4822.json?alt=media" }, { "category": "external", "summary": "Source - first", "url": "https://api.first.org/data/v1/epss?limit=10000&offset=0" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv", "url": "https://github.com/pinchtab/pinchtab/security/advisories/GHSA-mrqc-3276-74f8" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv", "url": "https://github.com/pinchtab/pinchtab/releases/tag/v0.8.4" }, { "category": "external", "summary": "Reference - github", "url": "https://github.com/advisories/GHSA-mrqc-3276-74f8" }, { "category": "external", "summary": "Reference - github", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33620" } ], "scores": [ { "cvss_v3": { "version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N", "baseScore": 4.3, "baseSeverity": "MEDIUM" }, "products": [ "CSAFPID-5907192" ] } ], "title": "CVE-2026-33620" } ] }