What causes "sending over UDP failed to %s: %v" in projectdiscovery/nuclei?

Raise the client timeout above the 5s default

sending over UDP failed to %s: %v

Error message

sending over UDP failed to %s: %v

What it means

The UDP write succeeded but the subsequent ReadFrom failed. A read deadline of config.timeout seconds (default 5) is set before the exchange, so the usual cause is the deadline expiring with no reply, or ICMP port-unreachable being reflected back on the connected UDP socket as a read error.

Source

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

	}
	return nil, nil
}

// sendUDP sends bytes to connection over UDP.
func sendUDP(conn *net.UDPConn, b []byte) ([]byte, error) {
	var r []byte
	defer func() {
		_ = conn.Close()
	}()
	_, err := conn.Write(b)
	if err != nil {
		return r, fmt.Errorf("error sending to (%s): %v", conn.RemoteAddr().String(), err)
	}
	udpbuf := make([]byte, 4096)
	n, _, err := conn.ReadFrom(udpbuf)
	r = udpbuf[:n]
	if err != nil {
		return r, fmt.Errorf("sending over UDP failed to %s: %v", conn.RemoteAddr().String(), err)
	}
	if len(r) < 1 {
		return r, fmt.Errorf("no response data from %s", conn.RemoteAddr().String())
	}
	return r, nil
}

// sendTCP sends bytes to connection over TCP.
func sendTCP(conn *net.TCPConn, b []byte) ([]byte, error) {
	defer func() {
		_ = conn.Close()
	}()
	var r []byte
	// RFC 4120 7.2.2 specifies the first 4 bytes indicate the length of the message in big endian order.
	hb := make([]byte, 4)
	binary.BigEndian.PutUint32(hb, uint32(len(b)))
	b = append(hb, b...)

View on GitHub (pinned to 265b3a3dec)

Solutions

Raise the client timeout above the 5s default
Confirm the KDC actually serves UDP/88, otherwise rely on the TCP path
Retry once for transient loss before concluding the KDC is unreachable

Defensive patterns

Strategy: retry

Try / catch

try {
  const resp = kerberos.SendToKDC(client, msg);
} catch (e) {
  // UDP read timed out or got ICMP-unreachable: raise the 5s default timeout or confirm the KDC serves UDP/88
}

Prevention

Raise the client timeout for slow or remote KDCs
Check whether the KDC is TCP-only before relying on UDP replies

When it happens

Trigger: KDC not listening on UDP/88 (ICMP unreachable); packet loss on lossy links; reply arriving after the 5s deadline; middleboxes dropping UDP payloads of the Kerberos size.

Common situations: TCP-only KDC hardening; unreliable VPN links; oversized ticket replies lost to fragmentation; slow DCs under load missing the 5s window.

Related errors

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