NetEase Cloud Music CVE-2026-109424

Exploitation requires the attacker to intercept or originate server responses to the client's /eapi/ and /xeapi/ API endpoints - i.e. a man-in-the-middle or traffic-tampering position (ARP/DNS spoofing, rogue proxy, or compromised network path) - which maps to the AC:H in the CVSS vector. No client-side authentication or privileges are needed (PR:N) because the AES-128-ECB key is fixed and publicly documented and responses carry no integrity credential (no signature/MAC), so any party with the known key can forge valid ciphertext with PKCS#7 padding. Limiting factors: the network-position requirement is the main barrier; only specific versions 3.1.38 and 3.1.39.205426 are named; and the flaw alone delivers only forged-response acceptance - meaningful impact depends on chaining to a follow-on primitive such as the os.navigateExternal bridge, so it is a prerequisite rather than a complete compromise.

The input CVSS 4.0 score of 8.2 (High) is driven primarily by VI:H (high integrity impact) combined with AV:N and PR:N/UI:N, but it is tempered by AC:H, which correctly reflects that an attacker must occupy a privileged network position to intercept or originate server responses. No EPSS score, no CISA KEV listing, and no confirmed exploit code are present in the input, so there is no signal of active or widespread exploitation - this appears to be a vendor-disclosed (VulnCheck) weakness rather than an in-the-wild threat. The headline severity is somewhat inflated relative to real-world risk: the flaw yields only integrity impact (VC:N/VA:N) and, per the description, is explicitly a 'prerequisite for further exploitation such as reaching the os.navigateExternal bridge' rather than a standalone compromise. My independent CVSS 3.1 estimate lands around 5.9 (Medium), reflecting the MITM prerequisite (AC:H) and integrity-only impact - the divergence from the 8.2 is expected given CVSS 4.0's different weighting of integrity-only network vulnerabilities. Net assessment: a legitimate crypto-design weakness (CWE-321, hardcoded AES-128-ECB key with no integrity credential) worth patching, but not an urgent mass-exploitation priority absent evidence of the follow-on bridge chain being weaponized.

An attacker on the same network, or one able to tamper with/originate traffic to the client (e.g. via DNS/ARP spoofing, a malicious proxy, or a compromised upstream), encrypts a malicious payload under the publicly documented AES-128-ECB key with PKCS#7 padding and returns it as a forged /eapi/ or /xeapi/ response. Because the client performs no integrity verification, it accepts the forged response as authentic, which can then be used to reach the os.navigateExternal bridge and set up further exploitation. A public gist documenting the fixed key lowers the barrier to crafting valid ciphertext, though no confirmed weaponized exploit is identified.