Description

A vulnerability was found in Studio-Saelix Sencho up to 0.94.1. This affects an unknown part of the file /api/auth/login of the component Login Endpoint. Performing a manipulation of the argument X-Forwarded-For results in improper authentication. The attack is possible to be carried out remotely. The exploit has been made public and could be used. The patch is named 79b86ddcd4aefdd6941f098e35990ab397b13c72. To fix this issue, it is recommended to deploy a patch. The vendor confirms: "The login limiter relied on client-supplied X-Forwarded-For data without an explicit trusted-proxy boundary, allowing an attacker to rotate the apparent client address. The remediation now ignores forwarding headers by default, accepts them only from explicitly configured proxy CIDRs, and adds a separate failed-attempt limit keyed by normalized account identity."

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.3",
  "pubDate": "2026-10-11T04:17:31.737Z",
  "pubdate": "2026-10-11T04:17:31.737Z",
  "executiveSummary": "A critical security flaw in Studio-Saelix Sencho (up to version 0.94.1) allows for improper authentication through the manipulation of the X-Forwarded-For HTTP header. The vulnerability exists within the /api/auth/login endpoint, which incorrectly trusts client-supplied header data for rate-limiting purposes.\nThis vulnerability effectively enables an attacker to bypass login rate-limiting controls by rotating the apparent source IP address associated with authentication attempts. Because the system fails to validate the origin of these forwarding headers against a trusted-proxy boundary, an attacker can launch brute-force or credential-stuffing attacks without being throttled.\nThe vulnerability is remotely exploitable, requiring no authentication prior to interaction with the target endpoint. Given that functional exploit code is publicly available, the risk of exploitation is significantly elevated. Organizations utilizing affected versions are at high risk of unauthorized account access due to the degradation of login security controls.",
  "technicalDetails": "The vulnerability is rooted in an insecure implementation of request origin validation within the login limiter component. The /api/auth/login endpoint in Studio-Saelix Sencho, prior to version 0.94.1, processed the 'X-Forwarded-For' HTTP header to determine the client's IP address for the purpose of enforcing rate limits on authentication attempts. The application failed to implement an explicit trusted-proxy boundary, which is a fundamental security requirement when relying on proxy-provided headers.\nBy manipulating the 'X-Forwarded-For' header, an attacker can programmatically inject arbitrary IP addresses into the application’s request processing flow. Since the application logic accepts these headers at face value without verifying that the request originated from a legitimate, pre-configured load balancer or reverse proxy, the rate-limiting mechanism is effectively bypassed. Each subsequent login attempt can be associated with a unique, forged IP address, preventing the system from identifying and blocking high-frequency authentication attempts from a single malicious source.\nThe attack flow proceeds as follows: 1) The attacker initiates an authentication request to the /api/auth/login endpoint. 2) The attacker inserts a forged 'X-Forwarded-For' header containing an arbitrary IP address. 3) The backend logic parses this header and updates the rate-limiting counter for that specific, fake IP address instead of the attacker’s true network origin. 4) The attacker continues to cycle through various forged IP addresses to circumvent account lockout or request throttling, enabling sustained brute-force attacks against user credentials.\nThe impact of this vulnerability is a complete bypass of the security perimeter designed to protect the authentication service. By decoupling the rate-limiting mechanism from the actual network connection, the attacker effectively disables the brute-force protection afforded to the system. The remediation, identified by commit 79b86ddcd4aefdd6941f098e35990ab397b13c72, addresses this by explicitly ignoring forwarding headers by default, ensuring that only requests originating from defined, trusted CIDR ranges are processed for IP-based logic, and shifting to a more secure, identity-based rate-limiting approach that tracks account-specific failed attempts rather than relying solely on client-supplied networking metadata."
}