CVE-2026-49292 in Kiwi
Summary
by MITRE • 09/17/2026
Kiwi TCMS is an open source test management system. Prior to 16.0, the unauthenticated /init-db/ page handled by InitDBView in tcms/core/views.py remains reachable after initial setup and proxies repeated requests to Kiwi/manage.py migrate. The migration command is reentrant, so repeated access reports that no migrations are available and does not cause data loss, alter application state, reveal confidential information, or produce a documented availability impact. This issue is fixed in version 16.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in Kiwi TCMS prior to version 16.0 centers on the improper handling of the database initialization endpoint within the web application's core view logic. Specifically, the /init-db/ page, which is managed by the InitDBView class located in tcms/core/views.py, remains accessible and functional even after the initial system setup has been completed. This architectural oversight allows unauthenticated users to repeatedly access this specific URL path without encountering an authentication barrier or a proper state check that would typically prevent re-execution of initialization routines on a configured instance.
From a technical perspective, the core flaw lies in the interaction between the web view and the Django management command migrate. When the /init-db/ endpoint is accessed, it proxies requests to Kiwi/manage.py migrate. While the migration process itself is designed to be idempotent or reentrant—meaning that running migrations multiple times does not alter existing data structures if they are already up-to-date—the mere availability of this entry point represents a deviation from secure configuration principles. The system fails to enforce a state-based restriction that would disable or redirect this endpoint once the database schema has been initialized, leaving it exposed to continuous probing by external actors.
In terms of operational impact and security classification, this issue is categorized as having low severity due to its benign nature regarding data integrity and confidentiality. Because the migration command detects that no new migrations are available upon repeated execution, it simply reports that there is nothing to do without causing any side effects. There is no risk of data loss, unauthorized alteration of application state, or exposure of sensitive information such as credentials or internal system details. Furthermore, while an attacker could theoretically generate a high volume of requests to this endpoint, the documentation indicates that this does not result in a documented availability impact, suggesting that the resource consumption associated with these harmless no-op migrations is negligible and unlikely to lead to denial-of-service conditions under normal circumstances.
Despite the lack of direct exploitability for data compromise or service disruption, the presence of an unauthenticated administrative-adjacent endpoint violates best practices for secure application design and defense in depth. It exposes internal implementation details regarding the use of Django's migration framework and provides a potential surface area for future vulnerabilities if the underlying logic changes. From a standards perspective, this aligns with CWE-284 Improper Access Control, as the system fails to restrict access to functionality that should be limited to post-initialization states or authenticated contexts. Additionally, it relates to ATT&CK technique T1078 Valid Accounts in the context of misconfiguration, where an attacker might use such endpoints for reconnaissance or persistence if combined with other flaws, although here it serves primarily as a configuration weakness rather than a direct attack vector.
To mitigate this vulnerability and align with secure coding standards, organizations running Kiwi TCMS versions prior to 16.0 should upgrade immediately to version 16.0 where the issue has been resolved. The fix likely involves modifying the InitDBView logic to check the current state of the database or application configuration before allowing access to the initialization routine. If upgrading is not immediately feasible, administrators can implement a temporary workaround by configuring their web server or reverse proxy to block requests to the /init-db/ path for all users after the initial setup is confirmed complete. This ensures that even if the internal logic remains flawed, external actors cannot interact with the endpoint, thereby closing the information disclosure and potential future exploitation vector associated with this misconfiguration.