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.
Affected: PyPI: local-deep-research
### 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 Pa…
Affected: PyPI: local-deep-research
### 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 Pa…