cve.bz

CAPEC-142

DNS Cache Poisoning

High severityHigh likelihoodDetailed pattern

A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.

On this page

Ask an AI about this attack pattern

ChatGPTClaudeGoogle AI Mode

Show the promptExplain the attack pattern CAPEC-142: DNS Cache Poisoning: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/142.html and https://cve.bz/cve/capec/142?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.

Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.

How the attack unfolds

  1. Explore

    The attacker looks for a way in.

    1. [Explore resolver caches] Check DNS caches on local DNS server and client's browser with DNS cache enabled.

      2 techniques
      • Run tools that check the resolver cache in the memory to see if it contains a target DNS entry.
      • Figure out if the client's browser has DNS cache enabled.

  2. Experiment

    They probe what they found.

    1. [Attempt sending crafted records to DNS cache] A request is sent to the authoritative server for target website and wait for the iterative name resolver. An adversary sends bogus request to the DNS local server, and then floods responses that trick a DNS cache to remember malicious responses, which are wrong answers of DNS query.

      3 techniques
      • Adversary must know the transaction ID by intercepting a DNS query, or sending a bogus query with known transaction ID.
      • If the transaction ID used to identify each query instance is randomized in some new DNS software, the attack must guess the transaction ID. Slow the response of the real DNS server by causing Denial-of-service. This gives adversaries enough time to guess transaction
      • Adversary crafts DNS response with the same transaction ID as in the request. The adversary sends out DNS responses before the authorized DNS server. This forces DNS local cache stores fake DNS response (wrong answer). The fake DNS responses usually include a malicious website's IP address.

  3. Exploit

    They carry out the attack.

    1. [Redirect users to malicious website] As the adversary succeeds in exploiting the vulnerability, the victim connects to a malicious site using a good web site's domain name.

      2 techniques
      • Redirecting Web traffic to a site that looks enough like the original so as to not raise any suspicion.
      • Adversary-in-the-Middle (CAPEC-94) intercepts secure communication between two parties.

Prerequisites

  • A DNS cache must be vulnerable to some attack that allows the adversary to replace addresses in its lookup table.Client applications must trust the corrupted cashed values and utilize them for their domain name resolutions.

Skills required

  • Medium skill

    To overwrite/modify targeted DNS cache

Resources required

  • The adversary must have the resources to modify the targeted cache. In addition, in most cases the adversary will wish to host the sites to which users will be redirected, although in some cases redirecting to a third party site will accomplish the adversary's goals.

Mitigations

  • Configuration: Make sure your DNS servers have been updated to the latest versions

  • Configuration: UNIX services like rlogin, rsh/rcp, xhost, and nfs are all susceptible to wrong information being held in a cache. Care should be taken with these services so they do not rely upon DNS caches that have been exposed to the Internet.

  • Configuration: Disable client side DNS caching.

Weaknesses it exploits

  • CWE-345 Insufficient Verification of Data Authenticity
  • CWE-346 Origin Validation Error
  • CWE-348 Use of Less Trusted Source
  • CWE-349 Acceptance of Extraneous Untrusted Data With Trusted Data
  • CWE-350 Reliance on Reverse DNS Resolution for a Security-Critical Action

Recent CVEs with these weaknesses

  1. 8.1CVE-2026-108187

    Origin Validation Error in Zoom Workplace for Windows may allow an unauthenticated user to conduct an escalation of privilege via network access.

  2. 7.4CVE-2026-120999

    Improper Authentication vulnerability in Google sign-in and email confirmation in nerves-hub nerves_hub_web allows an attacker who registers another person's email address to share that person's account once they sign in. NervesHub.Account…

  3. 8.1CVE-2026-123802

    SuperTokens Core is an open source authentication server. From 11.3.0 until 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, a licensed deployment with a configured SAML client can authenticate an identity from an assertion that did no…

  4. 7.4CVE-2026-123801

    SuperTokens Core is an open source authentication server. From 11.3.0 until 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, SAML.handleCallback does not consume RelayState, record assertion identifiers, or enforce Response.InResponseT…

  5. 8.1CVE-2026-115338

    Insufficient protection of communications in Progress WS_FTP Server versions prior to 2025.0.5 could allow a network attacker to intercept sensitive information or modify requests when unencrypted connections are used.

  6. 6.3CVE-2026-124249

    http.cookiejar.CookieJar deleted a stored cookie when a response carried an already expired Set-Cookie header for it, using the Domain and Path attributes from the header without consulting the cookie policy. A server could therefore delet…

  7. 6.3CVE-2026-123599

    Hickory DNS hickory-proto before 0.26.0-beta.1 and hickory-net before 0.26.2 contain a DNSSEC validation bypass because verify_rrsets() ignores DNS class when partitioning RRsets, so non-IN records skip signature verification yet are marke…

  8. 8.7CVE-2026-123596

    Hickory DNS hickory-proto through 0.26.0-alpha.1 and hickory-net 0.26.0-beta.1 before 0.26.2 contain a DNSSEC validation flaw in the validating recursor's NSEC handler that accepts parent-side ancestor-delegation NSEC records as proof of n…

The newest records naming one of them. Each weakness's page lists them all.

Part of
Can lead to

Examples

In this example, an adversary sends request to a local DNS server to look up www.example .com. The associated…

In this example, an adversary sends request to a local DNS server to look up www.example .com. The associated IP address of www.example.com is 1.3.5.7.

Local DNS usually caches IP addresses and do not go to remote DNS every time. Since the local record is not found, DNS server tries to connect to remote DNS for queries. However, before the remote DNS returns the right IP address 1.3.5.7, the adversary floods local DNS with crafted responses with IP address 2.4.6.8. The result is that 2.4.6.8 is stored in DNS cache. Meanwhile, 2.4.6.8 is associated with a malicious website www.maliciousexampsle.com

When users connect to www.example.com, the local DNS will direct it to www.maliciousexample.com, this works as part of a Pharming attack.

MITRE's words, unchanged: CAPEC-142 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.