CVE-2026-97064 in X-SpringBoot
Summary
by MITRE • 09/25/2026
X-SpringBoot through 6.0 ships with a hardcoded static master login verification code 172839 enabled by default in the database seed. Unauthenticated attackers can authenticate as any user by submitting the public master code to the emailOrMobileLogin endpoint with a known email or mobile number.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified in X-SpringBoot versions up through 6.0 represents a critical failure in authentication logic, specifically categorized under CWE-798: Use of Hard-coded Credentials. The core technical flaw lies in the application's database seeding process, which initializes the system with a static master login verification code hardcoded as the value 172839. This credential is enabled by default and persists across fresh installations without requiring explicit configuration or opt-in by the administrator. Consequently, this creates an unintended backdoor that bypasses standard multi-factor authentication mechanisms designed to secure user accounts via email or mobile number verification.
From a technical perspective, the exploitation vector targets the emailOrMobileLogin endpoint of the application's API. An unauthenticated attacker can interact with this endpoint by providing any validly formatted email address or mobile phone number associated with an existing account in the system. Instead of triggering the legitimate delivery and entry of a dynamic verification code sent to that user's device, the attacker simply submits the hardcoded master code 172839 as the authentication factor. The application logic incorrectly validates this static value against any provided identity, granting access without requiring knowledge of the actual password or possession of the victim's communication channel. This effectively neutralizes the security controls intended to verify user ownership of the contact information.
The operational impact of this vulnerability is severe and broad in scope. Since an attacker can authenticate as any existing user by knowing only their email address or mobile number, they gain full access to that account's data and privileges. Depending on the role assigned to the targeted user, this could range from unauthorized viewing of sensitive personal information to complete administrative control over the application if a high-privilege account is compromised. This undermines the fundamental trust model of the authentication system, allowing for identity theft, data exfiltration, privilege escalation, and potential lateral movement within connected systems. The ease of exploitation means that automated scanning tools can rapidly identify vulnerable instances by testing this specific credential against publicly known user identifiers.
This vulnerability aligns with MITRE ATT&CK technique T1078: Valid Accounts, where adversaries leverage legitimate credentials to maintain access or escalate privileges. It also reflects CWE-259: Use of Hard-coded Passwords and CWE-640: Weak Password Policy, as the system fails to enforce unique, dynamic secrets for authentication verification. The presence of such a hardcoded secret in production-ready software indicates a significant lapse in secure coding practices during development and quality assurance phases.
To mitigate this risk, immediate remediation is required by removing the hardcoded master code from the database seed script entirely. Authentication systems must rely on cryptographically secure random generation of one-time passwords or verification codes that are unique per session and tied to specific user identities through time-based expiration mechanisms rather than static shared secrets. Administrators should also audit existing deployments for any residual instances of this credential in their databases and rotate all affected account credentials if there is evidence of prior exploitation. Future development processes must include security reviews focused on authentication flows to ensure that no hardcoded bypasses or default administrative backdoors are introduced into the codebase, adhering strictly to principles of least privilege and secure defaults as outlined by industry standards such as OWASP Authentication Cheat Sheet guidelines.