CVE-2026-80212 in Resolv
Summary
by MITRE • 08/27/2026
An issue was discovered in the resolv gem before 0.7.2 for Ruby. Resolv::DNS::Resource.get_class, Resolv::DNS::Resource::Generic.create, and Resolv::DNS::SvcParam::Generic.create generate a new class for each unknown DNS resource record (type, class) pair, or each unknown SvcParamKey, encountered while decoding a response. Each generated class was permanently registered both as a constant on Resource (or SvcParam::Generic) and as an entry in a class-lookup hash (ClassHash), and thus the class remained reachable through that constant after the response was discarded. Type and class are each 16-bit values, and thus an attacker controlling DNS responses (a spoofed response, or a malicious or hijacked upstream DNS server) has roughly 2^32 distinct (type, class) pairs to choose from. A single response of a few hundred kilobytes carrying tens of thousands of distinct unknown types permanently grows process memory by tens of megabytes; repeated responses accumulate without bound and are never reclaimed by garbage collection, because the constant keeps each class alive. Any code path that calls Resolv::DNS::Message.decode on attacker-influenced DNS responses is affected. resolv is a default gem, and thus this is reachable from a plain Ruby installation without any additional dependency.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in the resolv gem prior to version 0.7.2 represents a critical resource exhaustion flaw rooted in improper memory management during the parsing of Domain Name System responses. The core technical defect lies within three specific methods: Resolv::DNS::Resource.get_class, Resolv::DNS::Resource::Generic.create, and Resolv::DNS::SvcParam::Generic.create. When these methods encounter DNS resource record types or SvcParamKeys that are not natively recognized by the library, they dynamically generate a new Ruby class to handle the unknown data structure. This dynamic generation is intended as a mechanism for handling arbitrary data formats, but it fails to implement any form of caching limit or garbage collection trigger for these transient objects. Instead, each newly generated class is permanently registered as a constant on either the Resource or SvcParam::Generic namespace and simultaneously inserted into an internal class-lookup hash known as ClassHash. This dual registration ensures that the classes remain strongly referenced within the Ruby runtime environment long after the initial DNS response packet has been processed and discarded by the application logic.
The operational impact of this design flaw is severe, leading to unbounded memory growth in any process that utilizes the resolv gem for DNS resolution against potentially malicious or compromised upstream servers. Because both the type and class fields in a DNS header are 16-bit values, an attacker has approximately four billion distinct combinations available to exploit. By sending a single large DNS response containing tens of thousands of unique unknown record types, an attacker can force the Ruby process to allocate tens of megabytes of memory for these unused classes. Since each generated class is held alive by its constant reference and hash entry, they are never eligible for garbage collection. Consequently, repeated interactions with such malicious responses result in cumulative memory leakage that continues without bound until the application crashes due to out-of-memory conditions or consumes all available system resources. This constitutes a classic denial of service scenario where an attacker can remotely exhaust server-side memory simply by influencing DNS resolution outcomes.
From a threat modeling perspective, this vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, and specifically relates to CWE-787, as the persistent allocation of objects in heap space without release leads to state corruption or system instability over time. In terms of attack vectors, it falls under MITRE ATT&CK technique T1496, Resource Hijacking, where an adversary uses computing resources for their own benefit, here manifesting as a denial-of-service through memory exhaustion rather than cryptographic mining. The risk is amplified by the fact that resolv is included in standard Ruby installations, meaning applications do not need to install additional third-party dependencies to be vulnerable. Any code path invoking Resolv::DNS::Message.decode on data derived from untrusted or spoofed DNS responses is directly susceptible to this exploitation.
Mitigation strategies must focus on preventing the permanent registration of these dynamic classes and enforcing limits on class generation. The primary remediation involves upgrading to resolv gem version 0.7.2 or later, where the developers have addressed the memory leak by ensuring that dynamically generated classes are not permanently retained in global namespaces when they represent unknown record types. For environments unable to upgrade immediately, defensive coding practices should be implemented to limit the number of DNS queries issued per request cycle and to implement timeouts for DNS resolution operations. Additionally, running Ruby applications with strict memory limits via containerization or process managers can help contain the blast radius if an attack occurs. It is also advisable to validate DNS responses against expected schemas where possible, although this may not be feasible in all general-purpose resolver scenarios due to the open nature of the DNS protocol.