CVE-2026-46526
Received Received - Intake
Server-Side Request Forgery in Local Deep Research

Publication date: 2026-05-28

Last updated on: 2026-05-28

Assigner: GitHub, Inc.

Description
Local Deep Research is an AI-powered research assistant for deep, iterative research. Prior to 1.6.10, the URL checking logic in local-deep-research has a logical flaw that could be bypassed by attackers, leading to SSRF attacks. 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. 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. This vulnerability is fixed in 1.6.10.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-05-28
Generated
2026-05-29
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
local_deep_research local_deep_research to 1.6.10 (exc)
learningcircuit local_deep_research 1.6.10
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-918 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.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-46526 is a Server-Side Request Forgery (SSRF) vulnerability in the Local Deep Research project prior to version 1.6.10. The issue arises from a logical flaw in the URL validation logic where differences in URL parsing between Python's urlparse and the requests library allow attackers to bypass SSRF protections.

For example, an attacker can craft a URL like 'http://127.0.0.1:6666\@1.1.1.1'. The urlparse function interprets the hostname as '1.1.1.1' (a public IP), passing the SSRF check, but the requests library actually connects to '127.0.0.1:6666' (an internal address), enabling unauthorized internal network access.

The vulnerability was fixed in version 1.6.10 by aligning URL parsing between the validator and the HTTP client, rejecting URLs with backslashes, whitespace, or control characters, blocking IPv6 unspecified addresses and cloud metadata IPs, and redacting sensitive information from logs.


How can this vulnerability impact me? :

This vulnerability allows an attacker to perform SSRF attacks by bypassing URL validation checks, potentially enabling them to make unauthorized requests to internal or protected network resources.

Such SSRF attacks can lead to exposure of internal services, unauthorized access to sensitive data, or interaction with cloud metadata endpoints that may reveal credentials or configuration details.

The CVSS score of 5.0 indicates a moderate severity, requiring network access and low complexity, with no special privileges or user interaction needed.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

Detection of this SSRF vulnerability involves identifying attempts to exploit discrepancies in URL parsing, such as URLs containing backslashes, whitespace, or control characters that bypass SSRF validation.

Specifically, crafted URLs like `http://127.0.0.1:6666\@1.1.1.1` or `http://127.0.0.1\@1.1.1.1` are indicators of exploitation attempts, where the attacker tries to bypass URL validation by exploiting differences between `urlparse` and the HTTP client's URL parsing.

To detect such attempts on your system or network, you can monitor logs for URLs containing suspicious characters such as backslashes (`\`), whitespace, or control characters in HTTP requests or application logs.

Commands to help detect these attempts might include searching application logs or network captures for these patterns. For example, using grep on log files:

  • grep -P '\\' /path/to/application.log
  • grep -P '\s' /path/to/application.log
  • grep -P '[\x00-\x1F]' /path/to/application.log

Additionally, monitoring for requests targeting cloud metadata IP addresses or IPv6 unspecified addresses can help detect attempts to exploit the vulnerability.


What immediate steps should I take to mitigate this vulnerability?

The primary and immediate mitigation step is to upgrade the local-deep-research package to version 1.6.10 or later, where the vulnerability is fixed.

Version 1.6.10 includes multiple security hardenings such as:

  • Rejecting URLs containing backslashes, whitespace, or ASCII control characters to prevent malicious URL parsing.
  • Aligning URL parsing logic by replacing `urlparse` with `urllib3.util.parse_url` to ensure consistent host extraction.
  • Blocking IPv6 unspecified addresses and IPv6 transition prefixes that could tunnel to private IPv4 destinations.
  • Blocking cloud metadata IP addresses from AWS, Tencent, and AlibabaCloud to prevent SSRF attacks targeting these endpoints.
  • Redacting sensitive userinfo from URL logs to avoid credential leaks.

If upgrading immediately is not possible, consider implementing strict input validation to reject suspicious URLs and monitor logs for exploitation attempts as a temporary measure.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

CVE-2026-46526 is a Server-Side Request Forgery (SSRF) vulnerability that could allow attackers to bypass URL validation and access internal or sensitive resources. Such unauthorized access could potentially lead to exposure of sensitive data or internal systems.

The vulnerability involves risks related to confidentiality, as indicated by the CVSS score impact on confidentiality (C:L). This could have implications for compliance with standards like GDPR or HIPAA, which require protection of sensitive personal or health information.

The fix includes redacting sensitive user information from URL logs to prevent credential leakage, which helps mitigate risks related to data exposure and supports compliance with data protection regulations.

Overall, if exploited, this vulnerability could undermine security controls required by common standards and regulations by enabling unauthorized internal network access or data leakage, thus potentially impacting compliance.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart