Vulnerability PYSEC-2026-2553

Unknown

3 months ago

Kiwi TCMS's /init-db/ page renders and responds to requests after first use

6.2.1 and 6.3 and 6.4 and 6.5 and 6.5.3 and 6.6 and 6.7 and 6.8 and 6.9 and 6.10 and 6.11 and 7.0 and 7.1 and 7.2 and 7.2.1 and 7.3 and 8.0 and 8.1 and 8.1.99 and 8.2 and 8.3 and 8.4 and 8.5 and 8.6 and 8.6.1 and 8.7 and 8.8 and 8.9 and 9.0 and 9.999 and 10.0 and 10.1 and 10.2 and 10.3 and 10.3.999 and 10.4 and 10.5 and 11.0 and 11.1 and 11.3 and 11.4 and 11.5 and 11.6 and 11.7 and 12.0 and 12.1 and 12.2 and 12.3 and 12.4

Summary

Kiwi TCMS's /init-db/ page renders and responds to requests after first use

Details

Kiwi TCMS provides the /init-db/ page as part of its setup mechanism for administrators who prefer a browser instead of the command line. In previous versions of Kiwi TCMS this page still renders and responds to requests even after first use.

Impact

The /init-db/ page does not require any user authentication because it is the first setup operation that needs to be executed in order for Kiwi TCMS to function. Database initialization happens before there are any user accounts available!

While that looks serious at first the /init-db/ page is merely a proxy behind the /Kiwi/manage.py migrate command, which itself is designed to be reentrant. In the case of repeated access to the /init-db/ page after first use the output is:

Running migrations:
  No migrations to apply.

as shown on the screenshots below:

2222 3333

There is no data loss because migrations result in a no-op if they are already applied!
No application state is altered because all state changes have already been applied!
No confidential information revealed because database migrations only report status on migrations which are clearly visible in source code!

Remediation

The /init-db/ page has been modified to short-circuit itself if migrations have already been applied, resulting in a no-op on the webUI layer as well.