CVE-2026-7679: YunaiV yudao-cloud · Improper Authentication
Affects YunaiV yudao-cloudSource CVE Database V5
Public exploit available · CVSS 6.9 Medium.
Data as of 31 Oct 2026, 20:34 UTC
Thin evidence
One scorer or none| CNA (VulDB) | CVSS 4.0 | 6.9 |
|---|---|---|
| CNA (VulDB) | CVSS 3.1 | 7.3 |
| CNA (VulDB) | CVSS 3.0 | 7.3 |
| CNA (VulDB) | CVSS 2.0 | 7.5 |
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 35% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:PExploitation evidence
Disclosed: evidence found.
CVE published 3 May 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: evidence found.
CVSS exploit maturity: proof of concept public
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), CVSS vector, the Metasploit, Exploit-DB and nuclei-templates index as of 31 Oct 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| YunaiVyudao-cloud | Affected
| Fixed in– |
MavenyunaiV/yudao-cloudpkg:maven/yunaiV/yudao-cloudOther threats | Affected
| Fixed in– |
CPE configurations (1)
cpe:2.3:a:yunaiv:yudao-cloud:*:*:*:*:*:*:*:*
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Until a fix is released, consider restricting external access to the affected service and applying compensating controls where possible.
Description
A security flaw has been discovered in YunaiV yudao-cloud up to 2026.01. This impacts the function getAccessToken of the file yudao-module-system-biz/src/main/java/io/github/ruoyi/common/oauth2/service/impl/OAuth2TokenServiceImpl.java. Performing a manipulation results in improper authentication. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks. The vendor explains: "[W]e intentionally retain the existing generic compatibility path that accepts a valid, unexpired stored refresh token when an access-token lookup is unavailable, for integrations such as reports and WebSocket. We are not introducing strict access-token-only verification, new revocation behavior or a separate trusted-entry API. This is a retained compatibility decision, not a claim that this behavior follows the standard OAuth separation or that every identity/revocation scenario has been eliminated."