CVE-2026-27812: Sub2API Password Reset Flaw Allows Account Takeover via Host Header Manipulation

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:

Host
X-Forwarded-Host
Forwarded

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 Host header.
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.