CVE-2026-81928: Net::DNS versions before 1.57 for Perl allow memory exhaustion via unbounded recursion in sig_data when re-encoding a message with a misplaced TSIG record
Net::DNS versions before 1.57 for Perl allow memory exhaustion via unbounded recursion in sigdata when re-encoding a message with a misplaced TSIG record.
sigdata signs a message by re-encoding it, and removes TSIG records only from the additional section. A TSIG decoded into the answer or authority section survives that step and is signed again, so encoding re-enters sigdata with no termination condition. Decoding does not reject such a message: a TSIG that is not the last record on the wire raises "misplaced or corrupt TSIG", but the error is caught, reported as a warning, and the record is left in the packet. RFC 8945 section 5.2 requires the message to be dropped.
The recursion is reached only when the decoded TSIG carries an empty MAC, since a MAC recovered from the wire short-circuits the signing step. It is reached only from code that re-encodes a message it decoded, such as a forwarder or a proxy. A decoded message that is never re-encoded is unaffected. Message direction does not matter: a query reaches the same path as a response.
Each cycle re-encodes the whole message, so fewer than 100 bytes on the wire exhaust available memory and terminate the process.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Net::DNS (Perl)to a version that resolves this vulnerability.Fixed in 1.57 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch RFC 8945 section 5.2 requires the message to be dropped
Event History
Frequently Asked Questions
Which deployments are realistically exposed to this issue?
Deployments using Net::DNS before 1.57 are exposed only if they decode DNS messages and later re-encode them, such as forwarders or proxies. Applications that decode a message but never re-encode it are unaffected.
What must an attacker include to trigger the memory exhaustion?
The attacker needs to supply a message containing a TSIG record in the answer or authority section, rather than the expected additional section, with an empty MAC. The TSIG must also survive decoding; a TSIG that is not last on the wire produces a warning but is retained.
Are both DNS queries and responses affected?
Yes. Message direction does not matter: both queries and responses can reach the recursive re-encoding path when processed by affected code.
What can be done if upgrading is not immediately possible?
Avoid re-encoding decoded messages from untrusted sources, or reject messages containing TSIG records outside the additional section before they reach signing or re-encoding logic. RFC 8945 section 5.2 requires messages with misplaced TSIG records to be dropped.
How severe can a successful trigger be in practice?
Each recursive cycle re-encodes the entire message, consuming memory until the process terminates. The provided data indicates that a wire message smaller than 100 bytes can exhaust available memory.