Vulnerabilities in pkg:pypi/local-deep-research

PACKAGE
Advisory Identifier: GHSA-g23j-2vwm-5c25
Advisory Summary

CVE-2026-46526 is a MODERATE (CVSS 5.0) local-deep-research has an ssrf bypass vulnerability (CWE-918: Server-Side Request Forgery (SSRF)) affecting Local deep research libraries in the PyPI ecosystem. The issue involves local-deep-research has an ssrf bypass in `safe_get`. Remediation is available by upgrading affected packages to version 1.6.10.

3 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:pypi/local-deep-research

3 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:pypi/local-deep-research. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-g23j-2vwm-5c25 CVE-2026-46526 MODERATE local-deep-research has an SSRF bypass in `safe_get`
GHSA-fj2m-qvh9-jq4q CVE-2026-43979 MODERATE local-deep-research is Vulnerable to HTML Injection via Unescaped User Input in PDF Export (`pdf_service.py:_markdown_to_html`)
GHSA-9c54-gxh7-ppjc CVE-2025-67743 MODERATE Local Deep Research is Vulnerable to Server-Side Request Forgery (SSRF) in Download Service

CVE-2026-46526 at a Glance

CVE Identifier CVE-2026-46526
GHSA Identifier GHSA-g23j-2vwm-5c25
Severity MODERATE
CVSS v3.1 Base Score 5.0
CWE Classification CWE-918: Server-Side Request Forgery (SSRF)
Affected Product Local deep research
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 5.0

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality Low (C:L)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2026-46526

To remediate this vulnerability, upgrade all affected Local deep research dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

local-deep-research fixed: 1.6.10
pip install local-deep-research>=1.6.10
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show local-deep-research

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-46526, inspect your installed packages using pip:

pip show local-deep-research

Analyze the terminal output to locate any version of Local deep research in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.6.10), your application is affected.

Note: The pip show local-deep-research command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-918: Server-Side Request Forgery (SSRF), where 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. In Local deep research, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary The URL checking logic in local-deep-research has a logical flaw that could be bypassed by attackers, leading to SSRF attacks. ### Details The current project uses `validate_url` to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks. <img width="1173" height="1107" alt="QQ20260430-212334-30-1" src="https://github.com/user-attachments/assets/52b356aa-9ad3-4b1d-a472-39a2ada3ea23" /> However, there are indeed differences in parsing between urlparse and the library that actually sends the request. For example, in `safe_get`, `validate_url` is first used to perform an SSRF check, and then `requests.get` is used to send the actual request. <img width="1164" height="1089" alt="QQ20260430-212431-30-2" src="https://github.com/user-attachments/assets/f3decb16-4daa-49e0-861c-273a913487a0" /> The core issue: urlparse() and requests disagree on which host a URL like `http://127.0.0.1:6666\@1.1.1.1` points to: - urlparse() treats \ as a regular character and @ as the userinfo-host delimiter, so it extracts hostname as `1.1.1.1` (public) - requests treats \ as a path character, connecting to `127.0.0.1` (internal) Below is a test code I wrote following the code. ``` #!/usr/bin/env python3 """Standalone demo: import project via absolute path and call safe_get.""" from __future__ import annotations import importlib.util import enum import sys import types from pathlib import Path # Hardcoded absolute path to the project's "src" directory. SRC_ROOT = Path( r"d:\BaiduNetdiskDownload\local-deep-research-main\local-deep-research-main\src" ) # Python 3.10 compatibility: # project constants import StrEnum (available in Python 3.11+). if not hasattr(enum, "StrEnum"): class _CompatStrEnum(str, enum.Enum): pass enum.StrEnum = _CompatStrEnum # type: ignore[attr-defined] def _load_safe_get(): """Load safe_get directly from file, bypassing package __init__ imports.""" ldr_pkg_name = "local_deep_research" security_pkg_name = "local_deep_research.security" # Build lightweight package modules so relative imports in safe_requests.py # resolve without executing package __init__.py files. if ldr_pkg_name not in sys.modules: ldr_pkg = types.ModuleType(ldr_pkg_name) ldr_pkg.__path__ = [str(SRC_ROOT / "local_deep_research")] # type: ignore[attr-defined] sys.modules[ldr_pkg_name] = ldr_pkg if security_pkg_name not in sys.modules: security_pkg = types.ModuleType(security_pkg_name) security_pkg.__path__ = [str(SRC_ROOT / "local_deep_research" / "security")] # type: ignore[attr-defined] sys.modules[security_pkg_name] = security_pkg module_name = "local_deep_research.security.safe_requests" module_path = SRC_ROOT / "local_deep_research" / "security" / "safe_requests.py" spec = importlib.util.spec_from_file_location(module_name, module_path) if spec is None or spec.loader is None: raise ImportError(f"Cannot load module from {module_path}") module = importlib.util.module_from_spec(spec) sys.modules[module_name] = module spec.loader.exec_module(module) return module.safe_get safe_get = _load_safe_get() def main() -> None: # Hardcoded URL for demonstration. url = "http://127.0.0.1:6666" # url = "http://127.0.0.1:6666\@1.1.1.1" safe_get(url, timeout=15) if __name__ == "__main__": main() ``` When an attacker uses `http://127.0.0.1:6666/`, the existing detection logic can detect that this is an internal network address and block it. <img width="1694" height="503" alt="QQ20260430-212723-30-3" src="https://github.com/user-attachments/assets/366f684d-9191-4acb-b6a2-b2c3c54f0223" /> However, when an attacker uses `http://127.0.0.1:6666\@1.1.1.1`, the detection logic resolves the host to `1.1.1.1`, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to `http://127.0.0.1:6666`, bypassing the detection and achieving an SSRF attack. <img width="2424" height="477" alt="QQ20260430-212833-30-4" src="https://github.com/user-attachments/assets/bd175e34-d833-44c5-981b-59cfad3406c3" /> ### PoC ``` http://127.0.0.1:6666\@1.1.1.1 ``` ### Impact SSRF --- ## Maintainer note (2026-05-15) Thanks @Fushuling and @RacerZ-fighting for the detailed report. The remediation spans four PRs, all merged to `main` and shipped in **v1.6.10**: **#3873** (merged 2026-05-08) — the load-bearing fix for the parser-differential bypass: - New `RFC_FORBIDDEN_URL_CHARS_RE` in `security/ssrf_validator.py` rejects URLs containing backslash, ASCII control bytes, or whitespace — RFC 3986 forbids these and their presence signals a parser-differential attempt. - Host extraction switched from `urllib.parse.urlparse(url).hostname` to `urllib3.util.parse_url(url).host`. `urllib3` is the parser `requests` uses internally, so the validator and the HTTP client now agree on the destination by construction — closing the `\@` divergence that drove the PoC. - Same two-layer defence applied to `NotificationURLValidator.validate_service_url`. - 53 new tests across `test_ssrf_validator.py`, `test_notification_validator.py`, `test_safe_requests.py`, and `test_ssrf_redirect_bypass.py`, including the advisory PoC `http://127.0.0.1:6666\@1.1.1.1` and the post-prepare canonical form `http://127.0.0.1:6666/%5C@1.1.1.1`. **#3882** (merged 2026-05-08) — hardens the metadata-IP block and redacts userinfo from log output so rejected URLs don't leak credentials to logs. **#3889** (merged 2026-05-09) — locks in real-world URL fixtures and behavior invariants from #3873/#3882 as regression tests. **#3932** (merged 2026-05-10) — blocks IPv6 transition prefixes (`2002::/16` 6to4, `64:ff9b::/96` NAT64, `2001::/32` Teredo, `100::/64` discard) so private IPv4 destinations cannot be reached via an IPv6-wrapped form. NAT64 has an operator opt-in (`LDR_SECURITY_ALLOW_NAT64=true`) for IPv6-only deployments, but cloud metadata IPs remain blocked regardless. ### Affected versions - **The specific parser-differential bypass** described above exists from **v1.3.0** (when `validate_url` was first introduced) through **v1.6.9**. The validator used `urlparse(url).hostname` for that entire span. - **Versions before v1.3.0** had no SSRF validator at all — requests went directly to `requests.get()` without any host check. Those versions are vulnerable to SSRF via this URL and any other internal address; the parser-differential trick is unnecessary. In both cases the remediation is the same: **upgrade to v1.6.10 or later.**

CVE-2026-46526 Affected Local deep research Versions

1 component(s)
Fixed Versions:
1.6.10
Product / Package Ecosystem Affected Versions Fixed Version
local-deep-research
PyPI
< 1.6.10
1.6.10

References

Frequently Asked Questions

What is CVE-2026-46526?
CVE-2026-46526 is a security vulnerability in Local deep research involving local-deep-research has an SSRF bypass in `safe_get` under CWE-918: Server-Side Request Forgery (SSRF).
Which Local deep research versions are affected?
Affected versions include releases prior to 1.6.10 across affected packages: local-deep-research.
What version fixes CVE-2026-46526?
Upgrading to 1.6.10 (or the latest patched release for your respective branch) resolves the vulnerability.
Is local-deep-research affected?
Yes, local-deep-research is affected in releases prior to 1.6.10. Upgrade your dependency to 1.6.10 or later.
What is the CVSS score of CVE-2026-46526?
CVE-2026-46526 has a CVSS v3.1 base score of 5.0 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N.
What CWE is associated with CVE-2026-46526?
CVE-2026-46526 is classified under CWE-918: Server-Side Request Forgery (SSRF) (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.).
How can I check PyPI dependencies for CVE-2026-46526?
Run the dependency tree command: 'pip show local-deep-research'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-g23j-2vwm-5c25",
  "modified" : "2026-06-09T10:23:33Z",
  "published" : "2026-05-28T19:18:34Z",
  "aliases" : [ "CVE-2026-46526" ],
  "summary" : "local-deep-research has an SSRF bypass in `safe_get`",
  "details" : "### Summary\nThe URL checking logic in local-deep-research has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.\n\n### Details\nThe current project uses `validate_url` to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks.\n\n<img width=\"1173\" height=\"1107\" alt=\"QQ20260430-212334-30-1\" src=\"https://github.com/user-attachments/assets/52b356aa-9ad3-4b1d-a472-39a2ada3ea23\" />\n\nHowever, there are indeed differences in parsing between urlparse and the library that actually sends the request. For example, in `safe_get`, `validate_url` is first used to perform an SSRF check, and then `requests.get` is used to send the actual request.\n\n<img width=\"1164\" height=\"1089\" alt=\"QQ20260430-212431-30-2\" src=\"https://github.com/user-attachments/assets/f3decb16-4daa-49e0-861c-273a913487a0\" />\n\nThe core issue: urlparse() and requests disagree on which host a URL like `http://127.0.0.1:6666\\@1.1.1.1` points to:\n\n- urlparse() treats \\ as a regular character and @ as the userinfo-host delimiter, so it extracts hostname as `1.1.1.1` (public)\n- requests treats \\ as a path character, connecting to `127.0.0.1` (internal)\n\nBelow is a test code I wrote following the code.\n```\n#!/usr/bin/env python3\n\"\"\"Standalone demo: import project via absolute path and call safe_get.\"\"\"\n\nfrom __future__ import annotations\n\nimport importlib.util\nimport enum\nimport sys\nimport types\nfrom pathlib import Path\n\n# Hardcoded absolute path to the project's \"src\" directory.\nSRC_ROOT = Path(\n    r\"d:\\BaiduNetdiskDownload\\local-deep-research-main\\local-deep-research-main\\src\"\n)\n\n# Python 3.10 compatibility:\n# project constants import StrEnum (available in Python 3.11+).\nif not hasattr(enum, \"StrEnum\"):\n    class _CompatStrEnum(str, enum.Enum):\n        pass\n\n    enum.StrEnum = _CompatStrEnum  # type: ignore[attr-defined]\n\n\ndef _load_safe_get():\n    \"\"\"Load safe_get directly from file, bypassing package __init__ imports.\"\"\"\n    ldr_pkg_name = \"local_deep_research\"\n    security_pkg_name = \"local_deep_research.security\"\n\n    # Build lightweight package modules so relative imports in safe_requests.py\n    # resolve without executing package __init__.py files.\n    if ldr_pkg_name not in sys.modules:\n        ldr_pkg = types.ModuleType(ldr_pkg_name)\n        ldr_pkg.__path__ = [str(SRC_ROOT / \"local_deep_research\")]  # type: ignore[attr-defined]\n        sys.modules[ldr_pkg_name] = ldr_pkg\n\n    if security_pkg_name not in sys.modules:\n        security_pkg = types.ModuleType(security_pkg_name)\n        security_pkg.__path__ = [str(SRC_ROOT / \"local_deep_research\" / \"security\")]  # type: ignore[attr-defined]\n        sys.modules[security_pkg_name] = security_pkg\n\n    module_name = \"local_deep_research.security.safe_requests\"\n    module_path = SRC_ROOT / \"local_deep_research\" / \"security\" / \"safe_requests.py\"\n\n    spec = importlib.util.spec_from_file_location(module_name, module_path)\n    if spec is None or spec.loader is None:\n        raise ImportError(f\"Cannot load module from {module_path}\")\n\n    module = importlib.util.module_from_spec(spec)\n    sys.modules[module_name] = module\n    spec.loader.exec_module(module)\n    return module.safe_get\n\n\nsafe_get = _load_safe_get()\n\n\ndef main() -> None:\n    # Hardcoded URL for demonstration.\n    url = \"http://127.0.0.1:6666\"\n    # url = \"http://127.0.0.1:6666\\@1.1.1.1\"\n\n    safe_get(url, timeout=15)\n\n\nif __name__ == \"__main__\":\n    main()\n```\nWhen an attacker uses `http://127.0.0.1:6666/`, the existing detection logic can detect that this is an internal network address and block it.\n\n<img width=\"1694\" height=\"503\" alt=\"QQ20260430-212723-30-3\" src=\"https://github.com/user-attachments/assets/366f684d-9191-4acb-b6a2-b2c3c54f0223\" />\n\nHowever, when an attacker uses `http://127.0.0.1:6666\\@1.1.1.1`, the detection logic resolves the host to `1.1.1.1`, which is a public IP address, thus passing the verification. But in the actual request process, this URL is forwarded by requests.get to `http://127.0.0.1:6666`, bypassing the detection and achieving an SSRF attack.\n\n<img width=\"2424\" height=\"477\" alt=\"QQ20260430-212833-30-4\" src=\"https://github.com/user-attachments/assets/bd175e34-d833-44c5-981b-59cfad3406c3\" />\n\n### PoC\n```\nhttp://127.0.0.1:6666\\@1.1.1.1\n```\n\n### Impact\nSSRF\n\n\n\n---\n\n## Maintainer note (2026-05-15)\n\nThanks @Fushuling and @RacerZ-fighting for the detailed report. The remediation\nspans four PRs, all merged to `main` and shipped in **v1.6.10**:\n\n**#3873** (merged 2026-05-08) — the load-bearing fix for the parser-differential\nbypass:\n- New `RFC_FORBIDDEN_URL_CHARS_RE` in `security/ssrf_validator.py` rejects\n  URLs containing backslash, ASCII control bytes, or whitespace — RFC 3986\n  forbids these and their presence signals a parser-differential attempt.\n- Host extraction switched from `urllib.parse.urlparse(url).hostname` to\n  `urllib3.util.parse_url(url).host`. `urllib3` is the parser `requests`\n  uses internally, so the validator and the HTTP client now agree on the\n  destination by construction — closing the `\\@` divergence that drove the\n  PoC.\n- Same two-layer defence applied to `NotificationURLValidator.validate_service_url`.\n- 53 new tests across `test_ssrf_validator.py`, `test_notification_validator.py`,\n  `test_safe_requests.py`, and `test_ssrf_redirect_bypass.py`, including the\n  advisory PoC `http://127.0.0.1:6666\\@1.1.1.1` and the post-prepare canonical\n  form `http://127.0.0.1:6666/%5C@1.1.1.1`.\n\n**#3882** (merged 2026-05-08) — hardens the metadata-IP block and redacts\nuserinfo from log output so rejected URLs don't leak credentials to logs.\n\n**#3889** (merged 2026-05-09) — locks in real-world URL fixtures and behavior\ninvariants from #3873/#3882 as regression tests.\n\n**#3932** (merged 2026-05-10) — blocks IPv6 transition prefixes (`2002::/16`\n6to4, `64:ff9b::/96` NAT64, `2001::/32` Teredo, `100::/64` discard) so private\nIPv4 destinations cannot be reached via an IPv6-wrapped form. NAT64 has an\noperator opt-in (`LDR_SECURITY_ALLOW_NAT64=true`) for IPv6-only deployments,\nbut cloud metadata IPs remain blocked regardless.\n\n### Affected versions\n\n- **The specific parser-differential bypass** described above exists from\n  **v1.3.0** (when `validate_url` was first introduced) through **v1.6.9**.\n  The validator used `urlparse(url).hostname` for that entire span.\n- **Versions before v1.3.0** had no SSRF validator at all — requests went\n  directly to `requests.get()` without any host check. Those versions are\n  vulnerable to SSRF via this URL and any other internal address; the\n  parser-differential trick is unnecessary.\n\nIn both cases the remediation is the same: **upgrade to v1.6.10 or later.**",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "local-deep-research"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.6.10"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/LearningCircuit/local-deep-research/security/advisories/GHSA-g23j-2vwm-5c25"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-46526"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/LearningCircuit/local-deep-research/pull/3873"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/LearningCircuit/local-deep-research/pull/3882"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/LearningCircuit/local-deep-research/pull/3889"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/LearningCircuit/local-deep-research/pull/3932"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/LearningCircuit/local-deep-research"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/LearningCircuit/local-deep-research/releases/tag/v1.6.10"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-918" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-28T19:18:34Z",
    "nvd_published_at" : "2026-05-28T19:16:39Z"
  }
}