Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-11-05T21:18:53.727Z",
  "pubdate": "2026-11-05T21:18:53.727Z",
  "executiveSummary": "Remark42 versions 1.0.0 through 1.16.2 contain a critical vulnerability where the application globally trusts HTTP headers including True-Client-IP, X-Real-IP, and X-Forwarded-For to determine the remote client's identity.\nThe vulnerability stems from the middleware.RealIP implementation, which overwrites the request's r.RemoteAddr property without verifying if the direct peer is a trusted proxy.\nThis flaw allows remote, unauthenticated attackers to spoof their IP address by manipulating these headers, effectively bypassing critical security controls.\nImpacts include the evasion of rate-limiting, subversion of vote de-duplication mechanisms, the creation of fraudulent anonymous identities, and the corruption of request logs and comment IP tracking.\nThe risk is highest in directly reachable deployments or environments behind non-validating proxies, where an attacker can systematically rotate spoofed headers to exhaust or reset security throttles.\nWhile global concurrent-request limits remain in place, the application's ability to accurately attribute actions or enforce per-IP policies is entirely compromised.\nRemediation requires upgrading to version 1.16.2 and explicitly defining authorized proxy IP ranges via the --trusted-proxy configuration.",
  "technicalDetails": "The root cause of this vulnerability is the improper implementation of IP-based identification within the Remark42 middleware chain. Specifically, the application utilizes middleware.RealIP to process incoming requests and extract client identity from HTTP headers. This middleware globally trusts True-Client-IP, X-Real-IP, and X-Forwarded-For headers without performing any validation to confirm the validity or trustworthiness of the upstream peer.\nIn a standard deployment, the r.RemoteAddr variable is expected to represent the actual network address of the direct peer. However, the flawed middleware overwrites this value with the contents of the spoofable forwarding headers before the application executes per-IP security controls. Because the application logic relies on r.RemoteAddr for identifying users, an attacker can manipulate these headers to inject arbitrary IP addresses.\nThe attack flow involves an attacker sending crafted HTTP requests where the aforementioned headers are populated with spoofed or rotated IP addresses. Since the application fails to verify the request's origin against a known trusted proxy list, it accepts the spoofed values as authoritative. This enables the attacker to perform several unauthorized actions: 1) Rate-Limit Evasion: By rotating the spoofed IP in the headers, an attacker can obtain fresh token buckets for rate-limited endpoints, effectively bypassing anti-spam and DoS protections. 2) Vote Manipulation: When --votes-ip is enabled, the attacker can cast multiple votes by presenting a unique spoofed IP for each request, undermining the integrity of the voting system. 3) Identity Spoofing: An attacker can mint multiple anonymous identities linked to arbitrary IPs, complicating forensic investigations and enabling sybil attacks. 4) Log Poisoning: The application logs and stored comment IP fields will reflect the attacker's chosen values rather than the actual connection source, resulting in inaccurate audit trails.\nThis vulnerability affects versions 1.0.0 through 1.16.2. The exploitation requires no special privileges and is accessible to any remote attacker capable of sending HTTP requests to the target instance. The presence of a proxy that forwards attacker-controlled headers exacerbates the issue, though the application is inherently vulnerable if deployed in a directly reachable state without explicit trust configuration. Post-exploitation impact is characterized by the total loss of confidence in IP-based telemetry, rate-limiting, and access control enforcement."
}