CVE-2026-28810
Predictable Transaction ID in Erlang/OTP inet_res Enables DNS Poisoning
Publication date: 2026-04-07
Last updated on: 2026-04-23
Assigner: EEF
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| erlang | erlang/otp | From 17.0 (inc) to 26.2.5.19 (exc) |
| erlang | erlang/otp | From 27.0 (inc) to 27.3.4.10 (exc) |
| erlang | erlang/otp | From 28.0 (inc) to 28.4.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-340 | The product uses a scheme that generates numbers or identifiers that are more predictable than required. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the Erlang/OTP built-in DNS resolver component called inet_res. It uses a sequential, process-global 16-bit transaction ID for UDP DNS queries without randomizing the source port. Because response validation relies almost entirely on this predictable transaction ID, an attacker who can observe a DNS query or predict the next transaction ID can perform DNS cache poisoning.
The vulnerability violates RFC 5452 recommendations, which advise using randomization to mitigate forged DNS answers. The inet_res resolver was intended only for trusted network environments with trusted recursive resolvers, but earlier documentation did not clearly state this, potentially leading to insecure deployments.
The issue affects Erlang/OTP versions from OTP 17.0 up to certain patched versions (26.2.5.19, 27.3.4.10, 28.4.2). The vulnerability allows attackers to inject forged DNS responses by exploiting the predictability of transaction IDs and lack of source port randomization.
How can this vulnerability impact me? :
This vulnerability can allow an attacker to perform DNS cache poisoning attacks against systems using the vulnerable Erlang/OTP DNS resolver. By predicting or observing the transaction ID, an attacker can inject forged DNS responses, causing the system to cache incorrect DNS information.
The impact includes unauthorized modification of DNS cache data, which can redirect users or services to malicious sites or servers. This compromises the integrity of DNS resolution but does not affect confidentiality or availability.
The vulnerability has a moderate severity with a CVSS v4 base score of 6.3, reflecting that it can be exploited remotely without privileges or user interaction but requires high attack complexity.
What immediate steps should I take to mitigate this vulnerability?
To mitigate the CVE-2026-28810 vulnerability, immediate steps include deploying Erlang nodes only within trusted network environments protected by firewalls.
Configure the inet_res DNS resolver to communicate exclusively with trusted recursive name servers to reduce the risk of DNS cache poisoning.
Apply available patches that improve the generation of strong random DNS transaction IDs and implement source port randomization for each DNS transaction, significantly reducing the risk of forged DNS replies.
Note that these mitigations do not protect against attackers who can observe DNS queries and responses on the network path.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in Erlang/OTP's built-in DNS resolver (inet_res) involves the generation of predictable transaction IDs and lack of source port randomization, which enables DNS cache poisoning attacks. This weakness conflicts with RFC 5452 recommendations for mitigating forged DNS answers, indicating a failure to meet established DNS security best practices.
While the CVE description and resources do not explicitly mention compliance with standards such as GDPR or HIPAA, the vulnerability's potential to allow unauthorized modification of DNS cache (impact on integrity) could indirectly affect compliance. For example, compromised DNS resolution might lead to data interception or redirection, which could violate data protection and security requirements under such regulations.
The advisory notes that inet_res is intended for trusted network environments and trusted recursive resolvers, and improper deployment outside these assumptions increases risk. Workarounds include restricting Erlang nodes to trusted networks and trusted DNS servers, which aligns with best practices for maintaining compliance with security controls required by regulations.
In summary, this vulnerability highlights a security weakness that could undermine the integrity of network communications, potentially impacting compliance with standards that require strong protections against unauthorized data modification and network attacks. However, no direct statements about GDPR, HIPAA, or other regulations are provided in the available information.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability arises from the Erlang/OTP built-in DNS resolver (inet_res) using predictable sequential 16-bit transaction IDs and lacking source port randomization for UDP DNS queries, making DNS cache poisoning feasible.
Detection involves verifying whether your Erlang/OTP environment is running a vulnerable version (OTP 17.0 up to versions before 26.2.5.19, 27.3.4.10, and 28.4.2) and whether the inet_res resolver is deployed in an untrusted network environment or communicating with untrusted recursive DNS servers.
To detect exploitation attempts or the vulnerability on your network or system, you can monitor DNS traffic for predictable transaction IDs and lack of source port randomization in UDP DNS queries originating from Erlang/OTP nodes.
Suggested commands for detection include using packet capture tools like tcpdump or Wireshark to inspect DNS query packets from your Erlang/OTP nodes:
- Capture DNS UDP queries on port 53 from the Erlang host: tcpdump -i <interface> udp port 53 and host <erlang_node_ip>
- Analyze captured packets in Wireshark to check if DNS transaction IDs are sequential or predictable rather than random.
- Check if source ports for DNS queries are fixed or predictable instead of randomized.
Additionally, verifying the Erlang/OTP version and patch level can be done by querying the OTP release version within the Erlang shell:
- erl -eval 'erlang:system_info(otp_release).' -noshell -s init stop
If the version is within the vulnerable range, and the deployment environment is untrusted or exposed to spoofed DNS responses, the system is at risk.
Note that the vulnerability is mitigated by patching Erlang/OTP to versions 26.2.5.19, 27.3.4.10, 28.4.2 or later, which implement strong random DNS transaction IDs and source port randomization.