CVE-2026-54738: Lemmy Auth Bypass Vulnerability

CVE-2026-54738 Overview

CVE-2026-54738 is a rate-limiting bypass vulnerability in Lemmy, a federated link aggregator and forum platform. The flaw resides in how Lemmy identifies client IP addresses for rate-limit bucketing. The actix-webConnectionInfo::realip_remote_addr function reads the first value from the X-Forwarded-For header as the client address in crates/utils/src/rate_limit/mod.rs. Lemmy's bundled docker/nginx.conf uses $proxy_add_x_forwarded_for instead of $remote_addr, appending the real client IP after any attacker-supplied value. Unauthenticated attackers can prepend a spoofed address on each request and receive a fresh rate-limit bucket. The issue affects versions prior to 0.19.19 and 1.0.0-beta.1.

Critical Impact
Attackers can bypass rate limits on registration, login, post/comment creation, search, image upload, and settings import endpoints, enabling account spam, brute-force login attempts, and content abuse.

Affected Products

Lemmy versions prior to 0.19.19
Lemmy 1.0.0 pre-release versions prior to 1.0.0-beta.1
Deployments using the bundled docker/nginx.conf or docker/federation/nginx.conf reverse proxy configuration

Discovery Timeline

2026-08-19 - CVE-2026-54738 published to NVD
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-54738

Vulnerability Analysis

The vulnerability is an instance of improper enforcement of a single, unique action per client [CWE-799]. Lemmy's rate limiter keys its buckets on raw_ip_key, which is derived from actix-web's ConnectionInfo::realip_remote_addr. That helper returns the leftmost value in the X-Forwarded-For header without validating whether the value originated from a trusted proxy. Because the bundled nginx configuration forwards the client-supplied header value and only appends the real remote address, the attacker fully controls the first hop seen by the backend. Every request with a new spoofed leading IP maps to a new rate-limit bucket, effectively disabling per-client throttling.

Root Cause

The root cause is a mismatch between the reverse proxy configuration and the application's trust model. In docker/nginx.conf, the directive proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; preserves any client-supplied header and appends $remote_addr. The Lemmy backend then trusts the first element of that header as the authoritative client IP. The application should have either read the last (proxy-appended) value or the nginx layer should have overwritten the header with $remote_addr before proxying.

Attack Vector

An unauthenticated remote attacker sends requests with a crafted X-Forwarded-For header containing an arbitrary IP as the first value. Each unique spoofed IP produces a distinct rate-limit bucket. Affected endpoints include 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. Abuse enables mass account creation, credential brute-forcing, spam posting, scraping, image upload floods, and repeated settings imports.

text

// Patch from docker/nginx.conf — replace $proxy_add_x_forwarded_for with $remote_addr
            rewrite ^(.+)/+$ $1 permanent;
            # Send actual client IP upstream
-            proxy_set_header X-Real-IP $remote_addr;
-            proxy_set_header Host $host;
-            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+            proxy_set_header X-Forwarded-For $remote_addr;
        }

        # backend

Source: LemmyNet/lemmy commit 41513c8

Detection Methods for CVE-2026-54738

Indicators of Compromise

High volume of requests to /api/v4/account/auth/register or /api/v4/account/auth/login from a narrow set of upstream TCP source addresses but with widely varying X-Forwarded-For leading values.
Requests where the leftmost X-Forwarded-For value is a private, reserved, or bogon IP range while the actual TCP source is a public address.
Sudden spikes in newly created accounts, comments, or image uploads without corresponding growth in unique TCP source IPs.

Detection Strategies

Parse both the TCP source address and the full X-Forwarded-For chain in nginx access logs, and alert when many distinct leading values map to the same TCP peer.
Correlate application-layer events (registrations, logins, uploads) with network-layer client identity rather than relying on Lemmy's internal rate-limit signals.
Deploy WAF rules that reject or normalize inbound X-Forwarded-For headers on the internet-facing edge before they reach nginx.

Monitoring Recommendations

Ship nginx and Lemmy application logs into a centralized analytics platform and baseline registration, login-failure, and upload rates per real client IP.
Alert on brute-force patterns such as repeated 401 responses from /api/v4/account/auth/login across multiple spoofed forwarded IPs sharing the same TCP peer.
Track the ratio of unique X-Forwarded-For leading values to unique TCP source IPs; a ratio significantly greater than 1 indicates header manipulation.

How to Mitigate CVE-2026-54738

Immediate Actions Required

Upgrade Lemmy to version 0.19.19 or 1.0.0-beta.1 or later, which contain the corrected nginx templates.
Replace proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; with proxy_set_header X-Forwarded-For $remote_addr; in both docker/nginx.conf and docker/federation/nginx.conf.
Audit any custom reverse proxy configurations in front of Lemmy to ensure client-supplied X-Forwarded-For values are overwritten, not appended.

Patch Information

The issue is fixed in Lemmy 0.19.19 and 1.0.0-beta.1. See the GitHub Security Advisory GHSA-2hrg-7x4g-9vpg, the fix pull requests #6574 and #6575, and the 0.19.19 release notes and 1.0.0-beta.1 release notes.

Workarounds

If patching is delayed, edit the deployed nginx configuration to overwrite X-Forwarded-For with $remote_addr and reload nginx.
Terminate TLS and normalize forwarded headers at an upstream WAF or CDN that strips or rewrites X-Forwarded-For before requests reach nginx.
Temporarily lower application-level rate limits and require CAPTCHA or email verification on registration and login endpoints to reduce abuse impact.

bash

# Corrected nginx snippet — apply and reload nginx
#   in docker/nginx.conf and docker/federation/nginx.conf
location / {
    proxy_pass $proxpass;

    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;

    rewrite ^(.+)/+$ $1 permanent;
}

# Reload nginx after editing
# nginx -t && nginx -s reload