CVE-2026-117922 in Firefox
Summary
by MITRE • 10/27/2026
Use-after-free in the Networking: WebSockets component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, and Firefox ESR 153.6.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The identified vulnerability represents a critical memory management error within the Mozilla Firefox browser's networking subsystem, specifically affecting the WebSocket implementation. This flaw is classified as an out-of-bounds write resulting from use-after-free conditions, which occurs when software continues to utilize a pointer after it has been freed or deallocated by the system. In the context of web technologies like WebSockets, this typically involves complex state transitions where network messages are processed asynchronously. If the underlying memory buffer associated with a WebSocket connection is released while an asynchronous operation still holds a reference to that memory, subsequent access attempts will target invalid or recycled memory addresses. This scenario creates a window for exploitation where the browser's internal data structures can be corrupted in unpredictable ways depending on how quickly and by what other objects the freed memory is reallocated.
From a technical perspective, this vulnerability aligns with Common Weakness Enumeration identifier CWE-416, which defines use-after-free errors as a significant category of software defects leading to security vulnerabilities. The exploitation potential stems from the ability of an attacker-controlled webpage or malicious script to trigger specific race conditions during WebSocket message handling. By carefully crafting network payloads and timing requests, an adversary can force the browser into a state where it writes data to memory that has already been returned to the heap allocator. This out-of-bounds write allows for arbitrary code execution if the attacker can control both the content written and the location in memory targeted. Such exploits are particularly dangerous because they bypass many standard security mitigations, including stack canaries and non-executable memory pages, by manipulating heap structures that may be mapped as executable or by achieving a primitive that leads to further exploitation stages like arbitrary read-then-write scenarios.
The operational impact of this vulnerability is severe, potentially allowing remote code execution on the victim's system without any user interaction beyond visiting a maliciously crafted website. Attackers could leverage this flaw to install malware, steal sensitive data such as session cookies or credentials stored in browser memory, or establish persistent access to the compromised machine. The risk is amplified by the widespread use of WebSockets for real-time communication features across modern web applications, meaning that many legitimate sites may inadvertently serve as vectors if they are not properly secured against malicious third-party scripts or injected content. Furthermore, because this issue resides in a core networking component, it affects multiple platforms and architectures supported by Firefox, increasing the potential blast radius of any successful exploitation attempt.
To mitigate these risks, users must ensure that their browsers are updated to versions where the vulnerability has been patched. Specifically, upgrading to Firefox version 159 or later is required for standard releases, while organizations relying on extended support should update to Firefox ESR version 115.44 or Firefox ESR version 153.6 and newer. These updates contain code changes that enforce stricter memory management protocols within the WebSocket engine, ensuring that pointers are nullified after deallocation and preventing access to freed memory regions. Additionally, security teams should monitor for indicators of compromise related to heap spraying techniques often associated with this class of vulnerabilities. Implementing strict content security policies can also help reduce the attack surface by limiting the sources from which scripts can initiate WebSocket connections, thereby reducing the likelihood that a malicious actor can trigger the vulnerable code path in the first place.