X-SpringBoot flaw hands out login codes to anyone who asks

A critical bug in a popular Java admin framework lets attackers read one-time codes straight off the server's response - but only if you're actually running the thing.

Illuminated circuit board with glowing traces and electronic components
Photo · Brecht Corbeel / Unsplash

What’s happened

A newly published vulnerability, tracked as CVE-2026-97063, has been given a critical CVSS score of 9.1. It affects X-SpringBoot, a Chinese-developed open-source Java framework used to spin up admin panels and back-office systems quickly - the sort of tool developers reach for when they don’t want to build login screens, permissions and SMS integrations from scratch.

According to the NVD listing, versions up to 6.0 have a rather basic problem: two endpoints, GET /sys/mobile/code and GET /sys/email/code, are meant to generate a one-time verification code and text or email it to the account holder. Instead, the flawed version also hands the code straight back in the HTTP response - to anyone who asks, without needing to log in first.

What the bug actually does

In plain terms: normally a verification code is a secret shared only between the server and the phone (or inbox) it was sent to. Here, the server apparently prints that secret on the receipt it gives to whoever requested it. A proof-of-concept script on GitHub shows the logic: call the endpoint for a target account, read the code out of the response, then use it to log in as that account - no password, no access to the victim’s phone, no social engineering required.

That’s a textbook account-takeover bug. If it works as described, it turns a login feature designed to prove you own an account into a feature that lets a stranger prove it for you.

So who is actually at risk

This is not a Windows update, a browser flaw or anything sitting on the average reader’s laptop. X-SpringBoot is a developer framework - organisations that have used it to build their own admin systems or customer-facing apps are the ones exposed, not the public directly. The GitHub project itself is reasonably popular, with over 2,700 stars and 800-plus forks, suggesting real-world deployments exist, though there’s no published figure for how many live systems are actually running the vulnerable code.

Crucially, several basic questions remain unanswered by what’s been published so far: there’s no confirmation yet of a patched release, no indication whether the flaw is being actively exploited, and no solid count of affected installations. NerdBite would treat “critical severity” here as a statement about how bad the bug is if triggered, not proof that it’s currently being abused at scale.

If your organisation runs X-SpringBoot, the people at risk are your users - anyone whose account could be hijacked by someone simply requesting a code on their behalf and reading it straight off the wire.

What to do about it

If you or your employer has deployed X-SpringBoot, check which version is running and watch the project’s repository and the NVD entry for a fix. Until a patch appears, treat the SMS and email code endpoints as untrusted, and consider blocking or rate-limiting anonymous access to them at the network level.

For everyone else - this isn’t a bug in your phone, your bank app or anything you’ll be prompted to update. It’s a lesson in why “send the code” and “here’s the code” should never live in the same response.

The takeaway

A real, well-documented flaw with a working demonstration exploit - but a narrow one, hitting a specific developer framework rather than consumer software. Worth a look if you build systems for a living; not a reason for ordinary readers to change any passwords tonight.

Sources