CVE-2026-33693
Received Received - Intake
SSRF Bypass in Lemmy activitypub-federation-rust via

Publication date: 2026-03-27

Last updated on: 2026-03-27

Assigner: GitHub, Inc.

Description
Lemmy is a link aggregator and forum for the fediverse. Prior to version 0.7.0-beta.9, the `v4_is_invalid()` function in `activitypub-federation-rust` (`src/utils.rs`) does not check for `Ipv4Addr::UNSPECIFIED` (0.0.0.0). An unauthenticated attacker controlling a remote domain can point it to 0.0.0.0, bypass the SSRF protection introduced by the fix for CVE-2025-25194 (GHSA-7723-35v7-qcxw), and reach localhost services on the target server. Version 0.7.0-beta.9 patches the issue.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-27
Last Modified
2026-03-27
Generated
2026-05-27
AI Q&A
2026-03-27
EPSS Evaluated
2026-05-25
NVD
Affected Vendors & Products
Showing 3 associated CPEs
Vendor Product Version / Range
lemmy activitypub_federation_rust to 0.7.0-beta.9 (exc)
lemmy activitypub_federation to 0.6.2 (inc)
lemmy activitypub-federation-rust to 0.7.0-beta.9 (exc)
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
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided information does not explicitly address how CVE-2026-33693 affects compliance with common standards and regulations such as GDPR or HIPAA.


Can you explain this vulnerability to me?

CVE-2026-33693 is a Server-Side Request Forgery (SSRF) vulnerability in the Rust library activitypub-federation-rust used by Lemmy, a link aggregator and forum for the fediverse.

The vulnerability arises because the function `v4_is_invalid()` in the source file `src/utils.rs` does not check for the unspecified IPv4 address 0.0.0.0 (`Ipv4Addr::UNSPECIFIED`). This omission allows an attacker controlling a remote domain to point its DNS record to 0.0.0.0, which routes TCP connections to localhost (127.0.0.1) on Linux, macOS, and Windows.

As a result, the SSRF protections intended to block requests to localhost and other restricted IPs can be bypassed, enabling the attacker to reach localhost services on the target server.

Additionally, there is a DNS rebinding Time-of-Check to Time-of-Use (TOCTOU) race condition where the IP address is validated during DNS resolution but resolved again during the actual HTTP request, allowing attackers to manipulate DNS responses to bypass validation.

The vulnerability was patched in version 0.7.0-beta.9 by adding checks for unspecified and broadcast IPv4 addresses in the validation function.


How can this vulnerability impact me? :

This vulnerability allows an unauthenticated attacker to bypass SSRF protections and access localhost services on the target server.

  • Attackers can reach internal services that are normally inaccessible from the outside, including cloud instance metadata services (e.g., 169.254.169.254).
  • It enables internal port scanning and potentially exploitation of vulnerable local services.
  • The DNS rebinding attack can further allow attackers to bypass IP validation by returning different IPs during validation and connection.

Overall, this can lead to unauthorized access to sensitive internal resources, data leakage, and increased attack surface on affected systems.


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

This vulnerability involves an attacker controlling a remote domain that resolves to the unspecified IPv4 address 0.0.0.0, which routes to localhost, bypassing SSRF protections. Detection involves monitoring DNS resolutions and network requests for domains resolving to 0.0.0.0 or suspicious IP addresses that should be blocked.

Suggested detection steps include:

  • Check DNS resolutions for domains resolving to 0.0.0.0 using commands like: `dig +short evil.com` or `nslookup evil.com`.
  • Monitor outgoing HTTP requests from your system or application to see if any requests are made to 0.0.0.0 or localhost IPs unexpectedly.
  • Use network monitoring tools (e.g., tcpdump, Wireshark) to capture traffic and filter for connections to 0.0.0.0 or 127.0.0.1 originating from the vulnerable application.
  • Audit application logs for ActivityPub federation requests referencing domains that resolve to 0.0.0.0 or localhost addresses.

What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include updating the vulnerable component to a patched version and applying recommended code fixes to prevent SSRF bypass.

  • Upgrade the activitypub-federation-rust library to version 0.7.0-beta.9 or later, where the `v4_is_invalid()` function includes checks for unspecified (0.0.0.0) and broadcast addresses.
  • Modify the `v4_is_invalid()` function to include additional IP validation checks as follows:
  • ```rust fn v4_is_invalid(v4: Ipv4Addr) -> bool { v4.is_private() || v4.is_loopback() || v4.is_link_local() || v4.is_multicast() || v4.is_documentation() || v4.is_unspecified() || v4.is_broadcast() } ```
  • Mitigate the DNS rebinding TOCTOU race condition by pinning DNS resolution results when making HTTP requests, for example:
  • ```rust let resolved_ip = lookup_host((domain, 80)).await?; // validate resolved_ip... let client = reqwest::Client::builder() .resolve(domain, resolved_ip) // pin resolution .build()?; ```
  • Review and monitor DNS records for domains used in ActivityPub federation to detect and block those resolving to 0.0.0.0 or other invalid IPs.

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