Sub2API Password Reset Poisoning via Host Header Manipulation
CVE ID: CVE-2026-27812
Product: Sub2API
Affected Versions: Versions prior to 0.1.85
Fixed Version: 0.1.85 and later
Severity: High
CVSS Score: 8.0 (High)
Attack Vector: Network
Attack Complexity: Low
Privileges Required: None
User Interaction: Required (victim must click reset link)
Exploit Availability: No public weaponized exploit observed at time of writing
CVE-2026-27812 is a password reset poisoning vulnerability in Sub2API. The issue occurs because the application trusts the incoming HTTP Host and related forwarding headers when generating password reset URLs. These headers are user-controlled and can be manipulated.
When a password reset request is submitted, the system constructs the reset link using the supplied Host header instead of a fixed, trusted application base URL. This allows an attacker to inject a malicious domain into the reset email.
If a victim clicks the poisoned link, the reset token can be captured by the attacker, enabling full account takeover.
Technical Root Cause
The vulnerability exists due to improper trust of client-controlled HTTP headers:
HostX-Forwarded-HostForwarded
Instead of validating these headers or using a configured canonical domain, the application dynamically builds the reset URL based on the request context.
Example flawed logic:
reset_url = "https://" + request.host + "/reset?token=" + token
Because request.host is derived from user input, it can be modified during the password reset request.
This results in:
- Untrusted data being reflected into outbound emails
- Exposure of reset tokens
- Potential account compromise
Attack Scenario
- An attacker identifies a valid user email address.
- The attacker submits a password reset request.
- The attacker manipulates the Host header:
POST /forgot-password HTTP/1.1
Host: attacker-domain.com
Content-Type: application/[email protected]
- The application sends a reset email to the victim.
- The email contains:
https://attacker-domain.com/reset?token=abc123
- The victim clicks the link.
- The token is captured by the attacker.
- The attacker uses the token against the legitimate system and sets a new password.
Account takeover is achieved without authentication bypass or brute force.
Impact
- Account takeover
- Credential compromise
- Unauthorized API usage
- Potential lateral movement if API keys are exposed
- Trust damage due to phishing-style email abuse
If Sub2API is integrated into production AI infrastructure, exploitation may result in data exposure or abuse of API quotas.
MITRE ATT&CK Mapping
- T1190 – Exploit Public-Facing Application
- T1556 – Modify Authentication Process
- T1078 – Valid Accounts
- T1539 – Steal Web Session Cookie / Credential Material
The vulnerability enables attackers to gain access to valid accounts through manipulation of reset workflows.
Proof of Concept (Educational)
The following example demonstrates how header manipulation can be performed in a controlled lab environment.
cURL Example
curl -X POST https://target-app.com/forgot-password \
-H "Host: attacker-controlled.com" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "[email protected]"
If vulnerable, the reset email will contain attacker-controlled.com as the base URL.
Burp Suite Testing Steps
- Intercept password reset request.
- Modify
Hostheader. - Forward request.
- Check reset email content.
- Verify if reset link reflects manipulated domain.
No public automated exploit toolkit is currently known.
Detection Strategy
Log Sources to Monitor
- Reverse proxy logs (Nginx / Apache)
- Load balancer logs
- Web application logs
- Email gateway logs
- Authentication logs
- WAF logs
Monitoring must focus on abnormal Host header values targeting reset endpoints.
Indicators of Compromise
- Reset emails containing non-canonical domains
- Host headers not matching configured application domain
- Multiple password reset attempts from a single IP
- Successful login immediately following reset from unusual IP
- DNS traffic toward domains not owned by the organization
Detection Rules
Splunk Query
index=web_logs
(uri_path="/forgot-password" OR uri_path="/reset-password" OR uri_path="/password/reset")
| where NOT like(host, "%yourdomain.com%")
| stats count by client_ip, host, uri_path, user_agent, _time
Elastic (KQL)
http.request.uri : ("/forgot-password" or "/reset-password") and
not http.request.headers.host : "yourdomain.com"
Microsoft Sentinel (KQL)
CommonSecurityLog
| where RequestURL contains "/forgot-password" or RequestURL contains "/reset-password"
| where HostName !contains "yourdomain.com"
| summarize count() by SourceIP, HostName, RequestURL, TimeGenerated
Suricata Rule (Example)
alert http any any -> $HOME_NET any (
msg:"Possible Host Header Password Reset Poisoning";
flow:to_server,established;
http.uri; content:"/forgot-password";
http.header; pcre:"/Host:\s*(?!yourdomain\.com)/i";
sid:900001;
rev:1;
)
WAF Detection Logic
- Reject requests where Host header does not match allowed list.
- Block requests with multiple Host headers.
- Block mismatched Forwarded or X-Forwarded-Host values.
- Rate limit reset endpoint requests.
Remediation
Immediate Actions
- Upgrade to patched version.
- Invalidate all active password reset tokens.
- Force password reset for high-value accounts.
- Enable MFA if not already enabled.
- Audit reset logs for anomalies.
Permanent Fix
Sub2API version 0.1.85 introduces proper hostname validation and secure URL construction.
Official Patch / Upgrade Link:
https://github.com/Wei-Shaw/sub2api/security/advisories/GHSA-vc2q-289v-74g3
Upgrade immediately to version 0.1.85 or later.
Secure Development Recommendations
- Never trust client-controlled headers.
- Use static configuration for base URLs.
- Implement strict Host header validation.
- Use short-lived reset tokens (5–10 minutes).
- Bind reset tokens to user-agent or IP where possible.
- Log and alert on reset token generation and usage.
- Implement anomaly detection for account recovery flows.
Risk Assessment
Although user interaction is required, exploitation is straightforward and realistic in phishing scenarios. The vulnerability does not require authentication, making it attractive for opportunistic attackers.
Organizations running exposed Sub2API instances should treat this as a high-priority patching requirement.
