projectdiscovery/nuclei · error

failed to read response: %w

Error message

failed to read response: %w

What it means

Returned by telnet.DetectNTLM when reading the server's response fails after the MS-TNAP login packet was sent successfully. The read runs under a hardcoded 10-second deadline set on the connection just before the exchange, so the common cause is an i/o timeout — the server sent nothing within 10s — or a connection reset/EOF while waiting.

Source

Thrown at pkg/js/libs/telnet/telnet.go:260

	// Set timeout
	_ = conn.SetDeadline(time.Now().Add(10 * time.Second))

	// Use the MS-TNAP packet crafting functions from our telnetmini library
	// Create MS-TNAP Login Packet (Option Command IS) as per Nmap script
	tnapLoginPacket := telnetmini.CreateTNAPLoginPacket()

	// Send the MS-TNAP login packet
	_, err = conn.Write(tnapLoginPacket)
	if err != nil {
		return nil, fmt.Errorf("failed to send MS-TNAP login packet: %w", err)
	}

	// Read response data
	buffer := make([]byte, 4096)
	n, err := conn.Read(buffer)
	if err != nil {
		return nil, fmt.Errorf("failed to read response: %w", err)
	}

	if n == 0 {
		return nil, fmt.Errorf("no response received")
	}

	// Parse NTLM response using our telnetmini library functions
	response := buffer[:n]

	// Use the parsing functions from our library instead of reimplementing
	// This should use the NTLM parsing functions we added to telnetmini
	ntlmInfo, err := telnetmini.ParseNTLMResponse(response)
	if err != nil {
		return nil, fmt.Errorf("failed to parse NTLM response: %w", err)
	}

	return ntlmInfo, nil
}

View on GitHub (pinned to 265b3a3dec)

Solutions

  1. Confirm the target is a Windows telnet service with NTLM authentication enabled
  2. Treat timeout as 'no NTLM info' and continue the scan rather than failing the template
  3. Retry once for flaky links; check egress filtering if reads always time out
Defensive patterns

Strategy: retry

Try / catch

try { client.DetectNTLM(host, port) } catch (e) { if (String(e).includes('failed to read response')) { /* 10s deadline hit or reset: treat as no NTLM */ } else { throw e; } }

Prevention

When it happens

Trigger: Server receives the TNAP packet but never answers (non-Windows telnet, or NTLM not enabled and the server waits for plain telnet negotiation); connection reset mid-read; slow or lossy network exceeding the 10s deadline.

Common situations: Probing Linux telnetd or embedded devices that ignore MS-TNAP; high-latency targets; IDS terminating the session after seeing the NTLM probe.

Related errors


AI-assisted analysis of projectdiscovery/nuclei@265b3a3dec (2026-08-15). Data as JSON: /api/errors/5acc970d1ce81b7b. Report an issue: GitHub.