Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1000 CNY

100.0%
Buy Us a Coffee

CWE-350 (不恰当地信任反向DNS) — Vulnerability Class 14

14 vulnerabilities classified as CWE-350 (不恰当地信任反向DNS). AI Chinese analysis included.

CWE-350 represents a critical authentication weakness where software relies on reverse DNS resolution to verify an entity’s identity for security-critical actions. Attackers typically exploit this by spoofing DNS responses or manipulating local DNS caches, allowing them to impersonate trusted hosts without possessing the corresponding IP address. Because DNS records are mutable and often lack robust cryptographic verification, an adversary can easily associate a malicious hostname with a legitimate IP, bypassing access controls. To mitigate this risk, developers must avoid using DNS names as sole authentication factors. Instead, they should implement mutual TLS with certificate validation, use static IP allowlists, or employ other cryptographic mechanisms that provide verifiable identity assurance, ensuring that security decisions are based on immutable credentials rather than easily manipulated network metadata.

MITRE CWE Description
The product performs reverse DNS resolution on an IP address to obtain the hostname and make a security decision, but it does not properly ensure that the IP address is truly associated with the hostname. Since DNS names can be easily spoofed or misreported, and it may be difficult for the product to detect if a trusted DNS server has been compromised, DNS names do not constitute a valid authentication mechanism. When the product performs a reverse DNS resolution for an IP address, if an attacker controls the DNS server for that IP address, then the attacker can cause the server to return an arbitrary hostname. As a result, the attacker may be able to bypass authentication, cause the wrong hostname to be recorded in log files to hide activities, or perform other attacks. Attackers can spoof DNS names by either (1) compromising a DNS server and modifying its records (sometimes called DNS cache poisoning), or (2) having legitimate control over a DNS server associated with their IP address.
Common Consequences (1)
Access ControlGain Privileges or Assume Identity, Bypass Protection Mechanism
Malicious users can fake authentication information by providing false DNS information.
Mitigations (2)
Architecture and DesignUse other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate.
ImplementationPerform proper forward and reverse DNS lookups to detect DNS spoofing.
Examples (2)
The following code samples use a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.
struct hostent *hp;struct in_addr myaddr; char* tHost = "trustme.example.com"; myaddr.s_addr=inet_addr(ip_addr_string); hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET); if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) { trusted = true; } else { trusted = false; }
Bad · C
String ip = request.getRemoteAddr(); InetAddress addr = InetAddress.getByName(ip); if (addr.getCanonicalHostName().endsWith("trustme.com")) { trusted = true; }
Bad · Java
In these examples, a connection is established if a request is made by a trusted host.
sd = socket(AF_INET, SOCK_DGRAM, 0); serv.sin_family = AF_INET; serv.sin_addr.s_addr = htonl(INADDR_ANY); servr.sin_port = htons(1008); bind(sd, (struct sockaddr *) & serv, sizeof(serv)); while (1) { memset(msg, 0x0, MAX_MSG); clilen = sizeof(cli); h=gethostbyname(inet_ntoa(cliAddr.sin_addr)); if (h->h_name==...) n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen); }
Bad · C
while(true) { DatagramPacket rp=new DatagramPacket(rData,rData.length); outSock.receive(rp); String in = new String(p.getData(),0, rp.getLength()); InetAddress IPAddress = rp.getAddress(); int port = rp.getPort(); if ((rp.getHostName()==...) & (in==...)) { out = secret.getBytes(); DatagramPacket sp =new DatagramPacket(out,out.length, IPAddress, port); outSock.send(sp); } }
Bad · Java
CVE IDTitleCVSSSeverityPublished
CVE-2026-6874 ericc-ch copilot-api Header token dns rebinding — copilot-api 4.3 Medium2026-04-22
CVE-2026-24281 Apache ZooKeeper: Reverse-DNS fallback enables hostname verification bypass in ZooKeeper ZKTrustManager — Apache ZooKeeper 7.4 -2026-03-07
CVE-2026-28271 Kiteworks Core is vulnerable to Server-Side Request Forgery (SSRF) — security-advisories 6.5 Medium2026-02-27
CVE-2026-1490 Spam protection, Honeypot, Anti-Spam by CleanTalk <= 6.71 - Authorization Bypass via Reverse DNS (PTR record) Spoofing to Unauthenticated Arbitrary Plugin Installation — Spam protection, Honeypot, Anti-Spam by CleanTalk 9.8 Critical2026-02-15
CVE-2025-59956 AgentAPI exposed user chat history via a DNS rebinding attack — agentapi 6.5 Medium2025-09-29
CVE-2025-59163 vet MCP Server SSE Transport DNS Rebinding Vulnerability — vet 4.3AIMediumAI2025-09-29
CVE-2024-53275 GHSL-2024-091: DNS rebinding attack in home-gallery — home-gallery 8.1 -2024-12-23
CVE-2024-42364 homepage DNS rebinding vulnerability (GHSL-2024-096) — homepage 6.5 Medium2024-08-23
CVE-2022-22364 IBM Cognos Controller security bypass — Cognos Controller 5.3 Medium2024-05-03
CVE-2021-34561 A vulnerability in WirelessHART-Gateway <= 3.0.8 allows to bypass any IP or firewall based access restrictions through DNS rebinding — WHA-GW-F2D2-0-AS- Z2-ETH 7.5 High2021-08-31
CVE-2021-22884 Nodejs 安全漏洞 — Node 8.1 -2021-03-03
CVE-2020-11091 Weave Net clusters susceptible to MitM attacks via IPv6 rogue router advertisements — Weave 5.8 Medium2020-06-03
CVE-2018-7160 Joyent Node.js inspector 安全漏洞 — Node.js 8.8 -2018-05-17
CVE-2017-0902 RubyGems 安全漏洞 — RubyGems 8.1 -2017-08-31

Vulnerabilities classified as CWE-350 (不恰当地信任反向DNS) represent 14 CVEs. The CWE taxonomy describes the weakness; review individual CVEs for product-specific impact.