CVE-2026-80213: Medium severity rubygems/resolv vulnerability

Published Aug 27, 2026
·
Updated

An issue was discovered in the resolv gem before 0.7.2 for Ruby. Resolv::DNS::MessageEncoder wrote a DNS label's length into a single octet without checking its range. A label longer than 255 octets had its length stored modulo 256 but the label data was written unchanged, and thus the bytes on the wire described a different name than the one the application asked to encode. RFC 1035 section 2.3.4 limits a label to 63 octets, and the two high bits of the length octet are reserved for compression pointers. putstring packed the length with putpack("C", d.length) and putlabel used it for labels, and thus any value from 0 to 255 could end up as a label length octet, including the reserved 0x40-0xBF range and the 0xC0-0xFF pointer range. Resolv::DNS::Name.create did not check per-label or total name length either, and thus an attacker-controlled hostname reached the encoder unchanged. An application that resolves an attacker-controlled hostname sends a query whose wire bytes name a domain the attacker chose. A hostname suffix that the application validates against an allowlist becomes padding that never appears on the wire, and thus allowlist and egress checks can be bypassed. The recursive resolver caches the response under the attacker's name, and DNS logs record that name rather than the one the application asked for. A label length whose low octet lands in the 0xC0-0xFF range produces a length octet that conforming parsers read as the start of a compression pointer, with the following attacker-controlled byte as the offset.

Affected Software

1 affected component
rubygems/resolv<0.7.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade resolv to a version that resolves this vulnerability.

    Fixed in 0.7.2
  2. Configuration

    Modify/ensure Resolv::DNS::MessageEncoder does not write a DNS label length into a single octet without checking its range; enforce RFC 1035 label size limits (63 octets) so the length octet never uses the compression-pointer-reserved 0x40-0xBF and 0xC0-0xFF ranges.

    Resolv::DNS::MessageEncoder DNS label length validation = Check per-label length (<= 63 octets) and ensure length octet reserved bits are not used
  3. Configuration

    Modify/ensure Resolv::DNS::Name.create checks per-label and total name length so attacker-controlled hostnames do not reach the encoder unchanged with out-of-range label lengths.

    Resolv::DNS::Name.create per-label and total name length validation = Validate per-label <=63 octets and total name length
  4. Compensating control

    After upgrading, review/monitor DNS recursive resolver behavior to ensure responses are cached/logged under the application-requested domain name (not an attacker-chosen name), since the recursive resolver caches under the attacker’s name and logs that name.

Event History

Aug 27, 2026
CVE Published
via MITRE·02:22 PM
Data Sourced
via MITRE·02:22 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·05:20 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which applications are exposed to this issue?

Applications using the resolv gem before 0.7.2 are exposed when they pass an attacker-controlled hostname to DNS resolution. The relevant path is Resolv::DNS::MessageEncoder encoding that hostname into a DNS query.

2

What does an attacker need to exploit the issue?

An attacker needs to control a hostname that the application will attempt to resolve. By supplying a label longer than 255 octets, the attacker can cause the encoded DNS query to describe a different domain name from the hostname the application processed.

3

Can hostname allowlists or DNS egress controls be bypassed?

Yes. A validated hostname suffix can become padding that is not present in the DNS wire representation, allowing a query for an attacker-chosen domain despite an application-side suffix allowlist or egress check.

4

What can be done before updating?

Reject DNS labels longer than 63 octets before they reach resolution, consistent with RFC 1035. Do not rely solely on suffix validation where attacker-controlled hostnames can be resolved; ensure the name permitted by policy is the name sent in the DNS request.

5

How can teams assess whether they are affected?

Check whether the application uses a resolv gem version before 0.7.2 and whether any untrusted input can influence hostnames submitted for DNS resolution. Pay particular attention to controls that validate hostnames by appending or checking an allowlisted suffix.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203