CVE-2026-108677 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains a missing authorization vulnerability in GET /sys/api/getUserByName that allows low-privileged authenticated users to retrieve any user's stored password value. Attackers can decrypt the AES-CBC protected response using the hard-coded key exposed by /sys/getEncryptedString to obtain administrators' password ciphertexts for offline guessing.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in JeecgBoot versions up to 3.9.5 represents a critical failure in access control mechanisms, specifically categorized under CWE-284 Improper Access Control. The flaw resides within the GET /sys/api/getUserByName endpoint, which is designed to retrieve user profile information based on a provided username. While this functionality might be intended for legitimate administrative or self-service purposes, it lacks sufficient authorization checks to restrict access based on the requesting user's role or identity relative to the target account. Consequently, any authenticated user with low privileges can invoke this API endpoint and supply arbitrary usernames as parameters, thereby bypassing standard security boundaries that should prevent unauthorized data retrieval.
The severity of this vulnerability is significantly amplified by the manner in which sensitive credentials are handled within the application architecture. The system stores passwords using AES-CBC encryption rather than irreversible hashing algorithms like bcrypt or Argon2, a practice that violates fundamental principles of secure password storage outlined in CWE-564. Although the data at rest appears encrypted, the implementation contains a critical flaw: the decryption key is hard-coded and exposed through another endpoint, GET /sys/getEncryptedString. This design choice effectively neutralizes the protection offered by encryption, as it allows any authenticated user to retrieve the secret key required to decrypt the stored password ciphertexts.
From an operational perspective, this vulnerability enables a severe compromise of system integrity and confidentiality. An attacker with low-level access can systematically enumerate users or target specific high-privilege accounts such as administrators. By retrieving their encrypted passwords and combining them with the exposed decryption key, the attacker obtains plaintext credentials that are immediately usable for offline brute-force attacks. This capability facilitates privilege escalation, allowing the attacker to assume administrative roles within the application. Once elevated privileges are achieved, the attacker can potentially access sensitive business data, modify system configurations, or deploy further malicious code, leading to a complete compromise of the underlying infrastructure.
This attack vector aligns with several techniques documented in the MITRE ATT&CK framework. The initial exploitation corresponds to T1078 Valid Accounts, as it relies on valid but low-privileged credentials to access unauthorized resources. The retrieval and decryption of passwords map to T1552 Unsecured Credentials, specifically involving stored credentials that are protected by weak or exposed keys. Furthermore, the ability to decrypt these values for offline cracking relates to T1040 Network Sniffing if intercepted in transit, though here it is more accurately described as local credential access via API abuse. The ultimate goal of gaining administrative control falls under T1078.003 Cloud Accounts or general privilege escalation techniques depending on the deployment context.
To mitigate this vulnerability, immediate remediation steps are required at both the application code level and architectural design levels. First, the GET /sys/api/getUserByName endpoint must be updated to enforce strict authorization checks, ensuring that users can only retrieve their own profile information unless they possess explicit administrative privileges. Second, the hard-coded encryption key exposed via /sys/getEncryptedString must be removed entirely from client-accessible endpoints and stored securely using environment variables or a dedicated secrets management service with restricted access controls. Third, password storage mechanisms should be migrated to use strong, adaptive hashing algorithms such as bcrypt, scrypt, or Argon2, which render offline guessing attacks computationally infeasible even if the database is compromised. Finally, implementing comprehensive logging and monitoring for unusual API usage patterns can help detect exploitation attempts early, providing an additional layer of defense-in-depth against this type of access control bypass.