RuoYi-Vue-Plus EUVD-2026-98939

The attacker must hold a valid authenticated account (PR:L) on the RuoYi-Vue-Plus instance and must know or enumerate the target victim's social binding identifier (socialId), which the vulnerable DELETE /auth/unlock/{socialId} endpoint accepts without verifying ownership. The deployment must have the OAuth social-login binding feature in use (GitHub, WeChat, or Gitee) for there to be a binding worth deleting. Limiting factors: exploitation yields only denial of the victim's social-login path (no confidentiality loss, no account takeover, no password credential impact), requires a logged-in session, and depends on obtaining the correct socialId - if binding IDs are non-sequential or hard to enumerate, targeting a specific victim is harder.

This is a genuinely low-priority issue, and the available signals agree rather than conflict. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:L) yields a score of only 2.3: no confidentiality impact, and only LOW integrity and availability impact limited to a single victim's social-login binding. PR:L confirms an authenticated account is required, and AT:P reflects that the attacker must first obtain the victim's specific socialId, which is a meaningful precondition. No EPSS score, CISA KEV listing, or explicitly-flagged POC is present in the input, so there is no public exploit code confirmed - though a detailed technical write-up (hackmd) and a VulnCheck advisory document the exact vulnerable request, meaning exploitation is trivial for anyone who reads them. There is no SSVC decision data provided. Bottom line: a real but minor authorization (IDOR) flaw that denies a victim their social-login convenience; it does not grant account takeover, data disclosure, or privilege escalation, so it does not warrant emergency prioritization. One note: the single input Tag 'Authentication Bypass' is inconsistent with the CWE-639 classification and PR:L requirement - this is an authorization/IDOR defect, not an authentication bypass.

An attacker with any valid low-privilege RuoYi-Vue-Plus account enumerates or obtains another user's social binding identifier and issues a DELETE /auth/unlock/{socialId} request using the victim's socialId. The server deletes the victim's GitHub, WeChat, or Gitee binding and stored OAuth tokens, preventing the victim from logging in via that social provider until they re-bind. No public exploit code is confirmed in the input, but the VulnCheck advisory and hackmd write-up describe the exact request.