What causes "error reading response: %v" in projectdiscovery/nuclei?

Raise the client timeout above the 5s default so large replies fit in the window

error reading response: %v

Error message

error reading response: %v

What it means

The 4-byte size header was read and declared a body length, but io.ReadFull could not read that many bytes. Either the connection dropped mid-response, or the header was corrupt and declared far more data than the KDC will ever send, so the reader waits until the deadline and fails.

Source

Thrown at pkg/js/libs/kerberos/sendtokdc.go:196

	binary.BigEndian.PutUint32(hb, uint32(len(b)))
	b = append(hb, b...)

	_, err := conn.Write(b)
	if err != nil {
		return r, fmt.Errorf("error sending to KDC (%s): %v", conn.RemoteAddr().String(), err)
	}

	sh := make([]byte, 4)
	_, err = conn.Read(sh)
	if err != nil {
		return r, fmt.Errorf("error reading response size header: %v", err)
	}
	s := binary.BigEndian.Uint32(sh)

	rb := make([]byte, s)
	_, err = io.ReadFull(conn, rb)
	if err != nil {
		return r, fmt.Errorf("error reading response: %v", err)
	}
	if len(rb) < 1 {
		return r, fmt.Errorf("no response data from KDC %s", conn.RemoteAddr().String())
	}
	return rb, nil
}

// CheckKrbError checks if the response bytes from the KDC are a KRBError.
func CheckKrbError(b []byte) ([]byte, error) {
	var KRBErr messages.KRBError
	if err := KRBErr.Unmarshal(b); err == nil {
		return b, KRBErr
	}
	return b, nil
}

// TGStoHashcat converts a TGS to a hashcat format.
func TGStoHashcat(tgs messages.Ticket, username string) (string, error) {

View on GitHub (pinned to 265b3a3dec)

Solutions

Raise the client timeout above the 5s default so large replies fit in the window
Verify nothing in the path (proxy, TLS-terminating LB) rewrites or truncates raw TCP/88 traffic
Cross-check with UDP; a consistent failure on both transports points to message encoding rather than the network

Defensive patterns

Strategy: retry

Try / catch

try {
  const resp = kerberos.SendToKDC(client, msg);
} catch (e) {
  // body read failed or declared length was bogus: raise the timeout and ensure nothing rewrites raw TCP/88 traffic
}

Prevention

Keep proxies and TLS terminators out of the raw KDC path
Raise the timeout so large ticket replies fit inside the deadline

When it happens

Trigger: Connection reset between header and body; a garbage size header (for example reading plaintext or an error banner as if it were Kerberos) yielding a huge length; deadline too short for a large ticket reply.

Common situations: Proxies injecting error pages into the stream; DCs truncating large TGS replies; slow links where big responses exceed the 5s deadline.

Related errors

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