CVE-2026-77463: Remark42: Rate limit bypass via unconditional trust of X-Forwarded-For/X-Real-IP headers in direct-internet deployment
Remark42 is a self-hosted comment engine for blogs, articles, or any other place where readers can add comments. From 1.0.0 until 1.16.2, Remark42 globally trusts True-Client-IP, X-Real-IP, and X-Forwarded-For without verifying that the direct peer is a trusted proxy, and middleware.RealIP overwrites r.RemoteAddr before per-IP controls run. In a directly reachable deployment, or a proxy that forwards attacker-controlled headers, a remote attacker can rotate spoofed forwarding headers to obtain fresh token buckets for rate-limited endpoints, bypass vote de-duplication when --votes-ip is enabled, mint anonymous identities, and poison stored comment IPs and request logs. The global concurrent-request throttle and per-request timeouts still limit availability impact. Mitigation support is available in version 1.16.2, but operators must configure --trusted-proxy for the deployment topology.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Remark42to a version that resolves this vulnerability.Fixed in 1.16.2 - Configuration
Configure --trusted-proxy so Remark42 trusts forwarding headers only from the deployment's trusted proxy.
Remark42 --trusted-proxy = configured for the deployment topology
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Directly internet-reachable Remark42 deployments are exposed. Deployments behind a proxy are also exposed if that proxy forwards attacker-controlled True-Client-IP, X-Real-IP, or X-Forwarded-For headers.
What does an attacker need to exploit the bypass?
An unauthenticated remote attacker only needs to send requests with spoofed forwarding headers and rotate their values. This causes per-IP controls to treat requests as coming from new client addresses.
What security controls and data can be affected?
The issue can bypass rate limiting, vote de-duplication when --votes-ip is enabled, and anonymous identity controls. It can also poison stored comment IP addresses and request logs; global concurrent-request throttling and per-request timeouts continue to limit availability impact.
How should operators mitigate the issue?
Use version 1.16.2 and configure --trusted-proxy to match the actual proxy topology. Do not allow untrusted clients to supply forwarding headers that reach Remark42 as trusted client-address information.