Safeguard
Vulnerability Analysis•

CVE-2025-3202: High Improper Authorization in ruoyi-ai Notices

CVE-2025-3202 is a high severity authorization flaw in ruoyi-ai up to 2.0.0. Upgrade to 2.0.1 or later and check your notices for edits you did not make.

Safeguard Security Team
3 min read

CVE-2025-3202 is a high severity (CVSS 7.3) improper authorization flaw in ageerle ruoyi-ai up to version 2.0.0. The system notice controller did not enforce access checks. The record says upgrading to 2.0.1 fixes it, so move to 2.0.1 or later and audit your notices.

What's affected

The NVD record covers ruoyi-ai up to 2.0.0. The file named is ruoyi-modules/ruoyi-system/src/main/java/org/ruoyi/system/controller/system/SysNoticeController.java. The weakness classes are CWE-266 and CWE-285.

The record says upgrading to 2.0.1 addresses the issue and names the patch commit 6382e177bf90cc56ff70521842409e35c50df32d. The v2.0.1 release notes say the same thing in plain terms: they list a bug fix so that only logged in users can modify notice information.

The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L. That means network reachable, no login needed, and low impact on each of confidentiality, integrity and availability. The record says an exploit is public. The CISA Known Exploited Vulnerabilities flag is false.

How to check if you're exposed

Check your release tag or commit.

git describe
git log -1 6382e17

A tag below v2.0.1, or a build where the second command reports an unknown revision, is affected. The public issue that led to the CVE describes the notice controller as letting someone query and change messages that the platform shows to users. So the practical test is to look at your notice list in the admin panel and ask whether every entry is one your team wrote.

Also check your reverse proxy logs for requests to the notice endpoints from sources that are not your staff.

What to do now

  1. Upgrade to 2.0.1 or later. Since 2.0.2 followed it on the same day according to the release pages, plan for the latest release rather than stopping at 2.0.1.
  2. Put the management interface behind a VPN or an allow list until the upgrade is done.
  3. Review stored notices and announcements for text or links you did not write. A changed notice is a convenient way to point users at a hostile page.
  4. Keep an eye on the project's releases, because the same release line fixed a related model settings flaw, CVE-2025-3199.
  5. Record the version in your asset list.

The free in-browser dependency scan takes a manifest or lockfile and lists known CVEs for the packages in it, and the Gold directory lets you look up a CVE by id.

Why it matters

A notice board looks harmless, but it is a message channel from the platform to its users. If anyone can edit it, they can say anything in the voice of the application. That is a trust problem even when no data leaves the system.

The root cause is the same as in many Java web projects: access control added to some controllers and forgotten on others. A global rule, such as denying every route unless it is explicitly marked public, is a safer default than checking each controller by hand.

Quick check

Which version fixes CVE-2025-3202?

The record says 2.0.1. Newer releases exist, so use the latest one.

Is this exploited in the wild?

No source reviewed says so, and it is not in the CISA KEV catalog. The record does say a public exploit exists.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

We email you a link to confirm, and only then add you to the list. Unsubscribe in one click. Privacy

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.