CVE-2026-97063: X-SpringBoot Login Code Exposure

What Happened, in Brief

CVE-2026-97063 is an X-SpringBoot vulnerability affecting releases through version 6.0. The application’s unauthenticated login-code endpoints can expose verification codes in their HTTP responses instead of delivering them only through the associated mobile or email account. An attacker who knows a target identifier can request a code, read it from the response, and submit it to the application’s login endpoint.

The practical impact is an authentication bypass and potential account takeover. A successful attacker may gain the same application permissions as the targeted user, including access to data, administrative functions, or other workflows exposed by the deployment. The ultimate impact depends on the privileges assigned to the compromised account.

Technical Notes

The reported attack path uses three application routes:

GET  /sys/mobile/code
GET  /sys/email/code
POST /sys/emailOrMobileLogin/login

The first two routes reportedly return the login verification code in the HTTP response. The third accepts the exposed code as part of the login process. This is a serious failure of authentication-secret handling: the server treats a code as proof of control while disclosing that code to an unauthenticated requester.

What’s the Root Cause?

The root cause is the combination of unauthenticated code-generation endpoints and improper disclosure of the generated authentication secret. The application appears to generate a code for a supplied mobile number or email address, but instead of restricting delivery to the account owner’s out-of-band channel, it makes the code available to the requester through HTTP.

That design defeats the security property verification codes are intended to provide. A one-time code is useful only when it is delivered through a channel controlled by the legitimate account owner and protected against replay, guessing, and unauthorized retrieval. Returning the code in a response means that possession of a victim’s email address or mobile number may be sufficient to complete authentication.

The available evidence identifies SysLoginController as the implicated component, particularly the login-code generation and email/mobile login functionality. This root-cause interpretation is based on the NVD description and linked source path; a separately published vendor root-cause advisory was not confirmed.

Technical Notes

The relevant source reference is pinned to a repository commit and source range:

src/main/java/com/suke/czx/modules/sys/controller/SysLoginController.java
lines 94-134

Defenders reviewing a local build should trace whether the controller or equivalent implementation:

1. Accepts an email address or mobile number without authentication.
2. Generates a login code.
3. Places that code in a JSON, text, or structured HTTP response.
4. Accepts the same code through /sys/emailOrMobileLogin/login.

Renaming the endpoints does not resolve the issue. Codes must not be returned to unauthenticated clients and must be delivered only through the intended out-of-band channel.

Who Needs to Act?

Organizations running X-SpringBoot version 6.0 or any earlier release should treat the deployment as affected. The available record does not provide a lower bound for the affected range, so it is not possible to identify a safe minimum version from the supplied evidence. Inventory production and non-production instances, including deployments exposed through reverse proxies, API gateways, or mobile back ends.

The project identity associated with the vulnerability is the GitHub repository yzcheng90/X-SpringBoot. The available information does not establish a vendor-published fixed release. A deployment should not be considered remediated merely because it has been rebuilt from the repository or because its displayed version differs from 6.0. Review the code path or obtain a maintainer-confirmed release.

A particularly urgent review is warranted for deployments that use email or mobile number login for administrator, operator, customer-service, or other privileged accounts. Account takeover of a privileged identity could expand the impact well beyond a single user.

Analyst’s Take: Endpoint restriction should come before version-based risk decisions because no verified fixed release is identified and custom builds may retain the vulnerable controller behavior. Treat internet-facing deployments through version 6.0 as affected, then use logs and source review to determine exposure.

Why This CVSS Score?

The reported CVSS base score is 9.1, which places the issue in the critical-risk range in practical terms. The score is consistent with a remotely reachable authentication failure that does not require a pre-existing account and can lead to unauthorized access. However, the supplied NVD result did not include the CVSS vector, so the individual metric selections cannot be independently verified from the available evidence.

The likely security consequences are substantial: an attacker may authenticate as a victim, read or modify account data, and perform any actions available to that account. If administrative accounts can use the affected login flow, the resulting compromise may include management functions or broader data access. The precise confidentiality, integrity, and availability metrics remain subject to confirmation from the finalized NVD record or CNA advisory.

Administrators should not downgrade the operational priority simply because the target email address or mobile number must be known. Those identifiers are often exposed through public profiles, customer records, directory data, password-reset workflows, data breaches, or application enumeration. The public PoC also lowers the effort required to validate the attack path.

Technical Notes

Treat the missing vector as a documentation limitation, not as evidence that permits delay. Before publishing an internal risk exception, obtain the finalized vector from the authoritative record and separately assess:

Remote reachability
Authentication requirement
User interaction requirement
Confidentiality impact
Integrity impact
Availability impact

Has It Been Exploited?

A public proof of concept is available in the cve-request-poc repository, in the file 02_sms-code-account-takeover.py. This establishes that exploitation logic has been publicly documented and that defenders should assume the vulnerability is readily testable by security researchers and attackers.

Confirmed in-the-wild exploitation has not been established by the available evidence. CVE-2026-97063 was reported as not present in the CISA Known Exploited Vulnerabilities catalog at the assessment date. There is no reported CISA due date, ransomware association, or required action for this CVE.

CISA KEV status is not a guarantee that exploitation has not occurred. It means only that CISA had not listed the vulnerability based on the lookup performed. Organizations should distinguish the following conditions:

Do not run the public PoC against systems without written authorization. Use controlled test accounts and a non-production instance when validating exposure. A dedicated practice environment can help with safe validation; see this guide to building a cybersecurity homelab for detection practice.

How Do I Know If I’m Hit?

Start by identifying every X-SpringBoot deployment through version inventory, source inspection, package metadata, container image history, and reverse-proxy routes. A version alone may not be sufficient because custom builds can retain the vulnerable controller behavior after a version change. Confirm whether the two reported unauthenticated endpoints are reachable and whether they return a verification code in the response.

Review web access logs for requests to the code-generation routes followed by login attempts. A single request may be legitimate in some environments, but repeated requests, requests from unfamiliar addresses, requests targeting many identifiers, or a short sequence from code generation to successful login should be treated as suspicious.

Technical Notes

Search reverse-proxy, load-balancer, application, and identity logs for the reported paths:

grep -E '"(GET|POST) /sys/(mobile/code|email/code|emailOrMobileLogin/login)' \
  /var/log/nginx/access.log

For JSON-formatted logs in an environment using jq, a query can isolate the relevant routes:

jq -r '
  select(
    (.request_uri // .path // "") |
    test("^/sys/(mobile/code|email/code|emailOrMobileLogin/login)")
  ) |
  [
    (.timestamp // .time),
    (.remote_addr // .client_ip),
    (.request_method // .method),
    (.request_uri // .path),
    (.status // .status_code),
    (.user // .username // "-")
  ] | @tsv
' /var/log/app/access.json

A useful detection pattern is a code request followed by a login request from the same source address within a short interval. Also look for one source requesting codes for multiple email addresses or mobile numbers, HTTP responses containing fields such as code, smsCode, emailCode, or equivalent values, and successful logins that occur without a corresponding legitimate delivery event.

The absence of logs does not prove the absence of exploitation. Logs may have been rotated, the application may log only at a proxy layer, or the vulnerable response may not be captured. Review account activity, session creation, password changes, profile changes, and administrative actions for potentially targeted users.

What Do I Do About It?

No verified fixed version was identified in the available NVD record or retrieved project references. The exact upgrade target is therefore unknown, and administrators should not claim remediation by upgrading to an unverified release. Obtain a maintainer-confirmed release that explicitly prevents code disclosure, or validate the source and deployed behavior before closing the incident.

Until a verified fix is available, block public access to both code-generation endpoints. For an NGINX reverse proxy, a temporary route restriction can be applied as follows:

location = /sys/mobile/code {
    deny all;
    return 403;
}

location = /sys/email/code {
    deny all;
    return 403;
}

After reloading the proxy, verify the result from an authorized test client:

sudo nginx -t && sudo systemctl reload nginx

curl -i https://app.example.com/sys/mobile/code
curl -i https://app.example.com/sys/email/code

The expected result is an access-denied response, such as HTTP 403, and no verification code in the response body. Apply equivalent controls in the organization’s API gateway, ingress controller, web application firewall, or service mesh if NGINX is not the enforcement point.

The durable fix must ensure that verification codes are never returned to unauthenticated clients. Codes should be delivered only through the intended email or mobile channel, expire quickly, be single-use, resist replay, and be protected by rate limits and attempt limits. After remediation, invalidate active sessions for potentially exposed accounts, require credential or account recovery actions where appropriate, and review privileged-account activity.

For accounts whose passwords or recovery credentials may also have been exposed, use unique credentials and a reputable password manager rather than reusing secrets across services. Organizations that already use 1Password can review its Try 1Password → offering as one possible password-management option.

Technical Notes

A source-based verification workflow can help determine whether a candidate build is actually fixed:

git clone https://github.com/yzcheng90/X-SpringBoot.git
cd X-SpringBoot
git log --all --oneline -- src/main/java/com/suke/czx/modules/sys/controller/SysLoginController.java
grep -RInE '(/sys/mobile/code|/sys/email/code|emailOrMobileLogin|smsCode|emailCode)' .

This is an inspection command, not a confirmed upgrade command. Do not deploy the repository’s default branch without reviewing its release status, build provenance, dependency changes, and the relevant controller behavior. When a maintainer publishes a fixed release, use that release’s documented build or deployment command and verify that the deployed artifact no longer exposes codes.

If exposure is suspected, immediately preserve logs, identify accounts associated with code requests, invalidate their active sessions, rotate affected credentials or tokens, and check for changes made after suspicious logins. For evidence-handling considerations during an investigation, review this forensic imaging glossary. Prioritize administrator and service accounts.

Where This Comes From

The primary technical description comes from the NVD record for CVE-2026-97063. The NVD description identifies the affected product, the affected upper version boundary, the exposed endpoints, and the login endpoint used to complete the account takeover flow. The linked project source identifies the relevant SysLoginController implementation.

The public PoC and project references should be used for defensive validation, source review, and incident response. They do not establish active exploitation by themselves. Similarly, the absence of a CISA KEV entry does not establish that no organization has been attacked.

References:

1. NVD-linked public PoC:
   https://github.com/LinYuanyi1/cve-request-poc/blob/master/x-springboot/02_sms-code-account-takeover.py

2. X-SpringBoot project repository:
   https://github.com/yzcheng90/X-SpringBoot

3. Relevant SysLoginController source reference:
   https://github.com/yzcheng90/X-SpringBoot/blob/d74ddba989c0449948ff1ddb0d211b6a7ce81fba/src/main/java/com/suke/czx/modules/sys/controller/SysLoginController.java#L94-L134

4. VulnCheck advisory:
   https://www.vulncheck.com/advisories/x-springboot-through-6.0-authentication-bypass-via-login-code

The CVSS vector, minimum affected version, fixed version, and official vendor patch advisory were not confirmed in the supplied research material. Make the first response an inventory of X-SpringBoot deployments and restriction of the reported endpoints; keep those controls in place until the code path or a maintainer-confirmed release shows that codes are no longer exposed. Organizations should assume that X-SpringBoot deployments through version 6.0 are affected while those gaps remain unresolved.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.