CVE-2026-111914 in Admidio
Summary
by MITRE • 10/17/2026
Admidio from 5.0.11 before 5.0.16 contains a broken access control vulnerability in modules/inventory/inventory_data.php that allows authenticated users to bypass the inventory_module_enabled restriction. Attackers with any valid login can request the DataTables JSON feed to read every inventory item and keeper names, even when the module is disabled.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
The identified vulnerability represents a critical failure in access control mechanisms within Admidio versions 5.0.11 through 5.0.16, specifically residing in the file modules/inventory/inventory_data.php. This flaw allows authenticated users to bypass administrative restrictions that are intended to disable specific functional modules. In typical web application architectures, module-level permissions should act as a gatekeeper for all associated endpoints and data feeds. However, in this instance, the server-side logic fails to verify whether the inventory module is enabled before processing requests directed at its underlying data structures. This architectural oversight means that the security boundary defined by the administrative configuration setting is effectively ignored during runtime execution of specific API-like functions within the application.
From a technical perspective, the vulnerability manifests when an authenticated user sends a request to retrieve JSON-formatted data via the DataTables interface associated with the inventory module. Normally, if the inventory_module_enabled flag is set to false by an administrator, any attempt to access this functionality should result in an authorization error or a redirect to a generic landing page indicating that the feature is unavailable. Instead, the application proceeds to query the database and return sensitive information regardless of this configuration state. This behavior indicates a lack of centralized permission checking for module-specific endpoints, where individual script files do not inherit or respect global module status flags during their execution lifecycle.
The operational impact of this vulnerability is significant due to the nature of the data exposed. By exploiting this broken access control mechanism, an attacker with any valid user account can extract comprehensive details about every inventory item stored in the system. This includes sensitive identifiers and potentially proprietary information related to organizational assets. Furthermore, the attack vector reveals keeper names associated with these items, which constitutes a privacy violation and aids in social engineering attacks against specific individuals within the organization. The ability to enumerate all records without restriction also facilitates further reconnaissance, allowing attackers to map out internal structures and identify high-value targets for subsequent exploitation attempts.
This vulnerability aligns closely with CWE-284, Improper Access Control, as it involves a failure to enforce proper restrictions on authenticated users regarding specific application functions. Additionally, the technique of accessing hidden or disabled features through direct object reference manipulation corresponds to MITRE ATT&CK tactic T1078, Valid Accounts, specifically within the context of exploiting misconfigured permissions. The exploitation does not require complex payload construction but relies instead on correctly formatted HTTP requests that target the specific JSON endpoint while bypassing logical checks for module availability.
Mitigation strategies must prioritize immediate patching to version 5.0.16 or later, where this logic error has been addressed by developers. In environments where upgrading is not immediately feasible, administrators should implement strict input validation and ensure that all module-specific endpoints explicitly check the global configuration state before processing requests. Web Application Firewalls can be configured to detect anomalous access patterns to disabled modules, although such controls are secondary to fixing the root cause in the application code. Regular security audits focusing on permission inheritance across modular components are recommended to prevent similar architectural flaws from persisting in future releases or other parts of the system.