CVE-2026-93954 in grimmory
Summary
by MITRE • 09/20/2026
A security vulnerability has been detected in grimmory-tools grimmory up to 3.3.3/3.4.1. Affected is the function AppSettingController.getAppSettings of the file backend/src/main/java/org/booklore/controller/AppSettingController.java of the component Settings API Endpoint. Such manipulation leads to incorrect authorization. The attack can be launched remotely. The exploit has been disclosed publicly and may be used. The name of the patch is 2b66ca6df8110f6b512e030b54c16b9fbe318f17. Applying a patch is advised to resolve this issue. PR #2558, merged as 53abc8b, moved the OIDC secret into a dedicated setting, but did not by itself restrict GET /api/v1/settings.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/20/2026
The vulnerability identified in grimmory-tools versions up through 3.3.3 and 3.4.1 represents a critical failure in access control mechanisms within the Settings API Endpoint of the application backend. Specifically, the flaw resides in the AppSettingController.getAppSettings function located in the file backend/src/main/java/org/booklore/controller/AppSettingController.java. This component is responsible for retrieving configuration settings from the system, but it fails to enforce proper authorization checks before returning sensitive data to the requester. The core technical issue is an incorrect authorization logic that allows unauthenticated or improperly authenticated users to access endpoints intended for administrative use only. By manipulating requests to this endpoint, an attacker can bypass security controls and retrieve application configurations that may contain secrets, keys, or other critical operational parameters necessary for maintaining system integrity.
This vulnerability falls under the category of broken access control, which is consistently ranked as a top threat in industry standards such as OWASP Top 10 and CWE-284 Improper Access Control. The lack of proper verification means that any remote actor with network connectivity to the service can exploit this flaw without needing prior valid credentials for administrative functions. This aligns with ATT&CK technique T1530, Data from Cloud Storage Object Discovery, as well as general reconnaissance patterns where attackers gather information about system configurations to plan further attacks. The ability to read these settings remotely significantly expands the attack surface, potentially leading to credential theft, service disruption, or deeper compromise of the underlying infrastructure depending on what sensitive data is exposed within those settings.
The operational impact of this vulnerability is severe due to its remote exploitability and public disclosure status. Since the exploit has been disclosed publicly, automated scanning tools and malicious actors can readily identify vulnerable instances in the wild. The exposure of configuration details may include OAuth client secrets, database connection strings, or internal API keys if they are stored within the settings payload. This information leakage facilitates subsequent attacks such as session hijacking, unauthorized data access, or privilege escalation. Although a previous patch referenced by PR #2558 and commit 53abc8b moved the OIDC secret into a dedicated setting to improve separation of concerns, it did not address the fundamental authorization gap in the GET /api/v1/settings endpoint itself. Consequently, even with that structural change, the underlying vulnerability remains active because the controller still permits unrestricted access to retrieve these newly isolated secrets alongside other settings.
To mitigate this risk, immediate action is required to apply the specific patch identified by commit hash 2b66ca6df8110f6b54c16b9fbe318f17. This patch addresses the authorization logic within the AppSettingController to ensure that only users with appropriate administrative privileges can invoke the getAppSettings method. Organizations should verify their current version and upgrade immediately if they are running any version up to 3.3.3 or 3.4.1. In addition to applying the software update, it is advisable to rotate any secrets or credentials that may have been exposed during the period of vulnerability. Implementing strict role-based access control checks at the API gateway level can also provide an additional layer of defense against unauthorized retrieval of sensitive configuration data. Regular security audits and penetration testing should be conducted to ensure no similar authorization flaws exist in other endpoints within the application architecture.