projectdiscovery/nuclei · warning
unexpected TDS status 0x%02x
Error message
unexpected TDS status 0x%02x
What it means
Returned by parsePreloginResponse when the second response byte is not 0x01 (TDSSTATUS_EOM, end-of-message), wrapped into errNotMssql by FingerprintMssql. After confirming type 0x04, the parser requires the status byte to mark a complete message; anything else means the packet is a fragment or simply not a conforming pre-login reply.
Source
Thrown at pkg/js/libs/mssql/fingerprint.go:187
MajorVersion int
MinorVersion int
BuildNumber int
Encryption int
EncryptionMode string
Mars bool
InstanceMatches bool
}
func parsePreloginResponse(response []byte) (preloginData, error) {
var out preloginData
if len(response) < 8 {
return out, fmt.Errorf("response too short for TDS header")
}
if response[0] != tdsTypeTabularResult {
return out, fmt.Errorf("unexpected TDS type 0x%02x", response[0])
}
if response[1] != tdsStatusEOM {
return out, fmt.Errorf("unexpected TDS status 0x%02x", response[1])
}
packetLength := int(binary.BigEndian.Uint16(response[2:4]))
if len(response) != packetLength {
return out, fmt.Errorf("packet length mismatch: header=%d body=%d", packetLength, len(response))
}
type optionToken struct {
token byte
offset uint16
length uint16
data []byte
}
position := 8
var tokens []optionToken
for position < len(response) {
if response[position] == tdsTerminator {
breakView on GitHub (pinned to 265b3a3dec)
Solutions
- Treat as 'not a standard MSSQL pre-login reply' and skip, or use mssql.IsMssql for boolean semantics
- Verify network path integrity (no DPI/proxy altering payloads) when MSSQL is definitely expected
- Capture the raw reply (info.Raw on success / packet dump while debugging) and compare against a known-good 04 01 pre-login response
Defensive patterns
Strategy: fallback
Try / catch
try {
const info = mssql.FingerprintMssql(host, port);
} catch (e) {
if (String(e).includes('not a mssql service')) return; // non-conforming reply => skip
throw e;
} Prevention
- Consider DPI/proxy interference when MSSQL is certain but the status byte is off
- Capture raw packets while debugging non-standard appliances
- Default handling: classify as not-MSSQL and continue the scan
When it happens
Trigger: A multi-packet TDS response where the first chunk lacks the EOM bit; a non-MSSQL service whose first byte coincidentally equals 0x04 but whose second byte differs (e.g. binary protocols, DPI-mangled replies).
Common situations: Middleboxes/IPS rewriting or truncating TDS streams; unusual SQL Server dialects or appliances that answer pre-login non-standardly; false positives on other binary protocols that begin 04 xx.
Related errors
- %w: invalid TDS packet length %d
- %w: %v
- unexpected TDS type 0x%02x
- not a mssql service
- response too short for TDS header
AI-assisted analysis of projectdiscovery/nuclei@265b3a3dec (2026-08-15).
Data as JSON: /api/errors/4dd585e095fc1581.
Report an issue: GitHub.