CVE-2026-77463 · Package
NO FIX YET · SEE WHAT TO DO
Remark42, a self-hosted blog comment engine, trusts client-supplied True-Client-IP, X-Real-IP and X-Forwarded-For headers without checking the sender is a trusted proxy. A remote attacker can rotate those headers to dodge per-IP rate limits and vote de-duplication, mint anonymous identities, and write fake IPs into stored comments and logs.
first public Jul 13, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Any Remark42 instance reachable directly from the internet, or behind a proxy that passes attacker-controlled forwarding headers through, is exposed. Deployments where a trusted reverse proxy strips and sets these headers, and only that proxy can reach the server, are less exposed once --trusted-proxy is configured correctly. The global concurrent-request throttle and request timeouts still limit availability impact.
Not affected if no-direct-internet-exposure, trusted-proxy-configured, version-1.16.2-or-later
Who cares blogs, remark42, self-hosted
remark42 --version or the image tag; versions from 1.0.0 through 1.16.2 are affected.--trusted-proxy; if it is absent, the server trusts forwarding headers from any peer.--votes-ip is enabled, since vote de-duplication depends on the IP.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.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
1.16.2 adds mitigation; the sources say operators must also configure --trusted-proxy for their topology.NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.