CVE-2026-102759 in NetX Duo
Summary
by MITRE • 09/29/2026
NetX Secure TLS accepts an empty application-data record without verifying its message authentication code. In `_nx_secure_verify_mac`, a decrypted application record whose length equals the negotiated MAC size is treated as valid and returns success after advancing the receive sequence number. The received MAC is never generated or compared.
Empty TLS application-data records are legal, and are commonly emitted by TLS 1.0 implementations as a BEAST mitigation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability in NetX Secure TLS stems from an improper validation of message authentication codes within the decryption routine for application data records. Specifically, during the execution of the _nx_secure_verify_mac function, the implementation fails to correctly handle cases where the decrypted record length matches the negotiated MAC size exactly. In such scenarios, the code incorrectly treats the empty payload as valid and returns a success status without actually generating or comparing the expected message authentication code against any received value. This logic error effectively bypasses integrity verification for specific TLS records that appear legitimate due to their structural properties rather than cryptographic validity.
This flaw allows an attacker to inject malicious data into the encrypted channel by sending empty application-data records, which are technically legal under TLS specifications and often used as a mitigation strategy against BEAST attacks in older implementations like TLS 1.0. Because the system accepts these records without verifying their authenticity, it creates a pathway for message injection or potential denial of service through state manipulation. The receive sequence number is advanced despite the lack of proper authentication check, which can lead to synchronization issues and further exploitation opportunities if subsequent packets rely on this corrupted state.
From an industry standards perspective, this vulnerability aligns with CWE-347, Improper Verification of Cryptographic Signature, as the system fails to ensure that a received cryptographic signature is valid before accepting data. Additionally, it relates to CWE-295, Improper Certificate Validation, in the broader context of TLS handshake and record layer integrity checks. In terms of MITRE ATT&CK techniques, this could facilitate Man-in-the-Middle attacks by allowing an adversary to manipulate traffic flow or inject payloads without detection, potentially leading to data exfiltration or unauthorized access depending on the application protocol carried over TLS.
To mitigate this issue, developers must update the NetX Secure TLS implementation to ensure that all received records undergo rigorous MAC verification regardless of their payload length. The code should explicitly check for empty payloads and either reject them if they are not expected in the current context or handle them with appropriate integrity checks rather than assuming validity based on size alone. Furthermore, enforcing stricter adherence to modern TLS versions where such ambiguities are less prevalent can reduce exposure. Regular security audits focusing on cryptographic verification routines will help identify similar logic errors before deployment.