Skip to main content

XX-Net EUVDEUVD-2026-33346

| CVE-2026-10099 MEDIUM
Improper Validation of Syntactic Correctness of Input (CWE-1286)
2026-05-29 disclosure@vulncheck.com GHSA-cwjv-w927-x7gr
5.1
CVSS 4.0 · Vendor: vulncheck
Share

Severity by source

Vendor (vulncheck) PRIMARY
5.1 MEDIUM
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from Vendor (vulncheck) · only source for this CVE.

CVSS VectorVendor: vulncheck

Attack Vector
Local
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
X

Lifecycle Timeline

2
Source Code Evidence Fetched
May 29, 2026 - 16:55 vuln.today
Analysis Generated
May 29, 2026 - 16:55 vuln.today

DescriptionCVE.org

XX-Net V5.16.6 contains a WebSocket frame parsing vulnerability in the WebSocket_receive_worker routine of simple_http_server.py that allows attackers to cause corrupted application data by sending unmasked WebSocket frames. The server unconditionally reads 4 bytes as a masking key regardless of whether the MASK bit is set in the frame header, causing the first 4 bytes of payload to be consumed as a mask key and the remaining payload to be incorrectly XOR-decoded, resulting in data corruption alongside missing RSV bit, opcode, and FIN fragmentation validations.

AnalysisAI

WebSocket frame parsing in XX-Net V5.16.6 corrupts application-layer data when the local HTTP server's WebSocket_receive_worker routine unconditionally consumes 4 bytes as a masking key regardless of the RFC 6455 MASK bit, causing payload data to be silently misinterpreted. Attackers with local system access and no privileges can send unmasked WebSocket frames to the embedded simple_http_server.py endpoint, causing the first 4 bytes of any payload to be misread as a mask key and the remainder to be incorrectly XOR-decoded. No public exploit has been identified at time of analysis and this vulnerability is not listed in CISA KEV; an upstream fix exists as a GitHub commit and open pull request but a formally released patched version has not been independently confirmed.

Technical ContextAI

XX-Net is a network circumvention proxy tool that embeds a custom Python HTTP/WebSocket server in code/default/lib/noarch/simple_http_server.py. RFC 6455 §5.2 defines the WebSocket framing protocol: bit 7 of the second header byte is the MASK flag, and when set, a 4-byte masking key follows the (extended) payload length field before the payload itself. The vulnerable WebSocket_receive_worker routine failed to check this MASK bit, instead unconditionally calling self.rfile.read(4) to extract a masking key regardless of frame type. The result is a systematic off-by-four byte alignment error: for any unmasked frame, the key array is populated with payload bytes, the remaining payload is XOR-decoded against those incorrect bytes, and the decoded string is silently passed upstream as legitimate application data. The description also notes missing validations for RSV bits, opcodes, and FIN fragmentation - suggesting the parser has broader RFC 6455 compliance gaps beyond the MASK bit issue. CWE-1286 (Improper Validation of Specified Type of Input) accurately describes the root cause: the code treats the MASK flag's value as irrelevant and applies a fixed parsing path regardless of what the protocol header signals.

RemediationAI

The upstream fix is available as GitHub commit a68b972a84ed6e52df9f30237cf47493b9231b53 (https://github.com/XX-net/XX-Net/commit/a68b972a84ed6e52df9f30237cf47493b9231b53) and the associated pull request #14170 (https://github.com/XX-net/XX-Net/pull/14170); however, a formally tagged and released patched version past V5.16.6 has not been independently confirmed - operators should monitor the XX-Net releases page for a version incorporating this commit. As a compensating control, restrict local system access to accounts that genuinely require XX-Net's WebSocket interface, reducing the pool of principals who could send malformed frames; this has no functional trade-off for single-user deployments. Because the server is locally bound by design, blocking external network access to the simple_http_server port via host firewall rules (e.g., iptables -A INPUT -p tcp --dport <XX-Net-port> -s 127.0.0.1 -j ACCEPT followed by a DROP rule) prevents adjacent-network abuse at the cost of potentially restricting legitimate LAN-based management if used that way.

Share

EUVD-2026-33346 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy