CVE-2026-77463 in Remark42
Summary
by MITRE • 11/05/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/05/2026
Remark42 serves as a self-hosted comment engine designed to facilitate reader engagement on blogs, articles, and other digital content platforms. The vulnerability identified within versions ranging from 1.0.0 through 1.16.2 stems from an insecure trust model regarding client IP address identification in reverse proxy environments. Specifically, the application globally trusts standard HTTP headers such as True-Client-IP, X-Real-IP, and X-Forwarded-For without performing any verification to ensure that these headers originate from a trusted upstream proxy or load balancer. This architectural flaw allows the middleware.RealIP component to overwrite the r.RemoteAddr field with values provided in these untrusted headers before per-IP security controls are evaluated. Consequently, if an attacker can send requests directly to the application or through an intermediary proxy that forwards client-controlled headers, they can manipulate the perceived source IP address of their requests.
The operational impact of this vulnerability is multifaceted and affects several critical security mechanisms within the Remark42 ecosystem. First, attackers can bypass rate-limiting controls by rotating spoofed forwarding headers to obtain fresh token buckets for endpoints that are subject to per-IP throttling. This allows malicious actors to perform denial-of-service attacks or spamming activities at a higher volume than intended. Second, when the --votes-ip feature is enabled, which is designed to prevent users from voting multiple times on the same content, attackers can circumvent this deduplication logic by spoofing different IP addresses for each vote. This undermines the integrity of community engagement metrics and allows for manipulation of post popularity or sentiment analysis data.
Furthermore, the ability to forge source IPs enables attackers to mint anonymous identities that appear distinct from one another, facilitating account creation abuse or evasion of identity-based restrictions. Additionally, this flaw leads to IP address poisoning in stored comment logs and request audit trails. By injecting false IP addresses into these records, attackers can obscure their true origin, making forensic analysis and incident response significantly more difficult for system administrators. While the global concurrent-request throttle and per-request timeouts provide some residual protection against total availability loss by limiting overall resource consumption, they do not mitigate the specific bypasses of application-level logic such as rate limits or vote deduplication.
This vulnerability is categorized under CWE-287 Improper Authentication due to its failure to correctly identify and authenticate users based on their network identity, and it aligns with ATT&CK techniques related to IP address spoofing and evasion of detection mechanisms. The root cause lies in the assumption that all incoming requests are proxied through a trusted infrastructure component capable of sanitizing or validating client headers. In deployments where Remark42 is directly exposed to the internet without an intervening reverse proxy, this trust model is fundamentally flawed as any remote actor can supply arbitrary header values.
Mitigation for this issue requires both software updates and configuration adjustments. Although version 1.16.2 includes mitigation support, it does not automatically resolve the vulnerability unless explicitly configured by the operator. Administrators must utilize the --trusted-proxy flag to specify which IP addresses or subnets are authorized to set forwarding headers. This ensures that only requests originating from known load balancers or reverse proxies will have their X-Forwarded-For and similar headers respected for identity determination. Requests coming directly from untrusted sources will retain their actual connection IP address, thereby preserving the integrity of rate limiting, vote deduplication, and logging mechanisms. Organizations running older versions should prioritize upgrading to 1.16.2 or later while simultaneously auditing their deployment topology to ensure that trusted proxy configurations are correctly applied to prevent exploitation.