GIVE YOUR AGENT THE EVIDENCE

Set up in your agent.

One prompt to get started. Paste it into your coding agent to connect cve.new through MCP and bring vulnerability context into your workflow.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

GIVE YOUR AGENT THE EVIDENCE

Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

cve.new
Check your stack
CVE-2026-7679medium6.9

YunaiV yudao-cloud OAuth2TokenServiceImpl.java getAccessToken improper authentication

Impact

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,…

Source excerpt · VulDB

Affected packages

This source has no supported package-version data for matching. You can read the advisory here, but this record alone cannot power a dependency check.

Affected products

Vendor version evidence. Product records are separate from automatic dependency matching.

Original source 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."

References