CVE-2026-33619 (GCVE-0-2026-33619)

Vulnerability from cvelistv5 – Published: 2026-03-26 20:34 – Updated: 2026-03-30 11:34
VLAI?
Title
PinchTab has Unauthenticated Blind SSRF in Task Scheduler via Unvalidated callbackUrl
Summary
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.
Severity ?
4.1 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:N
CWE
  • CWE-918 - Server-Side Request Forgery (SSRF)
Assigner
References
Impacted products
Vendor Product Version
pinchtab pinchtab Affected: < 0.8.4
Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-33619",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-30T11:34:33.142945Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-03-30T11:34:43.286Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "pinchtab",
          "vendor": "pinchtab",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.8.4"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027s 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\u0027s master API token. In PinchTab\u0027s 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\u0027s 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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.1,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "HIGH",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-918",
              "description": "CWE-918: Server-Side Request Forgery (SSRF)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-26T20:34:01.661Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/pinchtab/pinchtab/security/advisories/GHSA-xqq2-4j46-vwp7",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/pinchtab/pinchtab/security/advisories/GHSA-xqq2-4j46-vwp7"
        },
        {
          "name": "https://github.com/pinchtab/pinchtab/commit/c824574c3a05073dec2f5e9c219e22ffff8de445",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/pinchtab/pinchtab/commit/c824574c3a05073dec2f5e9c219e22ffff8de445"
        },
        {
          "name": "https://github.com/pinchtab/pinchtab/releases/tag/v0.8.4",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/pinchtab/pinchtab/releases/tag/v0.8.4"
        }
      ],
      "source": {
        "advisory": "GHSA-xqq2-4j46-vwp7",
        "discovery": "UNKNOWN"
      },
      "title": "PinchTab has Unauthenticated Blind SSRF in Task Scheduler via Unvalidated callbackUrl"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-33619",
    "datePublished": "2026-03-26T20:34:01.661Z",
    "dateReserved": "2026-03-23T14:24:11.616Z",
    "dateUpdated": "2026-03-30T11:34:43.286Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-33619\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2026-03-26T21:17:06.220\",\"lastModified\":\"2026-03-30T13:26:50.827\",\"vulnStatus\":\"Undergoing Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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\u0027s 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\u0027s master API token. In PinchTab\u0027s 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\u0027s 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.\"},{\"lang\":\"es\",\"value\":\"PinchTab es un servidor HTTP aut\u00f3nomo que otorga a los agentes de IA control directo sobre un navegador Chrome. PinchTab v0.8.3 contiene un problema de falsificaci\u00f3n de petici\u00f3n del lado del servidor en la ruta de entrega de webhook del programador opcional. Cuando se env\u00eda una tarea a \u0027POST /tasks\u0027 con una \u0027callbackUrl\u0027 controlada por el usuario, el programador v0.8.3 env\u00eda un \u0027POST\u0027 HTTP saliente a esa URL cuando la tarea alcanza un estado terminal. En esa versi\u00f3n, la ruta del webhook validaba solo el esquema de la URL y no rechazaba destinos de bucle invertido, privados, de enlace local u otros no p\u00fablicos. Debido a que la implementaci\u00f3n v0.8.3 tambi\u00e9n utilizaba el comportamiento predeterminado del cliente HTTP, se segu\u00edan las redirecciones y el destino no estaba fijado a IPs validadas. Esto permit\u00eda SSRF ciego desde el servidor PinchTab a objetivos HTTP(S) elegidos por el atacante accesibles desde el servidor. Este problema es m\u00e1s limitado que un SSRF general no autenticado y expuesto a internet. El programador es opcional y est\u00e1 desactivado por defecto, y en implementaciones protegidas por token el atacante ya debe ser capaz de enviar tareas utilizando el token maestro de la API del servidor. En el modelo de implementaci\u00f3n previsto de PinchTab, ese token representa control administrativo en lugar de un rol de bajo privilegio. Las implementaciones sin token reducen a\u00fan m\u00e1s la barrera, pero eso es un estado de configuraci\u00f3n inseguro separado en lugar del impacto creado por el propio error del webhook. El modelo de implementaci\u00f3n predeterminado de PinchTab es local-first y controlado por el usuario, con enlace de bucle invertido y acceso basado en token en la configuraci\u00f3n recomendada. Eso reduce el riesgo pr\u00e1ctico en el uso predeterminado, aunque no elimina el problema subyacente del webhook cuando el programador est\u00e1 habilitado y es accesible. Esto se abord\u00f3 en la v0.8.4 validando los objetivos de callback antes del env\u00edo, rechazando rangos de IP no p\u00fablicos, fijando la entrega a IPs validadas, deshabilitando el seguimiento de redirecciones y validando \u0027callbackUrl\u0027 durante el env\u00edo de tareas.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"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\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"HIGH\",\"userInteraction\":\"NONE\",\"scope\":\"CHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"LOW\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":2.3,\"impactScore\":1.4}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-918\"}]}],\"references\":[{\"url\":\"https://github.com/pinchtab/pinchtab/commit/c824574c3a05073dec2f5e9c219e22ffff8de445\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/pinchtab/pinchtab/releases/tag/v0.8.4\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/pinchtab/pinchtab/security/advisories/GHSA-xqq2-4j46-vwp7\",\"source\":\"security-advisories@github.com\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-33619\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"poc\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-03-30T11:34:33.142945Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-03-30T11:34:39.355Z\"}}], \"cna\": {\"title\": \"PinchTab has Unauthenticated Blind SSRF in Task Scheduler via Unvalidated callbackUrl\", \"source\": {\"advisory\": \"GHSA-xqq2-4j46-vwp7\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV3_1\": {\"scope\": \"CHANGED\", \"version\": \"3.1\", \"baseScore\": 4.1, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:N\", \"integrityImpact\": \"LOW\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"NONE\", \"privilegesRequired\": \"HIGH\", \"confidentialityImpact\": \"NONE\"}}], \"affected\": [{\"vendor\": \"pinchtab\", \"product\": \"pinchtab\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 0.8.4\"}]}], \"references\": [{\"url\": \"https://github.com/pinchtab/pinchtab/security/advisories/GHSA-xqq2-4j46-vwp7\", \"name\": \"https://github.com/pinchtab/pinchtab/security/advisories/GHSA-xqq2-4j46-vwp7\", \"tags\": [\"x_refsource_CONFIRM\"]}, {\"url\": \"https://github.com/pinchtab/pinchtab/commit/c824574c3a05073dec2f5e9c219e22ffff8de445\", \"name\": \"https://github.com/pinchtab/pinchtab/commit/c824574c3a05073dec2f5e9c219e22ffff8de445\", \"tags\": [\"x_refsource_MISC\"]}, {\"url\": \"https://github.com/pinchtab/pinchtab/releases/tag/v0.8.4\", \"name\": \"https://github.com/pinchtab/pinchtab/releases/tag/v0.8.4\", \"tags\": [\"x_refsource_MISC\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"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\u0027s 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\u0027s master API token. In PinchTab\u0027s 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\u0027s 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.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-918\", \"description\": \"CWE-918: Server-Side Request Forgery (SSRF)\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2026-03-26T20:34:01.661Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-33619\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-03-30T11:34:43.286Z\", \"dateReserved\": \"2026-03-23T14:24:11.616Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2026-03-26T20:34:01.661Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.