CVE-2025-6444: ServiceStack Auth Bypass Vulnerability

CVE-2025-6444 Overview

CVE-2025-6444 is an improper input validation vulnerability in the ServiceStack web services framework. The flaw resides in the GetErrorResponse method, where insufficient validation of user-supplied data creates a type confusion condition. Remote attackers can exploit this weakness to relay NT LAN Manager (NTLM) credentials in the context of the current user. Exploitation requires interaction with the vulnerable library, and attack vectors depend on how applications integrate ServiceStack. The vulnerability was reported through the Zero Day Initiative as ZDI-CAN-25834 and published as ZDI-25-415. This weakness maps to [CWE-20] Improper Input Validation.

Critical Impact
Successful exploitation lets remote attackers relay NTLM credentials in the context of the current user, enabling authenticated access to downstream services.

Affected Products

ServiceStack (all versions matching CPE cpe:2.3:a:servicestack:servicestack:*)
Applications embedding the ServiceStack framework that expose the GetErrorResponse code path
Web services relying on ServiceStack error handling in Windows environments using NTLM authentication

Discovery Timeline

2025-06-25 - CVE-2025-6444 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-6444

Vulnerability Analysis

The vulnerability exists in the GetErrorResponse method within ServiceStack. The method processes user-supplied data without adequate type validation before use, permitting a type confusion condition. When an application invokes this code path with attacker-influenced input, the runtime interprets memory or object references in an unintended way. This behavior can be steered to trigger outbound authentication attempts that an attacker relays to another service.

An attacker who convinces a vulnerable client or server component to interact with attacker-controlled input can capture and forward NTLM authentication material. Because relayed credentials execute in the context of the current user or service account, an attacker gains the effective privileges of that identity on the relay target. Exploitation is network-based, does not require prior authentication, and involves no user interaction, though the attack complexity is high because it depends on specific implementation choices.

Root Cause

The root cause is missing type validation on user-supplied data consumed by GetErrorResponse. Instead of enforcing an expected object type, the method accepts input that can be coerced into a different type, causing the framework to process it along an unintended path that initiates outbound authentication.

Attack Vector

The attack originates over the network. An attacker sends crafted input to an endpoint that ultimately reaches GetErrorResponse. The type confusion triggers an outbound request from the ServiceStack process to an attacker-controlled endpoint. NTLM negotiation follows, and the attacker relays the challenge and response to a separate server that trusts the victim identity. Downstream targets can include SMB shares, LDAP directories, or Active Directory Certificate Services endpoints. See the Zero Day Initiative Advisory ZDI-25-415 for further technical detail.

Detection Methods for CVE-2025-6444

Indicators of Compromise

Unexpected outbound SMB (TCP 445) or HTTP authentication traffic originating from processes hosting ServiceStack
NTLM Type 1, Type 2, and Type 3 messages exchanged with hosts outside the trusted asset inventory
Error handling stack traces referencing GetErrorResponse correlating with anomalous outbound connections
Authentication events in Active Directory logs showing the ServiceStack service account authenticating to unexpected relay targets

Detection Strategies

Inspect ServiceStack request logs for malformed payloads targeting error-producing endpoints that reach the GetErrorResponse path
Monitor for outbound NTLM authentication from web application servers, which typically should not initiate NTLM to external hosts
Correlate application exception telemetry with network egress events using OCSF-normalized data in a SIEM or data lake

Monitoring Recommendations

Enable Windows Event ID 4624 and 4625 collection on servers that could be relay targets to spot anomalous logons from ServiceStack service accounts
Alert on any egress traffic from application tier hosts to TCP 445, 389, or 636 that lacks a business justification
Track process-to-network relationships for the ServiceStack host process and flag first-time destination pairs

How to Mitigate CVE-2025-6444

Immediate Actions Required

Identify all applications and services embedding ServiceStack and inventory their exposure to untrusted input
Update ServiceStack to a fixed release as indicated in the Zero Day Initiative Advisory ZDI-25-415 and vendor release notes
Restrict outbound SMB and NTLM traffic from application servers at the perimeter and internal segmentation boundaries
Enforce SMB signing and Extended Protection for Authentication (EPA) on servers that could serve as relay targets

Patch Information

ServiceStack has been notified through the Zero Day Initiative disclosure process. Consult the Zero Day Initiative Advisory ZDI-25-415 for the fixed version and remediation guidance. Apply the upgrade to every deployment that ships or references the affected ServiceStack assemblies.

Workarounds

Block outbound TCP 445 from application servers to any destination outside the trusted internal range
Disable NTLM authentication on downstream targets where Kerberos-only authentication is feasible
Add input validation and type checks at API gateway or reverse proxy layers to reject payloads that trigger GetErrorResponse with unexpected object shapes

bash

# Configuration example: block outbound NTLM/SMB egress from a ServiceStack host on Windows
New-NetFirewallRule -DisplayName "Block-Outbound-SMB-445" -Direction Outbound -Protocol TCP -RemotePort 445 -Action Block
New-NetFirewallRule -DisplayName "Block-Outbound-LDAP-389" -Direction Outbound -Protocol TCP -RemotePort 389 -Action Block

# Restrict outgoing NTLM traffic via Group Policy
# Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
# Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Deny all