CVE-2025-4494 is a high severity improper authentication flaw (CVSS 7.3) in JAdmin 1.0 from JAdmin-JAVA. The toLogin function in NoNeedLoginController.java, part of the admin backend, can be abused remotely without credentials. The record lists no fix, so limit access to the backend and check the project's issue.
What's affected
Per the CVE record, JAdmin 1.0 is affected. The weak spot is the toLogin function in the file NoNeedLoginController.java in the Admin Backend component. The record describes the result as improper authentication, and it says the attack can be launched remotely.
No fixed version is named. The only reference to the project is a public GitHub issue on the JAdmin repository, which I did not retrieve. Check that issue and the repository's releases for any change after the report.
The record says the exploit has been disclosed to the public. It does not say the bug is used in attacks, and the KEV flag is false.
How to check if you're exposed
First, confirm whether JAdmin is part of anything you run. It is a Java admin backend, so look in your build files for it. For a Maven project:
grep -rn -i "jadmin" --include=pom.xml .
For Gradle projects, search the build files instead:
grep -rn -i "jadmin" --include=build.gradle* .
If the code was copied into your repository, search for the class name:
grep -rln "NoNeedLoginController" .
Then check how the admin backend is reached. If it listens on a public address, anyone can send it requests. Look at your reverse proxy or load balancer rules and at the security group for the host.
Finally, read the access logs for requests to the login route and look for clients that never completed a normal sign in but reached admin pages.
What to do now
- Search your repositories and deployed artifacts for JAdmin 1.0.
- Move the admin backend behind a VPN or an IP allow list. It should not face the internet.
- Read the project's public issue and releases for a fix, and apply one if it exists.
- If you maintain a fork, review how
toLogindecides that a caller is authenticated, and make sure every admin route checks a valid session on the server side. - Rotate admin passwords and session secrets if you find signs of unexpected access.
- Add the application to your monitoring so that new admin logins raise an alert.
Why it matters
The record maps this to CWE-287, improper authentication. The code is meant to confirm who a caller is, and it can be talked into accepting someone who has not proved it. Admin backends are the worst place for that, because they usually hold user management, configuration and data export.
The name of the controller, NoNeedLoginController, hints at how these bugs happen. Routes that are meant to be public get grouped together, and the login logic ends up in a place with no authentication check around it. Review such groupings with care.
A dependency scan will show you whether JAdmin is in your tree. Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan can do that for a manifest file, and the Gold directory lists related CVEs by product.
Quick check
Is CVE-2025-4494 being exploited in the wild?
The record does not report exploitation and its CISA KEV flag is false. That can change, so check the CISA catalog again before you decide how urgent this is.
Is there a fixed version of JAdmin?
The record does not name one. Check the project's GitHub issue and its releases, and keep the backend off the public internet until you know.
Sources
- CVE-2025-4494 on Gold
- NVD record for CVE-2025-4494
- Reference listed in the CVE record: a public issue on the JAdmin GitHub repository and VulDB entries. They were not retrieved when this post was written.
Last reviewed: 18 October 2026.
