CVE-2025-11678: libwebsockets Buffer Overflow Vulnerability

CVE-2025-11678 Overview

CVE-2025-11678 is a stack-based buffer overflow [CWE-121] in the lws_adns_parse_label function of warmcat libwebsockets. The flaw affects builds compiled with the LWS_WITH_SYS_ASYNC_DNS flag enabled. An attacker positioned on an adjacent network can sniff outgoing Domain Name System (DNS) requests and craft a forged response with a matching transaction ID. When the response contains a label longer than the maximum allowed size, the parser overflows the label_stack buffer on the stack.

Successful exploitation can corrupt stack memory, leading to denial of service or arbitrary code execution in applications that embed libwebsockets.

Critical Impact
Adjacent-network attackers can spoof DNS responses to overflow stack memory in any application using libwebsockets with async DNS, enabling code execution or process crashes.

Affected Products

warmcat libwebsockets compiled with LWS_WITH_SYS_ASYNC_DNS enabled
Applications and embedded systems linking libwebsockets with async DNS support
Versions prior to the upstream fix in commit 2bb9598562b37c942ba5b04bcde3f7fdf66a9d3a

Discovery Timeline

2025-10-20 - CVE-2025-11678 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-11678

Vulnerability Analysis

The vulnerability resides in lws_adns_parse_label, the routine responsible for parsing DNS labels inside asynchronous DNS responses. DNS labels are length-prefixed segments of a domain name, each capped at 63 bytes by RFC 1035. The parser writes label bytes into a fixed-size stack buffer called label_stack without sufficiently validating that the cumulative label length stays within the buffer bounds.

When a forged response contains a label longer than the maximum supported size, the function writes past the end of label_stack, corrupting adjacent stack memory. This includes saved frame pointers and return addresses, providing an avenue for control-flow hijacking.

The attack requires adjacent-network access because the adversary must observe the outgoing DNS query to learn the transaction ID, source port, and destination resolver. With those values, the attacker races the legitimate resolver and delivers a malicious response that the client accepts.

Root Cause

The root cause is missing or insufficient bounds enforcement during label decompression and copying in lws_adns_parse_label. The function trusts attacker-influenced length fields from the wire and copies bytes into a fixed stack buffer. The upstream fix in commit 2bb9598562b37c942ba5b04bcde3f7fdf66a9d3a adds length validation to prevent writes beyond label_stack.

Attack Vector

Exploitation requires the attacker to share an adjacent network segment with the victim, such as the same Wi-Fi network, VLAN, or broadcast domain. The attacker passively captures outgoing DNS requests, extracts the 16-bit transaction ID, and sends a spoofed UDP response from the resolver address before the legitimate reply arrives. The response includes a malformed compressed label whose decoded length exceeds the label_stack buffer. The CVSS 4.0 vector indicates the attack also requires passive user interaction to trigger the vulnerable DNS resolution path.

No verified public proof-of-concept code is available. The vulnerability mechanism is described in the Nozomi Networks CVE-2025-11678 Advisory and the upstream libwebsockets Commit Update.

Detection Methods for CVE-2025-11678

Indicators of Compromise

Unexpected crashes or stack canary violations in processes linking libwebsockets with async DNS enabled
DNS responses arriving from unexpected source addresses or before the configured upstream resolver replies
DNS answer payloads containing label length fields larger than 63 bytes or producing decoded names beyond 255 bytes
Duplicate DNS responses for a single outstanding transaction ID on the local segment

Detection Strategies

Inspect DNS traffic for malformed label length octets and oversized compressed names using network intrusion detection signatures
Monitor for libwebsockets-based applications terminating with SIGSEGV or stack-smashing protector aborts in system logs
Enable AddressSanitizer or compiler stack protectors during testing to surface overflow conditions before deployment

Monitoring Recommendations

Collect endpoint telemetry on application crashes and link it to network DNS activity for correlation
Track DNS query and response pairs at the network edge to identify spoofing attempts on adjacent networks
Audit firmware and software bills of materials (SBOM) to inventory devices shipping libwebsockets with LWS_WITH_SYS_ASYNC_DNS

How to Mitigate CVE-2025-11678

Immediate Actions Required

Update libwebsockets to a build that includes commit 2bb9598562b37c942ba5b04bcde3f7fdf66a9d3a and rebuild dependent applications
Inventory all internal products and third-party devices that embed libwebsockets and verify whether LWS_WITH_SYS_ASYNC_DNS is enabled
Restrict access to adjacent network segments where vulnerable devices operate, including guest Wi-Fi and shared VLANs

Patch Information

The libwebsockets maintainers have published a fix in upstream commit 2bb9598562b37c942ba5b04bcde3f7fdf66a9d3a. Vendors that ship libwebsockets statically linked into firmware must rebuild and reissue affected images. Reference the libwebsockets Commit Update for the source-level change.

Workarounds

Recompile libwebsockets with LWS_WITH_SYS_ASYNC_DNS disabled when the async DNS subsystem is not required
Route DNS through a trusted local resolver over a protected channel such as DNS over TLS (DoT) or DNS over HTTPS (DoH)
Segment vulnerable embedded devices onto isolated VLANs that exclude untrusted hosts capable of sniffing DNS traffic
Enforce stack protections such as -fstack-protector-strong and Address Space Layout Randomization (ASLR) when rebuilding consuming applications

bash

# Rebuild libwebsockets with async DNS disabled as an interim workaround
cmake -DLWS_WITH_SYS_ASYNC_DNS=OFF \
      -DCMAKE_C_FLAGS="-fstack-protector-strong -D_FORTIFY_SOURCE=2" \
      ..
make && sudo make install