CVE-2026-54738 in Lemmy
Summary
by MITRE • 08/20/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified involves a critical misconfiguration in how the Lemmy application handles client IP addresses for rate limiting purposes within its reverse proxy setup. Lemmy, functioning as a link aggregator and forum on the fediverse, relies heavily on accurate identification of individual users to enforce security policies such as brute-force protection and spam prevention. The core technical flaw stems from an inconsistency between the application logic in crates/utils/src/rate_limit/mod.rs and the nginx configuration bundled with the software. Specifically, the actix-web framework's ConnectionInfo::realip_remote_addr function is configured to read the first value of the X-Forwarded-For header as the client address via raw_ip_key. However, the default nginx.conf utilizes $proxy_add_x_forwarded_for when proxying requests. This directive appends the actual remote client IP address to any existing X-Forwarded-For header sent by the client rather than replacing it or ensuring a trusted source is at the front of the chain.
This architectural mismatch creates an opportunity for unauthenticated attackers to bypass rate limiting mechanisms through header manipulation. Because nginx appends the real client IP to whatever value the attacker supplies in the initial request, the application sees the attacker-controlled spoofed address as the first entry in the X-Forwarded-For list. Consequently, the rate limiter assigns a new bucket based on this fake IP rather than the true source of the traffic. This allows an adversary to rotate their apparent identity with every single HTTP request by injecting different random or sequential IP addresses into the header field. By doing so, they effectively reset their rate limit counter for each action taken against protected endpoints.
The operational impact of this vulnerability is severe across multiple attack vectors within the Lemmy API. The bypass affects critical endpoints including POST /api/v4/account/auth/register, which allows for excessive and automated account creation; POST /api/v4/account/auth/login, enabling unlimited brute-force password guessing attempts without lockout; POST /api/v4/post and POST /api/v4/comment, facilitating high-volume spamming of forum content; GET /api/v4/search, permitting aggressive scraping of community data; POST /api/v4/image, allowing unrestricted upload abuse that can consume storage resources; and POST /api/v4/account/import_settings, which permits repeated configuration imports. These capabilities collectively degrade service availability, compromise user account security through credential stuffing or brute force, and overwhelm system resources with spam and unauthorized uploads.
From a classification perspective, this issue aligns with CWE-798: Use of Hard-coded Credentials if viewed broadly as trust misconfiguration, but more accurately maps to CWE-284: Improper Access Control regarding the bypass of rate limiting controls. In terms of offensive security frameworks, it corresponds to ATT&CK technique T1190: Exploit Public-Facing Application and specifically relates to methods used in automated account creation (T1136) or brute-force attacks (T1110). The root cause is a failure to properly validate the source of proxy headers, leading to CWE-20: Improper Input Validation where the application trusts client-supplied data over server-enforced context.
To mitigate this vulnerability, administrators must update their nginx configuration immediately if they are running versions prior to 0.19.19 or 1.0.0-beta.1. The fix involves changing $proxy_add_x_forwarded_for to $remote_addr in the proxy headers section of the nginx.conf file. This ensures that only the actual client IP address is passed to the application, preventing attackers from spoofing their identity via header injection. Alternatively, if maintaining dynamic forwarding is required for legitimate use cases behind trusted proxies, the configuration should explicitly set X-Forwarded-For using $remote_addr and ensure no additional appending occurs unless strictly necessary and validated by a reverse proxy that strips untrusted headers. Upgrading to version 0.19.19 or later resolves this issue as it corrects the underlying logic to handle IP identification more robustly, ensuring rate limits are applied based on true client identity rather than manipulable header fields.