CVE-2026-109424 in Cloud Music
Summary
by MITRE • 10/12/2026
NetEase Cloud Music client for Windows (cloudmusic.exe) versions 3.1.38 and 3.1.39.205426 contains a weak encryption vulnerability where /eapi/ and /xeapi/ API response bodies are decrypted using a fixed, publicly documented AES-128-ECB key with no integrity credential. Attackers who can intercept or originate server responses can construct valid ciphertext under the known key with PKCS#7 padding, enabling the client to accept forged API responses that serve as a prerequisite for further exploitation such as reaching the os.navigateExternal bridge.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in NetEase Cloud Music client versions 3.1.38 and 3.1.39.205426 represents a critical failure in cryptographic implementation, specifically categorized under CWE-327: Use of a Broken or Risky Cryptographic Algorithm. The core technical flaw lies in the decryption mechanism for API response bodies returned from endpoints such as /eapi/ and /xeapi/. Instead of employing dynamic key exchange protocols or utilizing keys derived from session-specific data, the application relies on a fixed, publicly documented AES-128-ECB encryption key. This design choice fundamentally undermines the confidentiality and integrity guarantees that symmetric encryption is intended to provide. The use of Electronic Codebook mode further exacerbates this weakness by failing to obscure patterns in the plaintext, although the primary issue here is the static nature of the key itself rather than the block cipher mode's pattern preservation properties alone.
The absence of any integrity credential or message authentication code means that there is no mechanism for the client to verify whether a decrypted response has been tampered with during transit. In standard secure communications, protocols such as TLS utilize HMAC or AEAD modes to ensure data authenticity and prevent modification by third parties. Without these safeguards, an attacker positioned in the network path can intercept legitimate traffic or inject their own crafted responses. Because the encryption key is known and static, it becomes trivial for a malicious actor to encrypt arbitrary payloads using AES-128 with PKCS#7 padding. The client application will successfully decrypt this forged ciphertext because it matches the expected format and passes decryption without raising integrity errors, effectively treating attacker-controlled data as legitimate server responses.
This vulnerability enables severe operational impacts, primarily facilitating Man-in-the-Middle attacks where an adversary can manipulate the behavior of the desktop application. By constructing valid but malicious API responses, attackers can trick the client into executing unintended actions or loading untrusted content. A significant consequence highlighted in reports is that this flaw serves as a prerequisite for reaching the os.navigateExternal bridge functionality. This bridge likely allows the application to interact with external systems or browsers, and by forging responses that trigger specific navigation commands, an attacker could potentially induce the client to open malicious URLs or execute arbitrary code through associated system handlers. The ability to spoof server identity completely removes any trust boundary between the client and the network environment it operates within.
From a threat intelligence perspective, this vulnerability aligns with ATT&CK techniques related to Man-in-the-Middle attacks and potential privilege escalation if the forged responses lead to execution of external processes. It also reflects CWE-347: Improper Verification of Cryptographic Signature, as the application fails to validate that the data originated from a trusted source. The reliance on hardcoded keys is a common anti-pattern in software development often resulting from convenience during early prototyping or poor security hygiene in production releases. Such practices are explicitly discouraged by industry standards including OWASP and NIST guidelines for cryptographic storage and transmission, which mandate dynamic key management and integrity verification mechanisms like HMAC-SHA256 or AES-GCM to prevent replay and modification attacks.
Mitigation strategies must prioritize immediate remediation of the encryption implementation. The most effective solution is to replace the static AES-128-ECB scheme with a modern authenticated encryption algorithm such as AES-256-GCM, which provides both confidentiality and integrity in a single operation. If maintaining backward compatibility is necessary for legacy systems, implementing an HMAC-based message authentication code alongside standard encryption like AES-CBC or AES-CTR would restore the missing integrity checks. Furthermore, any hardcoded cryptographic keys must be removed from the binary and replaced with secure key derivation functions that generate unique session keys based on strong random seeds or established key exchange protocols such as Diffie-Hellman. Until a patch is deployed by NetEase, users are advised to exercise caution when using public Wi-Fi networks where traffic interception is feasible, although network-level protections like TLS inspection may not fully mitigate this client-side logic flaw if the application bypasses standard certificate validation for these specific API endpoints.