iflytek SkillHub EUVD-2026-96345

The attacker must hold a valid authenticated SkillHub session (any low-privilege user suffices, per PR:L); no admin rights are needed. The specific trigger is the self-service account-merge flow: the merge-initiate endpoint returned the verification token directly to the caller, and the verify/confirm steps did not require the target account to approve from its own authenticated session, so a single actor could complete a merge against any named username or OAuth identity. Exploitation works against default deployments because the diff notes the flow is enforced by the API even though the /settings/accounts UI remains redirected (not yet exposed). Limiting factors: the attacker needs an authenticated account and must know or guess the victim's username or OAuth identity; versions 0.2.22 and later require dual-account confirmation, token revocation, and request cancellation, closing the flaw.

This is a credible, actionable priority for anyone running iflytek SkillHub, but the risk is scoped by its preconditions rather than being a mass-exploitation threat. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 8.7 High score are internally consistent with the description: remote, low-complexity, no user interaction, but requiring an already-authenticated (PR:L) attacker. The impact triad VC:H/VI:H/VA:H is well justified - the attacker inherits the victim's API tokens, roles, and namespace ownership, i.e. full account takeover. No EPSS score is provided in the input, so exploitation probability cannot be quantified. This is NOT in CISA KEV (no confirmed active exploitation) and no public exploit code is referenced, though the fixed source lines (AccountMergeService.java#L95-L109) and the patch commit are public, making the logic flaw trivially reconstructable. The root cause is confirmed by the diff: the initiate endpoint returned the verification token directly in MergeInitiateResponse, and the verify step consumed that token instead of requiring the second account's authenticated approval - a classic CWE-863 incorrect-authorization bug. Net: real and worth prompt patching for SkillHub operators because exploitation is reliable and high-impact once a low-privilege account is held, but the authentication requirement and the product's limited deployment footprint reduce broad, internet-wide urgency.

An attacker registers or already holds a low-privilege SkillHub account, then calls the account-merge initiate endpoint naming a victim's username or OAuth identity. Because the API returns the verification token directly in the response, the attacker confirms the merge without ever controlling the victim account, inheriting the victim's API tokens, roles, and namespace ownership. No public exploit is referenced, but the fixed source lines and patch commit make the flaw straightforward to reproduce.