Description

Lemmy is a link aggregator and forum for the fediverse. Prior to 0.19.19 and 1.0.0-beta.1, actix-web ConnectionInfo::realip_remote_addr reads the first value of X-Forwarded-For as the client address used by raw_ip_key in crates/utils/src/rate_limit/mod.rs. Lemmy's bundled docker/nginx.conf uses $proxy_add_x_forwarded_for instead of $remote_addr, which appends the real client address to an X-Forwarded-For value supplied by the client. An unauthenticated attacker can therefore place a different spoofed address first on each request and receive a new rate-limit bucket, bypassing limits on POST /api/v4/account/auth/register, POST /api/v4/account/auth/login, POST /api/v4/post, POST /api/v4/comment, GET /api/v4/search, POST /api/v4/image, and POST /api/v4/account/import_settings. This permits excessive account creation, brute-force attempts, spam, scraping, uploads, and repeated imports. This issue is fixed in versions 0.19.19 and 1.0.0-beta.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-19T21:16:58.073Z",
  "pubdate": "2026-08-19T21:16:58.073Z",
  "executiveSummary": "A rate-limiting bypass vulnerability exists in Lemmy prior to versions 0.19.19 and 1.0.0-beta.1. The vulnerability stems from improper client IP address extraction via the actix-web ConnectionInfo::realip_remote_addr method in conjunction with misconfigured reverse proxy headers in the bundled docker/nginx.conf. An unauthenticated attacker can exploit this flaw to bypass rate limits enforced on sensitive endpoints including account registration, authentication login, post creation, commenting, search, image uploads, and account settings import. The risk implication includes potential automated brute-force attacks, excessive account creation, spam dissemination, resource exhaustion through scraping, and unauthorized bulk uploads. Exploitation requires no authentication, allowing remote attackers to manipulate HTTP headers directly and allocate arbitrary rate-limiting buckets per request.",
  "technicalDetails": "The vulnerability resides in the crates/utils/src/rate_limit/mod.rs component of Lemmy, specifically within the raw_ip_key function which determines the client IP address utilized for rate-limiting logic. Prior to versions 0.19.19 and 1.0.0-beta.1, the application relies on actix-web ConnectionInfo::realip_remote_addr, which extracts the primary value from the incoming X-Forwarded-For HTTP header to identify the remote client. Simultaneously, the bundled docker/nginx.conf reverse proxy configuration utilizes the $proxy_add_x_forwarded_for directive rather than $remote_addr. This configuration appends the actual network client address to any pre-existing X-Forwarded-For header value explicitly supplied by the connecting HTTP client, rather than overwriting or securely appending the trusted proxy IP.\nBecause the application evaluates the first entry in the X-Forwarded-For header as the definitive client address, an unauthenticated remote attacker can inject arbitrary, spoofed IP addresses at the beginning of the header chain on every HTTP request. Consequently, the actix-web framework and underlying rate-limiting mechanism evaluate each spoofed IP address as a unique client origin. This behavior forces the allocation of a distinct rate-limiting bucket for every individual crafted request, effectively nullifying the protection mechanisms enforced on high-value endpoints such as POST /api/v4/account/auth/register, POST /api/v4/account/auth/login, POST /api/v4/post, POST /api/v4/comment, GET /api/v4/search, POST /api/v4/image, and POST /api/v4/account/import_settings.\nThe attack flow proceeds as follows: 1) The unauthenticated attacker crafts an HTTP request directed at one of the vulnerable API endpoints. 2) The attacker injects a maliciously constructed or randomly generated IP address into the X-Forwarded-For header, placing it before the proxy-appended values. 3) The request traverses the Nginx reverse proxy, which appends the true remote address subsequent to the client-supplied data. 4) Lemmy processes the request via ConnectionInfo::realip_remote_addr, isolates the attacker-controlled initial IP value, and passes it to raw_ip_key. 5) The application maps the request to a unique rate-limiting counter associated with the spoofed IP. 6) The attacker repeats the process with varying spoofed headers to execute brute-force attacks, spam generation, scraping, and unauthorized bulk operations without encountering rate-limit blocks."
}