Forwarded Header Trust Bypasses Country and Restricted-Asset Compliance Checks

Reported Feb 21, 2026

Severity High

Platform Web

Vulnerability Class Business Logic / Trust Boundary (CWE-348)

Target Type Cryptocurrency Exchange

Impact Compliance decisions controllable by any unauthenticated client

The Risk

The exchange decided whether a visitor was in a sanctioned country, and which assets were restricted for them, by reading a value the visitor's own browser sent in the request. By changing one line in the request, anyone could make the site believe they were in an allowed country and remove the restricted-asset list entirely. If those same signals are used anywhere in the login, registration, trading, or withdrawal path, sanctioned and country-restricted users can quietly slip past compliance controls the company is legally required to enforce.

The Vulnerability

The exchange's compliance endpoints derived the client's geographic state from attacker-controlled HTTP forwarding headers rather than from the actual network-layer source IP. The origin accepted X-Forwarded-For as authoritative and reflected the supplied value back as the "client IP" in compliance responses.

Two unauthenticated endpoints were affected:

An IP check endpoint returning the client IP, country code, country name, and a restricted flag.
A country-specific endpoint returning a restricted flag and a list of assets restricted for that jurisdiction.

Response headers indicated no upstream proxy was stripping client-supplied forwarding headers, so the values sent by the browser reached the origin unchanged.

The Attack

Country Decision Flip

Sending a single header was sufficient to change the compliance decision:

curl -s "https://example.com/api/auth/region-check" \
  -H "X-Forwarded-For: 198.51.100.10"
# isRestricted: true (sanctioned-country IP)

curl -s "https://example.com/api/auth/region-check" \
  -H "X-Forwarded-For: 8.8.8.8"
# isRestricted: false (allowed IP)

Country-Specific Asset List Cleared

With a country-specific IP spoofed, the response listed 16 restricted assets. Spoofing the same header to an allowed IP returned an empty restricted asset list, removing the compliance gate entirely.

Header Parsing Weakness

When multiple IPs were supplied in the header, the server selected the left-most value. This made the bypass trivial even in deployments where a downstream proxy would normally append the real client IP, because the attacker-supplied value always won.

The Impact

The compliance decision layer is controllable by any unauthenticated client with a single header.
Users from sanctioned regions can present as allowed-country visitors.
Country-specific restricted asset lists can be cleared, allowing access to assets that would otherwise be blocked for that jurisdiction.
If these compliance signals feed into login, registration, trading, or withdrawal flows, the bypass becomes a direct compliance control failure, with regulatory and reputational exposure for the platform.

Remediation

Only honour X-Forwarded-For and similar forwarding headers when set by trusted infrastructure. Strip or overwrite client-supplied values at the edge.
Standardise on a single authoritative header injected by a trusted proxy, or use the true peer IP at the origin.
For security-critical decisions, enforce geographic state server-side at the action layer (order placement, withdrawals, registration), using trusted IP data, never client headers.
Audit other endpoints for the same trust pattern, since a single misconfiguration like this often repeats across the API surface.