CVE-2026-80213

Executive Summary

CVE-2026-80213 is a DNS message encoding flaw in the Ruby resolv gem prior to version 0.7.2 that permits an attacker-controlled hostname to be encoded onto the wire in a manner inconsistent with the intended name. The vulnerability arises from insufficient length validation in the Resolv::DNS::MessageEncoder and Resolv::DNS::Name.create classes, allowing a label longer than 255 octets to have its length truncated modulo 256 while the label data is written unchanged. This discrepancy enables allowlist and egress-check bypasses because a hostname suffix validated by the application can become padding that never appears on the wire, while the recursive resolver and DNS logs record a different, attacker-chosen name.

The CVSS score is 4.0 (Medium) with a vector of CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N, indicating low impact on integrity with no confidentiality or availability impact, though the scope is changed. No public exploit code or PoC exists, and no patch evidence has been tracked beyond the gem version 0.7.2 release. The flaw is classified under CWE-197 (Numeric Truncation Error) and is not present on the CISA KEV list.

Technical Analysis

The vulnerability resides in the resolv gem's DNS message encoding logic, which is responsible for serializing DNS query messages before transmission. The core issue is a numeric truncation error (CWE-197) affecting DNS label length handling.

In RFC 1035 (Section 2.3.4), DNS labels are limited to 63 octets. The length octet in a DNS message also has its two high bits reserved for compression pointer encoding (0xC0-0xFF range indicates a pointer, 0x40-0xBF is reserved/unused). The Resolv::DNS::MessageEncoder class in the resolv gem fails to enforce these constraints.

Specifically, put_string calls put_pack("C", d.length) which packs the length into a single unsigned octet. When a label's length exceeds 255 octets, the length value is truncated modulo 256. For example, a label of length 300 would be encoded with a length byte of 44 (300 mod 256 = 44), but the actual label data (300 bytes) would be written unchanged. This creates a wire format where the declared length does not match the actual data, and a conforming DNS parser would interpret only the first N bytes (where N is the truncated length value) as the label, leaving the remainder as malformed or misinterpreted data.

More critically, a label length in the range 256-319 would have its truncated low octet fall into the 0x00-0x3F range (normal label length), while lengths 320-383 would produce a low octet in the 0x40-0xBF reserved range, and lengths 384-447 would produce a low octet in the 0xC0-0xFF range that conforming parsers interpret as a compression pointer. Per the NVD description, a length octet in the 0xC0-0xFF range would cause parsers to read the next two bytes (the first bytes of the label data itself) as a pointer offset, resulting in the parser following a bogus compression pointer.

The Resolv::DNS::Name.create method does not validate per-label or total name length, meaning an attacker-controlled hostname is passed to the encoder unchanged. An application that resolves an attacker-controlled hostname — for instance, in a web application that performs DNS lookups on user-supplied domain names — will generate a query whose wire-format name differs from the requested name.

The security impact is threefold:

1. Allowlist bypass: If an application validates a hostname suffix against an allowlist, an attacker can append a long padding string to a disallowed domain. The application's validation sees the padded hostname as conforming (the disallowed domain has a valid suffix appended), but the wire-format DNS query contains a different name (the original disallowed domain plus a truncated portion of the padding). For example, a hostname such as evil.com[300-byte padding].allowed-domain.com would be validated as part of allowed-domain.com, but on the wire, the label evil.com might be completely consumed within a single suffixed label that the resolver interprets as a different name.

2. Log poisoning: DNS logs record the attacker-chosen name, not the application-intended name, enabling an attacker to manipulate audit trails and forensic evidence.

3. Cache poisoning at the resolver: The recursive resolver caches the response under the attacker's chosen name, meaning subsequent resolution attempts may return attacker-controlled data for names the application never intended to query.

The attack requires the ability to supply an attacker-controlled hostname to an application using the vulnerable gem — a prerequisite that elevates the attack complexity (AC:H in the CVSS vector). The impact is limited to low integrity compromise (C:N/I:L/A:N) with changed scope (S:C), meaning the compromised component is different from the impacted system.

Exploitation Scenarios

Scenario 1 — Malicious DNS Query with Long Label

1. Reconnaissance: An attacker identifies a target application that performs DNS resolution on user-supplied domain names, such as a URL expansion service, a domain scanner, a mail server with custom lookup features, or a service that validates domain reputation.

2. Trigger: The attacker submits a hostname containing a label longer than 255 octets. For example, a crafted hostname string that passes application-level validation (e.g., a length check that only inspects the first few characters or suffixes).

3. Payload: The attacker constructs a hostname with a long label such that the low octet of its length falls into a desirable range. If the length low octet is in the 0x00-0x3F range, the wire message contains a truncated name. If it lands in 0xC0-0xFF, the wire message contains a compression pointer that points into the label data itself.

4. Post-exploitation: The recursive resolver caches the response under the attacker-chosen name. DNS logs record this name rather than the application's intended name. If the application validates an allowlist suffix, the attack can bypass that check because the padded bytes never appear on the wire. The attacker may subsequently direct the application to resolve domains outside its allowed scope, enabling data exfiltration channels or resource abuse.

Scenario 2 — Allowlist Bypass for Egress Filtering

1. Reconnaissance: An organization deploys a DNS-based egress filter or allowlist that only permits queries to internal domains (e.g., *.corp.example) and rejects queries to external domains.

2. Trigger: An attacker controlling a hostname input to a vulnerable Ruby application submits malicious.com[200 bytes of padding].corp.example. The application's allowlist check sees a hostname ending in .corp.example and permits the query.

3. Payload: The first label (malicious.com plus most of the padding) has a total length that, when encoded, produces a wire-format name where malicious.com is misparsed or where the label length byte is misinterpreted. Depending on the length output, the resolver queries a name that the attacker controls or that is otherwise distinct from *.corp.example.

4. Post-exploitation: The attacker's domain receives a DNS query from the internal resolver, confirming active code execution or network connectivity. The attacker can use this to establish a covert DNS channel or to bypass network perimeter allowlists.

Important note: No public PoC or exploit code exists for this CVE. The attack chain is inferred from the vulnerability class (numeric truncation in DNS label encoding) and the NVD description. Specific label lengths, padding sizes, and exact wire-format outcomes require testing against a patched or unpatched instance; insufficient technical detail is available in public sources to provide byte-exact exploit construction.

Impact Assessment

Business Impact: The primary impact is an integrity breach of DNS query generation logic. An application using the vulnerable resolv gem may issue DNS queries for domains that were not intended, bypassing allowlist or egress controls. This could lead to:

• Compliance violations: If an organization maintains a strict network perimeter with DNS allowlists (e.g., for payment card environments or regulated data), this flaw permits circumvention.
• DNS log poisoning: Forensic analysis and incident response are impaired because DNS logs contain attacker-chosen names rather than application-generated names.
• Cache poisoning: The recursive resolver caches responses under attacker-controlled names, potentially serving incorrect data to other clients or applications that subsequently query those names.

Affected Systems: Any Ruby application using resolv gem versions prior to 0.7.2 that performs DNS resolution on untrusted, user-supplied hostnames. This includes but is not limited to web applications, email gateways, URL validation services, and custom network monitoring tools.

Blast Radius: The CVSS vector indicates Changed scope (S:C) — meaning the vulnerable component is in one security scope, but the impacted component is in another (e.g., the application is a client in one trust boundary, while the DNS resolver and network egress controls are in another). However, the low CVSS score (4.0) reflects the high attack complexity and the limited direct impact. There is no confidentiality (C:N) or availability (A:N) impact, and the integrity impact is low (I:L). No exploit in the wild has been reported.

Detection Guidance

Sigma Rule

title: Potential DNS Label Length Anomaly from Ruby resolv Gem
id: 7f8a3c2d-4b9e-4a5f-9d4c-2e6f1a8b3c5d
status: experimental
description: Detects DNS query names with labels exceeding 63 octets or messages where the name length does not match the wire encoding, indicative of CVE-2026-80213 exploitation.
author: Valters IT Security
date: 2026/05/20
logsource:
  category: dns_query
  product: windows
  definition: 'Requires logging of raw DNS query names'
detection:
  selection_label_length:
    query:
      - trailing ' label_length > 63
  selection_query_length:
    query:
      - trailing ' len(query_name) > 255
  condition: selection_label_length or selection_query_length
falsepositives:
  - Legitimate DNS queries with unusually long labels (rare but possible)
  - Partial or truncated DNS logging
level: medium
tags:
  - attack.t1190
  - cve.2026-80213

YARA Rule

rule CVE_2026_80213_Ruby_Resolv_DNS_Label_Truncation
{
    meta:
        author = "Valters IT Security"
        date = "2026-05-20"
        description = "Detects Ruby resolv gem source code patterns vulnerable to DNS label length truncation (CVE-2026-80213)"
        cve = "CVE-2026-80213"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-80213"
    strings:
        $put_string = "put_pack(\"C\", d.length)" ascii
        $put_label = "put_label" ascii
        $name_create = "Name.create" ascii
        $push_label = "push(label)" ascii
        $label_length = "label.length" ascii
    condition:
        ($put_string or $put_label) and ($name_create or $push_label) and $label_length
}

Suricata IDS Rule

alert dns any any -> any any (msg:"CVE-2026-80213 - Ruby resolv gem DNS label length overflow attempt"; dns_query; content:"|c0|"; offset:12; depth:1; content:"|ff|"; offset:13; depth:1; classtype:attempted-information-leak; sid:202680213; rev:1; metadata:created_at 2026_05_20, updated_at 2026_05_20, cve CVE_2026_80213;)

Note: This rule looks for DNS query messages where the first byte after the header (the query name length octet at offset 12) is in the 0xC0-0xFF range — indicating a compression pointer at the start of the query name, which is abnormal and consistent with the truncation attack. Also alerts on 0x00-0x3F length bytes that precede oversized label data.

Elastic Detection

// EQL query to detect DNS queries with abnormally long names or suspicious name structure
sequence by host.id with maxspan=5m
  [ network where event.action == "lookup" and dns.question.name_len > 255 ]
  [ file where event.action == "read" and file.path contains "resolv" ]

Or a simpler detection:

network where event.category == "network" and network.protocol == "dns" 
and dns.question.name_len > 255 
or (dns.question.name contains "\u0000" and len(dns.question.name) < 511)

Splunk SPL Query

index=dns sourcetype=dns_query
| eval qname_len = len(query_name)
| where qname_len > 255
| eval suspicious = case(substr(query_name, 1, 1) >= "\xC0" and substr(query_name, 1, 1) <= "\xFF", "compression_pointer_at_start",
                          substr(query_name, 1, 1) >= "\x40" and substr(query_name, 1, 1) <= "\xBF", "reserved_length",
                          true, "long_label")
| where suspicious != "long_label"
| table _time, src_ip, dest_ip, query_name, suspicious
| sort -_time

Or a simpler variant:

index=dns query_name_length>255 
| stats count by src_ip, dest_ip, query_name 
| where count > 5

Wazuh OSSEC Rule

<group name="dns,">
  <rule id="100213" level="10">
    <decoded_as>dns</decoded_as>
    <field name="query_length">>255</field>
    <description>DNS query with label length exceeding 255 octets - possible CVE-2026-80213 exploitation</description>
    <group>dns_anomaly,attack.t1190,cve.2026-80213</group>
    <info type="cve">CVE-2026-80213</info>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED (no patch evidence from tracked sources)

1. Immediate Mitigations:

   • Upgrade: The only known remediation is to upgrade the resolv gem to version 0.7.2 or later. Verify the gem version with gem list resolv and update via gem update resolv or by adding gem 'resolv', '>= 0.7.2' to the Gemfile.
   • Input validation: Implement application-level validation of hostnames before passing them to DNS resolution. Reject hostnames with any label exceeding 63 octets or total name length exceeding 253 octets (per RFC 1035). This can be implemented as a defensive check independent of the gem fix.
   • Network monitoring: Deploy detection rules (see Detection Guidance above) to alert on DNS queries with abnormal label lengths or anomalous query name structures.
   • Egress DNS filtering: Configure recursive resolvers and firewalls to log and block DNS queries where the total name length exceeds 253 octets or any label exceeds 63 octets.

2. Patch/Upgrade Steps:

   • Check current gem version: ruby -e "require 'resolv'; puts Resolv::DNS::VERSION" (or equivalent).
   • Update: gem update resolv or if using Bundler, update the Gemfile and run bundle update resolv.
   • Restart all Ruby services that load the resolv gem.
   • Verify the update by re-running the version check and confirming a version >= 0.7.2.

3. Long-Term Hardening:

   • Defense in depth: Implement a DNS allowlist at the resolver level (e.g., using RPZ — Response Policy Zones) that rejects queries to unauthorized domains regardless of how the application encodes them.
   • Input sanitization: Treat all user-supplied hostnames as untrusted. Validate against strict regex patterns that enforce RFC 1035 label length limits before any DNS resolution is attempted.
   • Dependency management: Implement a policy for regular updates of all Ruby gems, especially network-facing components like resolv.
   • Runtime monitoring: Deploy anomaly detection on DNS query patterns that alerts on label lengths, character sets, and encoded bytes that deviate from normal application behavior.
   • Security testing: Include DNS fuzzing in application security tests, specifically testing label lengths from 1 to 1000 octets, to catch similar truncation flaws in other components.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-80213 (official NVD vulnerability record with CVSS scoring)
2. RFC 1035 — Domain Names — Implementation and Specification: https://www.rfc-editor.org/rfc/rfc1035 (Section 2.3.4 defines the 63-octet label limit and the reserved bits of the length octet)
3. Ruby Gems — resolv: https://rubygems.org/gems/resolv (gem page with version history; version 0.7.2 is the patched version)
4. CWE-197 — Numeric Truncation Error: https://cwe.mitre.org/data/definitions/197.html (vulnerability class reference)
5. MITRE ATT&CK — T1190: https://attack.mitre.org/techniques/T1190/ (exploit public-facing application tactic mapping)

Threat Actor Campaigns: No known threat actor campaigns or exploit-in-the-wild evidence have been reported for CVE-2026-80213 as of the publication date. The vulnerability is not present on the CISA Known Exploited Vulnerabilities (KEV) list. The CNA title field was empty in the provided data, and no vendor advisory beyond the gem version release has been published.