Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-27T17:20:50.880Z",
  "pubdate": "2026-08-27T17:20:50.880Z",
  "executiveSummary": "The Ruby resolv gem is susceptible to an uncontrolled memory consumption vulnerability caused by the improper caching of dynamically generated classes during DNS response decoding.\nThis vulnerability is classified as a Denial of Service (DoS) risk, as an attacker can induce arbitrary memory growth by providing crafted DNS responses containing unknown resource record types or SvcParamKey values.\nThe flaw affects the resolv gem in versions prior to 0.7.2, which is bundled by default in Ruby installations.\nExploitation requires the attacker to influence DNS traffic, such as through DNS spoofing, hijacking, or via a malicious upstream DNS server, to force the application to process specifically structured responses.\nBecause the dynamically generated classes are stored as permanent constants and within lookup tables, they are not eligible for garbage collection, leading to unbounded memory accumulation.\nSuccessful exploitation results in process termination due to memory exhaustion, impacting service availability for any Ruby application utilizing resolv for DNS message decoding.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of class generation within Resolv::DNS::Resource.get_class, Resolv::DNS::Resource::Generic.create, and Resolv::DNS::SvcParam::Generic.create. When the decoder encounters an unknown DNS resource record type-class pair or an unknown SvcParamKey, the gem dynamically creates a new class to represent this entity.\nThese dynamically generated classes are subsequently registered as constants under the Resource or SvcParam::Generic namespaces and simultaneously added to an internal class-lookup hash (ClassHash).\nIn Ruby, assigning a class to a constant ensures that the class object remains reachable and thus ineligible for garbage collection. Consequently, each unique (type, class) pair or SvcParamKey introduced in a malicious DNS response results in a permanent addition to the process's memory footprint.\nThe attack flow proceeds as follows: An attacker intercepts or influences the DNS resolution process for a target Ruby application. The attacker sends a crafted DNS response containing thousands of distinct, unrecognized DNS resource record types or SvcParamKeys. When the application calls Resolv::DNS::Message.decode, the decoder iterates through these records. For every unknown entry, the vulnerable functions generate a new class and perform the permanent registration described above. Because the DNS protocol allows for 16-bit values for both type and class, there are 2^32 potential combinations, providing a vast space for the attacker to generate unique, memory-consuming entries.\nA single malicious response of a few hundred kilobytes can cause the application process to consume tens of megabytes of additional memory. Repeatedly sending such payloads causes the process memory to grow without bound until the host system triggers an Out-of-Memory (OOM) kill or the application crashes, resulting in a denial of service.\nThis vulnerability is particularly critical as it resides in a default gem, meaning nearly all standard Ruby environments are exposed if they perform DNS lookups on untrusted or potentially compromised network paths. No specific authentication or high-level privileges are required, as the vulnerability is triggered by the standard processing of DNS traffic."
}