Submeter #893366: Studio-Saelix sencho <= 0.94.1 Authentication Bypass by Spoofing

SUMMARY

The POST /api/auth/login endpoint in Sencho implements a rate-limiting middleware that derives the client's identity from the X-Forwarded-For request header without verifying whether the request actually originates from a trusted reverse proxy. Because this header is fully attacker-controlled on a direct connection, the rate limit can be trivially bypassed.

DETAILS

Each distinct X-Forwarded-For value is granted a fresh quota of 5 attempts. An attacker can rotate this header on every request (at zero cost, without needing real proxy infrastructure) to perform unrate-limited password guessing against any account, including the administrator account.

PROOF OF CONCEPT

Submit a login request with a spoofed header:
curl -s -i -X POST http://TARGET:1852/api/auth/login \
-H "Content-Type: application/json" \
-H "X-Forwarded-For: x.x.x.x" \
-d '{"username":"admin","password":"wrongpass"}'
-> RateLimit-Remaining: 4

Rotate the IP on the next request:
curl -s -i -X POST http://TARGET:1852/api/auth/login \
-H "Content-Type: application/json" \
-H "X-Forwarded-For: x.x.x.x" \
-d '{"username":"admin","password":"wrongpass"}'
-> RateLimit-Remaining: 4 (a brand new bucket is granted)

Repeating with a freshly incremented X-Forwarded-For value on every request keeps RateLimit-Remaining at 4 indefinitely, allowing an unbounded number of password attempts against a single account.

IMPACT

This removes the only defense against online brute-force password guessing on the login endpoint. Combined with a weak or reused administrator password, this could lead to full admin account takeover. Sencho manages Docker Compose deployments across potentially multiple nodes and mounts /var/run/docker.sock, so admin takeover has a direct path to host-level compromise.

FIX

Do not trust X-Forwarded-For for rate-limiting identity unless the request originates from a configured, trusted proxy IP (allowlist), in which case only the last hop / a specifically-configured trusted-proxy-count of entries should be honored per standard reverse-proxy header handling (e.g. Express's trust proxy setting used correctly, or an allowlist of proxy IPs). Where no trusted proxy is configured, rate-limit by the actual TCP-level remote address instead. Additionally, consider a secondary, account-based rate limit (independent of any client-supplied identity) so that even a legitimately-rotating client IP cannot bypass a per-account attempt cap.

DUPLICATE CHECK

Checked VulDB, NVD, and the GitHub public Advisory Database prior to submission; no existing entry found. The vendor's own advisories page (github.com/Studio-Saelix/sencho/security/advisories) shows no published advisories as of this submission.

VENDOR CONTACT

Vendor contacted via a private GitHub Security Advisory (GHSA-6h3c-pjgc-rw9f) on Studio-Saelix/sencho. No CVE requested and no patch published by maintainers as of this submission.

• Fonte: ⚠️ https://gist.github.com/jovair1994/839c8aaca1f37567cdd02e107a389f6a
• Utilizador: jpazz (UID 99722)
• Submissão: 16/07/2026 22h19 (há 3 meses)
• Moderação: 10/10/2026 14h48 (3 months later)
• Estado: Aceite
• Entrada VulDB: 416188 [Studio-Saelix Sencho até 0.94.1 Login Endpoint /api/auth/login X-Forwarded-For Autenticação fraca]
• Pontos: 20