GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
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.

5690 vulnerabilities reference this CWE, most recent first.

GHSA-VXG2-HHGR-37FX

Vulnerability from github – Published: 2026-04-03 06:31 – Updated: 2026-04-04 06:53
VLAI
Summary
Roundcube Webmail: Insufficient CSS sanitization in HTML e-mail messages
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.

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

{
  "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-07-20 21:25
VLAI
Summary
praisonaiagents: SSRF guard validates literal IPs only and never resolves DNS
Details

praisonaiagents: 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.39
  • pip/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

  1. Clone the target: git clone --depth 1 https://github.com/MervinPraison/PraisonAI
  2. Run the proof of concept shown above against the cloned source.
  3. 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.

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": [
    {
      "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": [
    "CVE-2026-57126"
  ],
  "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-07-20T21:25:26Z",
  "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:22
VLAI
Summary
Hugo: security.http.urls allow-list bypass via HTTP redirects
Details

Commit: 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.

Show details on source website
To clipboard 

{
  "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:30
VLAI
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.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
5.3 (Medium)
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
Show details on source website
To clipboard 

{
  "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:30
VLAI
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.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
2.1 (Low)
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
Show details on source website
To clipboard 

{
  "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-W229-45JG-VP35

Vulnerability from github – Published: 2026-08-10 09:31 – Updated: 2026-08-11 21:32
VLAI
Details

The LearnPress WordPress plugin before 4.4.4 does not validate a user-supplied URL before the server fetches it, allowing users with the instructor role to induce the server to issue requests to arbitrary external hosts, a blind and bounded server-side request forgery.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-12971"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-10T07:16:46Z",
    "severity": "LOW"
  },
  "details": "The LearnPress  WordPress plugin before 4.4.4 does not validate a user-supplied URL before the server fetches it, allowing users with the instructor role to induce the server to issue requests to arbitrary external hosts, a blind and bounded server-side request forgery.",
  "id": "GHSA-w229-45jg-vp35",
  "modified": "2026-08-11T21:32:29Z",
  "published": "2026-08-10T09:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12971"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/ef69bd9d-ec2a-4526-b2b9-51948fa76980"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W233-JW66-J356

Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2025-09-22 21:30
VLAI
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.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
2.1 (Low)
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
Show details on source website
To clipboard 

{
  "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:34
VLAI
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.

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

{
  "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:30
VLAI
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['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.

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

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

GHSA-W2RX-84HP-GG95

Vulnerability from github – Published: 2026-08-04 19:40 – Updated: 2026-08-04 19:40
VLAI
Summary
Open WebUI: SSRF into internal services via unvalidated sub-resource requests in the Playwright web loader
Details

Summary

With the Playwright web loader enabled, Open WebUI opens user-submitted URLs in a real browser and validates the destination address before allowing the request. That check only ran for the top-level page request. Every other request the page issued was passed through unvalidated, so a page could use its own JavaScript to reach addresses the validation exists to block. Because the loader returns the page's final DOM to the requesting user, anything the page read back from those addresses ends up in the web-search or RAG output.

Preconditions

  • WEB_LOADER_ENGINE=playwright. This is not the default; deployments on the default web loader are unaffected.
  • A reachable Playwright browser, either local or via PLAYWRIGHT_WS_URL.
  • Any authenticated user who can submit a URL for ingestion or trigger a web search. No administrator role is required.
  • Something worth reading on a network the browser can reach. A deployment whose browser container has no route to internal services loses nothing here.

Impact

An authenticated user can read HTTP responses from services reachable by the browser process: cloud instance metadata, other containers on the same network, and internal APIs bound to private addresses. The content is returned to the user through the normal web-search or document-ingestion result, so this is a read primitive, not a blind one. It confers no write access and no availability impact, and it does not extend beyond what the browser's network position already allows.

Fix

Fixed in 0.11.0 by commit bef63a2ae. Every intercepted request is now validated, fetched with redirects disabled, re-validated on each redirect hop and then fulfilled, so neither a sub-resource nor a redirect can land on a non-global address. The same change blocks the two paths that never reached the interceptor at all: service-worker requests, via service_workers="block", and WebSocket connections, via a route handler that never connects upstream. Upgrading to 0.11.0 fully resolves the issue; no configuration change is required.

Root cause

Affected component: SafePlaywrightURLLoader in backend/open_webui/retrieval/web/utils.py, in both the sync and async request interceptors. Affected setup: only builds running the Playwright loader engine.

The interceptor was written to guard navigation, and its first action was to return early for any request whose resource type was not document. The intent was that only the page the user asked for needs address validation, but a browser page is not a single request: once the validated document loads, its scripts issue further requests under the page's own control, and those never reached the validation. The address check was therefore applied to the one request the attacker did not need to control, and skipped on every request they did.

Proof of concept

Reported against 0.10.2 by driving the interceptor directly with stand-in route and request objects, one call per resource type, against http://169.254.169.254/latest/meta-data/. The document type is aborted; every other type is continued unvalidated. The browser and the network request were seeded rather than driven end to end; the code path exercised is the one the browser reaches for each sub-resource.

Credits

  • @edwardav970 — identified that address validation was applied only to the top-level document request, leaving every sub-resource type unvalidated.
Severity
7.7 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.6"
            },
            {
              "fixed": "0.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-70479"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-04T19:40:48Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\nWith the Playwright web loader enabled, Open WebUI opens user-submitted URLs in a real browser and validates the destination address before allowing the request. That check only ran for the top-level page request. Every other request the page issued was passed through unvalidated, so a page could use its own JavaScript to reach addresses the validation exists to block. Because the loader returns the page\u0027s final DOM to the requesting user, anything the page read back from those addresses ends up in the web-search or RAG output.\n\n## Preconditions\n- `WEB_LOADER_ENGINE=playwright`. This is not the default; deployments on the default web loader are unaffected.\n- A reachable Playwright browser, either local or via `PLAYWRIGHT_WS_URL`.\n- Any authenticated user who can submit a URL for ingestion or trigger a web search. No administrator role is required.\n- Something worth reading on a network the browser can reach. A deployment whose browser container has no route to internal services loses nothing here.\n\n## Impact\nAn authenticated user can read HTTP responses from services reachable by the browser process: cloud instance metadata, other containers on the same network, and internal APIs bound to private addresses. The content is returned to the user through the normal web-search or document-ingestion result, so this is a read primitive, not a blind one. It confers no write access and no availability impact, and it does not extend beyond what the browser\u0027s network position already allows.\n\n## Fix\nFixed in 0.11.0 by commit `bef63a2ae`. Every intercepted request is now validated, fetched with redirects disabled, re-validated on each redirect hop and then fulfilled, so neither a sub-resource nor a redirect can land on a non-global address. The same change blocks the two paths that never reached the interceptor at all: service-worker requests, via `service_workers=\"block\"`, and WebSocket connections, via a route handler that never connects upstream. Upgrading to 0.11.0 fully resolves the issue; no configuration change is required.\n\n## Root cause\nAffected component: `SafePlaywrightURLLoader` in `backend/open_webui/retrieval/web/utils.py`, in both the sync and async request interceptors. Affected setup: only builds running the Playwright loader engine.\n\nThe interceptor was written to guard navigation, and its first action was to return early for any request whose resource type was not `document`. The intent was that only the page the user asked for needs address validation, but a browser page is not a single request: once the validated document loads, its scripts issue further requests under the page\u0027s own control, and those never reached the validation. The address check was therefore applied to the one request the attacker did not need to control, and skipped on every request they did.\n\n## Proof of concept\nReported against 0.10.2 by driving the interceptor directly with stand-in route and request objects, one call per resource type, against `http://169.254.169.254/latest/meta-data/`. The `document` type is aborted; every other type is continued unvalidated. The browser and the network request were seeded rather than driven end to end; the code path exercised is the one the browser reaches for each sub-resource.\n\n## Credits\n- **@edwardav970** \u2014 identified that address validation was applied only to the top-level document request, leaving every sub-resource type unvalidated.",
  "id": "GHSA-w2rx-84hp-gg95",
  "modified": "2026-08-04T19:40:48Z",
  "published": "2026-08-04T19:40:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-w2rx-84hp-gg95"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/pull/27526"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/bef63a2ae915571d50d2722a635e8bfa753d7877"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: SSRF into internal services via unvalidated sub-resource requests in the Playwright web loader"
}

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