CVE-2026-102552 in FreeRTOS-Plus-TCP
Summary
by MITRE • 10/16/2026
Improper verification of the source of a communication channel in the DNS resolver in Amazon FreeRTOS-Plus-TCP before V4.4.2 might allow remote third-party to insert a chosen address into the device's DNS cache via a forged DNS reply.
To remediate this issue, users should upgrade to version V4.4.2 and enable ipconfigDNS_CHECK_REPLY_SOURCE_IP.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in Amazon FreeRTOS-Plus-TCP prior to version 4.4.2 represents a critical flaw in the DNS resolver implementation, specifically categorized under CWE-345: Improper Verification of Cryptographic Signature or CWE-287: Improper Authentication when applied to network protocol validation. This issue stems from an insufficient verification mechanism regarding the source identity of incoming communication channels within the Domain Name System resolution process. In a standard TCP/IP stack operating on embedded devices, the DNS resolver is responsible for translating human-readable domain names into IP addresses required for network connectivity. The security architecture relies heavily on the assumption that responses received are legitimate and originate from trusted resolvers or authoritative servers. However, in this specific implementation, the library failed to rigorously validate whether the source Internet Protocol address of a returned DNS packet matched the expected destination or utilized transaction ID matching with sufficient entropy checks against spoofed sources. This architectural oversight allows an attacker positioned on the local network segment to exploit the trust relationship inherent in UDP-based DNS queries by injecting malicious responses before legitimate ones arrive, effectively performing a cache poisoning attack.
From an operational perspective, this vulnerability enables remote third-party actors to perform DNS cache poisoning attacks without requiring authentication or prior compromise of any device credentials. By sending forged DNS replies that appear valid due to the lack of strict source IP verification in older versions, an attacker can insert chosen malicious addresses into the device's local DNS cache. Once these false entries are cached, subsequent requests for specific domains will resolve to the attacker-controlled IP addresses rather than the intended legitimate servers. This manipulation facilitates a range of downstream attacks including man-in-the-middle scenarios where sensitive data such as credentials or proprietary information is intercepted during transmission. It also allows for phishing campaigns by redirecting users to counterfeit websites that mimic trusted services, thereby compromising user trust and potentially leading to further system compromise through malicious downloads hosted on the spoofed sites. The impact is particularly severe in IoT environments because these devices often operate with limited security controls and may have persistent connections to cloud backends or internal infrastructure, making them high-value targets for lateral movement within a network.
The technical root cause lies in the handling of UDP packets where stateful tracking of transaction identifiers was either absent or insufficiently enforced against source IP spoofing techniques common in local area networks. Attackers can easily craft DNS response packets with forged source addresses that mimic legitimate resolvers, exploiting the fact that many embedded systems do not implement strict return-route validation for every single query-response pair unless explicitly configured to do so. This aligns closely with MITRE ATT&CK technique T1498: Network Denial of Service or more specifically T1071 Application Layer Protocol if used for command and control, but primarily falls under DNS hijacking behaviors described in techniques related to cache poisoning such as those seen in historical exploits like Kamikaze or Dnspooq. The absence of source IP verification means the resolver accepts any response that matches the transaction ID regardless of whether it came from a trusted network path, violating fundamental principles of secure communication channel validation defined in industry standards for embedded networking stacks.
To remediate this vulnerability and restore integrity to DNS resolution processes, users must upgrade their Amazon FreeRTOS-Plus-TCP library to version V4.4.2 or later. This updated release incorporates enhanced logic that validates the source IP address of incoming DNS responses against expected values, ensuring that only packets originating from authorized resolvers are accepted into the cache. Additionally, it is strongly recommended to explicitly enable the configuration parameter ipconfigDNS_CHECK_REPLY_SOURCE_IP within the network interface settings. Enabling this flag forces the stack to perform strict verification checks on every received DNS reply, comparing its source address against known good addresses or expected resolver IPs before processing and caching the result. This mitigation effectively neutralizes cache poisoning attempts by dropping forged packets that do not originate from legitimate sources. Organizations deploying FreeRTOS-based devices should audit their deployment pipelines to ensure this patch is applied across all affected firmware images and consider implementing additional network-level protections such as DNSSEC validation where supported, or restricting outbound UDP port 53 traffic via firewall rules to further reduce the attack surface available to local adversaries.