# Summary
MEGA-FENCE (webgate-lib.*) trusts an unvalidated, attacker-controlled X-Forwarded-For (XFF) header value as the client IP address. When present, the first XFF value is unconditionally accepted and propagated into security-relevant state, such as the WG_CLIENT_IP cookie. 

This can enable client IP spoofing and may undermine IP-based access controls, auditing, and rate limiting in certain deployment scenarios.
This vulnerability has been assigned **CVE-2025-65328**.

# Description
In MEGA-FENCE (webgate-lib.*), the function WG_GetUserAddress(HttpServletRequest) extracts the client IP address by trusting the first value of the X-Forwarded-For header whenever the header is present.

No validation is performed to ensure that the request originates from a trusted proxy, nor is there verification of a trusted proxy chain. As a result, a remote, unauthenticated attacker can supply an arbitrary X-Forwarded-For value to spoof the client IP address.

The derived client IP value is propagated into downstream state, including the WG_CLIENT_IP cookie. In deployments where this value is relied upon for IP-based allowlists, administrative access restrictions, auditing, abuse prevention, or rate limiting, an attacker may bypass these controls by spoofing a trusted source IP.

According to the vendor, the affected cookie is intended for logging purposes only and is not used internally for security-critical decisions by default. However, the unconditional trust of client-supplied IP headers introduces a trust-boundary violation and creates a conditional security risk depending on deployment configuration and downstream usage.

# Affected Products
- Product: MEGA-FENCE (webgate-lib.*)
- Versions: 25.1.914 and earlier

# Vulnerability Type
- Improper Access Control
- Trust of Untrusted Input

### CVE
- CWE-807: Reliance on Untrusted Inputs in a Security Decision
- CWE-284: Improper Access Control

# Attack Vector
A remote, unauthenticated attacker sends an HTTP request containing a crafted X-Forwarded-For header (for example, setting the first list element to a spoofed IP address). No user interaction is required.

### Minimal Reproduction Example


```
# Request
GET /9000/backend.php HTTP/1.1
Host: demo.example.com
X-Forwarded-For: 1.1.1.1
```

```
# Response
Set-Cookie: WG_CLIENT_IP=1.1.1.1
```

# Impact
Depending on deployment configuration and downstream usage, this issue may allow:
- Bypass of IP-based allowlists or administrative access restrictions
- Evasion of audit trails or log-based attribution
- Circumvention of rate limiting or abuse detection mechanisms

# Mitigation
Recommended remediation actions include:
1. Only parse and trust X-Forwarded-For headers when REMOTE_ADDR belongs to a configured trusted proxy CIDR range.
2. Implement a strict and documented precedence order when multiple IP-related headers are present (Forwarded, X-Forwarded-For, X-Real-IP).
3. Default to ignoring client-supplied IP headers unless explicitly enabled and documented.
4. Clearly document how client IP addresses are determined and under which trust assumptions.

# Vendor Status
The vendor has stated that the affected behavior is intended for logging purposes only and is not used for security-critical decisions in the default configuration. This advisory documents a conditional-impact vulnerability that may become exploitable when the derived client IP value is used for security enforcement in downstream deployments.

# Credits
- Discovered by: p1aintext
- Contact: p1aintext@proton.me

# References
- CVE-2025-65328