kiwitcms

Summary

In Kiwi TCMS the fields TestCase.extra_link and TestPlan.extra_link were meant to represent URLs to external resources however in versions prior to 16.1 user input was not being sanitized and values were rendered verbatim which represents an opportunity for cross-site scripting exploitation. In version 16.1 these fields are properly sanitized and existing database records which don't validate will be reset to a null value.

Impact

Deployments which use the official Docker images and/or unmodified Kiwi TCMS middleware send a Content-Security-Policy header which makes this vulnerability difficult to exploit in practice because this header blocks the browser from executing inline JavaScript. Customized deployments which modify the default security settings may still be vulnerable.

Summary

An open redirect vulnerability in the account confirmation endpoint allows an unauthenticated attacker to craft a URL hosted on a legitimate Kiwi TCMS instance that redirects victims to an arbitrary external domain. The attack surface is particularly relevant for phishing campaigns targeting Kiwi TCMS users, as the malicious link originates from a trusted organizational hostname.

Impact

This is an open redirect vulnerability (CWE-601). Any unauthenticated attacker can exploit it against any user of a Kiwi TCMS deployment.

The primary risk is phishing. Because Kiwi TCMS is typically deployed as an internal tool for engineering and QA teams, a redirect from the organization's own hostname carries high implicit trust. An attacker can use this endpoint to:

• Redirect victims to a credential-harvesting page styled to match the Kiwi TCMS or corporate SSO login.
• Bypass email security filters and link-reputation checks that allowlist the organization's domain.
• Distribute malware via a convincing "confirm your account" lure.

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:

• 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.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced changes which were meant to serve all uploaded files as plain text in order to prevent browsers from executing potentially dangerous files when such files are accessed directly!

The previous Nginx configuration was incorrect allowing certain browsers like Firefox to ignore the Content-Type: text/plain header on some occasions thus allowing potentially dangerous scripts to be executed.

Additionally file upload validators and parts of the HTML rendering code have been found to require additional sanitation and improvements.

Patches

• Updated Nginx content type configuration
• Improved file upload validation code to prevent more potentially dangerous uploads
• Sanitization of test plan names used in the tree_view_html() function

References

Disclosed by M Nadeem Qazi and Mahshooq Zubair.

Summary

In Kiwi TCMS the fields TestCase.extra_link and TestPlan.extra_link were meant to represent URLs to external resources however in versions prior to 16.1 user input was not being sanitized and values were rendered verbatim which represents an opportunity for cross-site scripting exploitation. In version 16.1 these fields are properly sanitized and existing database records which don't validate will be reset to a null value.

Impact

Deployments which use the official Docker images and/or unmodified Kiwi TCMS middleware send a Content-Security-Policy header which makes this vulnerability difficult to exploit in practice because this header blocks the browser from executing inline JavaScript. Customized deployments which modify the default security settings may still be vulnerable.

Summary

An open redirect vulnerability in the account confirmation endpoint allows an unauthenticated attacker to craft a URL hosted on a legitimate Kiwi TCMS instance that redirects victims to an arbitrary external domain. The attack surface is particularly relevant for phishing campaigns targeting Kiwi TCMS users, as the malicious link originates from a trusted organizational hostname.

Impact

This is an open redirect vulnerability (CWE-601). Any unauthenticated attacker can exploit it against any user of a Kiwi TCMS deployment.

The primary risk is phishing. Because Kiwi TCMS is typically deployed as an internal tool for engineering and QA teams, a redirect from the organization's own hostname carries high implicit trust. An attacker can use this endpoint to:

• Redirect victims to a credential-harvesting page styled to match the Kiwi TCMS or corporate SSO login.
• Bypass email security filters and link-reputation checks that allowlist the organization's domain.
• Distribute malware via a convincing "confirm your account" lure.

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:

• 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.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced changes which were meant to serve all uploaded files as plain text in order to prevent browsers from executing potentially dangerous files when such files are accessed directly!

The previous Nginx configuration was incorrect allowing certain browsers like Firefox to ignore the Content-Type: text/plain header on some occasions thus allowing potentially dangerous scripts to be executed.

Additionally file upload validators and parts of the HTML rendering code have been found to require additional sanitation and improvements.

Patches

• Updated Nginx content type configuration
• Improved file upload validation code to prevent more potentially dangerous uploads
• Sanitization of test plan names used in the tree_view_html() function

References

Disclosed by M Nadeem Qazi and Mahshooq Zubair.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded and Content-Security-Policy definition to prevent cross-site-scripting attacks.

The upload validation checks were not 100% robust which left the possibility to circumvent them and upload a potentially dangerous file which allows execution of arbitrary JavaScript in the browser. Additionally we've discovered that Nginx's proxy_pass directive will strip some headers negating protections built into Kiwi TCMS when served behind a reverse proxy.

Patches

• Improved file upload validation code
• Updated Nginx reverse proxy configuration for *.tenant.kiwitcms.org

Workarounds

If serving Kiwi TCMS behind a reverse proxy make sure that additional header values are still passed to the client browser. If they aren't redefine them inside the proxy configuration. See etc/nginx.conf#L66-L68 and etc/nginx.conf#L87

References

Disclosed by M Nadeem Qazi.

Summary

In Kiwi TCMS the fields TestCase.extra_link and TestPlan.extra_link were meant to represent URLs to external resources however in versions prior to 16.1 user input was not being sanitized and values were rendered verbatim which represents an opportunity for cross-site scripting exploitation. In version 16.1 these fields are properly sanitized and existing database records which don't validate will be reset to a null value.

Impact

Deployments which use the official Docker images and/or unmodified Kiwi TCMS middleware send a Content-Security-Policy header which makes this vulnerability difficult to exploit in practice because this header blocks the browser from executing inline JavaScript. Customized deployments which modify the default security settings may still be vulnerable.

Summary

An open redirect vulnerability in the account confirmation endpoint allows an unauthenticated attacker to craft a URL hosted on a legitimate Kiwi TCMS instance that redirects victims to an arbitrary external domain. The attack surface is particularly relevant for phishing campaigns targeting Kiwi TCMS users, as the malicious link originates from a trusted organizational hostname.

Impact

This is an open redirect vulnerability (CWE-601). Any unauthenticated attacker can exploit it against any user of a Kiwi TCMS deployment.

The primary risk is phishing. Because Kiwi TCMS is typically deployed as an internal tool for engineering and QA teams, a redirect from the organization's own hostname carries high implicit trust. An attacker can use this endpoint to:

• Redirect victims to a credential-harvesting page styled to match the Kiwi TCMS or corporate SSO login.
• Bypass email security filters and link-reputation checks that allowlist the organization's domain.
• Distribute malware via a convincing "confirm your account" lure.

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:

• 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.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced changes which were meant to serve all uploaded files as plain text in order to prevent browsers from executing potentially dangerous files when such files are accessed directly!

The previous Nginx configuration was incorrect allowing certain browsers like Firefox to ignore the Content-Type: text/plain header on some occasions thus allowing potentially dangerous scripts to be executed.

Additionally file upload validators and parts of the HTML rendering code have been found to require additional sanitation and improvements.

Patches

• Updated Nginx content type configuration
• Improved file upload validation code to prevent more potentially dangerous uploads
• Sanitization of test plan names used in the tree_view_html() function

References

Disclosed by M Nadeem Qazi and Mahshooq Zubair.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded and Content-Security-Policy definition to prevent cross-site-scripting attacks.

The upload validation checks were not 100% robust which left the possibility to circumvent them and upload a potentially dangerous file which allows execution of arbitrary JavaScript in the browser. Additionally we've discovered that Nginx's proxy_pass directive will strip some headers negating protections built into Kiwi TCMS when served behind a reverse proxy.

Patches

• Improved file upload validation code
• Updated Nginx reverse proxy configuration for *.tenant.kiwitcms.org

Workarounds

If serving Kiwi TCMS behind a reverse proxy make sure that additional header values are still passed to the client browser. If they aren't redefine them inside the proxy configuration. See etc/nginx.conf#L66-L68 and etc/nginx.conf#L87

References

Disclosed by M Nadeem Qazi.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded, see GHSA-fwcf-753v-fgcj and Content-Security-Policy definition to prevent cross-site-scripting attacks, see GHSA-2wcr-87wf-cf9j.

The upload validation checks were not robust enough which left the possibility of an attacker to circumvent them and upload a potentially dangerous file. Exploting this flaw a combination of files could be uploaded so that they work together to circumvent the existing Content-Security-Policy and allow execution of arbitrary JavaScript in the browser.

Patches

• File upload validation code has been improved
• Kiwi TCMS will now force Content-Type: text/plain when serving uploaded files

Workarounds

1. Force the Content-Type header via a custom Django middleware, see ExtraHeadersMiddleware in https://github.com/kiwitcms/Kiwi/blob/master/tcms/core/middleware.py#L23 and/or
2. Force the Content-Type header via Nginx overrides, see location /uploads/ in https://github.com/kiwitcms/Kiwi/blob/master/etc/nginx.conf

References

Disclosed by Antonio Spataro and ek1ng. Additional credits to Ahmed Rabeaa Mosa.

Kiwi TCMS is an open source test management system. In kiwitcms/Kiwi v12.2 and prior and kiwitcms/enterprise v12.2 and prior, the changelog.yml workflow is vulnerable to command injection attacks because of using an untrusted github.head_ref field. The github.head_ref value is an attacker-controlled value. Assigning the value to zzz";echo${IFS}"hello";# can lead to command injection. Since the permission is not restricted, the attacker has a write-access to the repository. Commit 834c86dfd1b2492ccad7ebbfd6304bfec895fed2 of the kiwitcms/Kiwi repository and commit e39f7e156fdaf6fec09a15ea6f4e8fec8cdbf751 of the kiwitcms/enterprise repository contain a fix for this issue.

Summary

In Kiwi TCMS the fields TestCase.extra_link and TestPlan.extra_link were meant to represent URLs to external resources however in versions prior to 16.1 user input was not being sanitized and values were rendered verbatim which represents an opportunity for cross-site scripting exploitation. In version 16.1 these fields are properly sanitized and existing database records which don't validate will be reset to a null value.

Impact

Deployments which use the official Docker images and/or unmodified Kiwi TCMS middleware send a Content-Security-Policy header which makes this vulnerability difficult to exploit in practice because this header blocks the browser from executing inline JavaScript. Customized deployments which modify the default security settings may still be vulnerable.

Summary

An open redirect vulnerability in the account confirmation endpoint allows an unauthenticated attacker to craft a URL hosted on a legitimate Kiwi TCMS instance that redirects victims to an arbitrary external domain. The attack surface is particularly relevant for phishing campaigns targeting Kiwi TCMS users, as the malicious link originates from a trusted organizational hostname.

Impact

This is an open redirect vulnerability (CWE-601). Any unauthenticated attacker can exploit it against any user of a Kiwi TCMS deployment.

The primary risk is phishing. Because Kiwi TCMS is typically deployed as an internal tool for engineering and QA teams, a redirect from the organization's own hostname carries high implicit trust. An attacker can use this endpoint to:

• Redirect victims to a credential-harvesting page styled to match the Kiwi TCMS or corporate SSO login.
• Bypass email security filters and link-reputation checks that allowlist the organization's domain.
• Distribute malware via a convincing "confirm your account" lure.

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:

• 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.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced changes which were meant to serve all uploaded files as plain text in order to prevent browsers from executing potentially dangerous files when such files are accessed directly!

The previous Nginx configuration was incorrect allowing certain browsers like Firefox to ignore the Content-Type: text/plain header on some occasions thus allowing potentially dangerous scripts to be executed.

Additionally file upload validators and parts of the HTML rendering code have been found to require additional sanitation and improvements.

Patches

• Updated Nginx content type configuration
• Improved file upload validation code to prevent more potentially dangerous uploads
• Sanitization of test plan names used in the tree_view_html() function

References

Disclosed by M Nadeem Qazi and Mahshooq Zubair.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded and Content-Security-Policy definition to prevent cross-site-scripting attacks.

The upload validation checks were not 100% robust which left the possibility to circumvent them and upload a potentially dangerous file which allows execution of arbitrary JavaScript in the browser. Additionally we've discovered that Nginx's proxy_pass directive will strip some headers negating protections built into Kiwi TCMS when served behind a reverse proxy.

Patches

• Improved file upload validation code
• Updated Nginx reverse proxy configuration for *.tenant.kiwitcms.org

Workarounds

If serving Kiwi TCMS behind a reverse proxy make sure that additional header values are still passed to the client browser. If they aren't redefine them inside the proxy configuration. See etc/nginx.conf#L66-L68 and etc/nginx.conf#L87

References

Disclosed by M Nadeem Qazi.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded, see GHSA-fwcf-753v-fgcj and Content-Security-Policy definition to prevent cross-site-scripting attacks, see GHSA-2wcr-87wf-cf9j.

The upload validation checks were not robust enough which left the possibility of an attacker to circumvent them and upload a potentially dangerous file. Exploting this flaw a combination of files could be uploaded so that they work together to circumvent the existing Content-Security-Policy and allow execution of arbitrary JavaScript in the browser.

Patches

• File upload validation code has been improved
• Kiwi TCMS will now force Content-Type: text/plain when serving uploaded files

Workarounds

1. Force the Content-Type header via a custom Django middleware, see ExtraHeadersMiddleware in https://github.com/kiwitcms/Kiwi/blob/master/tcms/core/middleware.py#L23 and/or
2. Force the Content-Type header via Nginx overrides, see location /uploads/ in https://github.com/kiwitcms/Kiwi/blob/master/etc/nginx.conf

References

Disclosed by Antonio Spataro and ek1ng. Additional credits to Ahmed Rabeaa Mosa.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. In earlier versions there is no control over what kinds of files can be uploaded. Thus a malicious actor may upload an .exe file or a file containing embedded JavaScript and trick others into clicking on these files causing vulnerable browsers to execute malicious code on another computer or attempting XSS attacks.

Stored XSS attacks via file uploads have been fixed in earlier versions of Kiwi TCMS, see GHSA-2wcr-87wf-cf9j. This advisory deals with prohibiting users to upload potentially compromised files in the first place.

Patches

Kiwi TCMS v12.2 comes with functionality that allows administrators to configure additional upload validator functions which give them more control over what file types are accepted for upload. By default .exe are denied. Other files containing the <script> tag, regardless of their type are also denied b/c they are a path to XSS attacks.

Workarounds

Upgrade to version 12.2 or later.

References

Originally reported by Ahmed Rabeaa Mosaa.

Impact

In previous versions of Kiwi TCMS users were able to update their email addresses via the "My profile" admin page. This page allowed them to change the email address registered with their account without the ownership verification performed during account registration.

Patches

With Kiwi TCMS v12.2 or later it is not possible to edit the email field associated with a user account!

Workarounds

No workaround exists.

References

Disclosed by @novemberdad.

Kiwi TCMS is an open source test management system. In kiwitcms/Kiwi v12.2 and prior and kiwitcms/enterprise v12.2 and prior, the changelog.yml workflow is vulnerable to command injection attacks because of using an untrusted github.head_ref field. The github.head_ref value is an attacker-controlled value. Assigning the value to zzz";echo${IFS}"hello";# can lead to command injection. Since the permission is not restricted, the attacker has a write-access to the repository. Commit 834c86dfd1b2492ccad7ebbfd6304bfec895fed2 of the kiwitcms/Kiwi repository and commit e39f7e156fdaf6fec09a15ea6f4e8fec8cdbf751 of the kiwitcms/enterprise repository contain a fix for this issue.

Summary

In Kiwi TCMS the fields TestCase.extra_link and TestPlan.extra_link were meant to represent URLs to external resources however in versions prior to 16.1 user input was not being sanitized and values were rendered verbatim which represents an opportunity for cross-site scripting exploitation. In version 16.1 these fields are properly sanitized and existing database records which don't validate will be reset to a null value.

Impact

Deployments which use the official Docker images and/or unmodified Kiwi TCMS middleware send a Content-Security-Policy header which makes this vulnerability difficult to exploit in practice because this header blocks the browser from executing inline JavaScript. Customized deployments which modify the default security settings may still be vulnerable.

Summary

An open redirect vulnerability in the account confirmation endpoint allows an unauthenticated attacker to craft a URL hosted on a legitimate Kiwi TCMS instance that redirects victims to an arbitrary external domain. The attack surface is particularly relevant for phishing campaigns targeting Kiwi TCMS users, as the malicious link originates from a trusted organizational hostname.

Impact

This is an open redirect vulnerability (CWE-601). Any unauthenticated attacker can exploit it against any user of a Kiwi TCMS deployment.

The primary risk is phishing. Because Kiwi TCMS is typically deployed as an internal tool for engineering and QA teams, a redirect from the organization's own hostname carries high implicit trust. An attacker can use this endpoint to:

• Redirect victims to a credential-harvesting page styled to match the Kiwi TCMS or corporate SSO login.
• Bypass email security filters and link-reputation checks that allowlist the organization's domain.
• Distribute malware via a convincing "confirm your account" lure.

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:

• 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.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced changes which were meant to serve all uploaded files as plain text in order to prevent browsers from executing potentially dangerous files when such files are accessed directly!

The previous Nginx configuration was incorrect allowing certain browsers like Firefox to ignore the Content-Type: text/plain header on some occasions thus allowing potentially dangerous scripts to be executed.

Additionally file upload validators and parts of the HTML rendering code have been found to require additional sanitation and improvements.

Patches

• Updated Nginx content type configuration
• Improved file upload validation code to prevent more potentially dangerous uploads
• Sanitization of test plan names used in the tree_view_html() function

References

Disclosed by M Nadeem Qazi and Mahshooq Zubair.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded and Content-Security-Policy definition to prevent cross-site-scripting attacks.

The upload validation checks were not 100% robust which left the possibility to circumvent them and upload a potentially dangerous file which allows execution of arbitrary JavaScript in the browser. Additionally we've discovered that Nginx's proxy_pass directive will strip some headers negating protections built into Kiwi TCMS when served behind a reverse proxy.

Patches

• Improved file upload validation code
• Updated Nginx reverse proxy configuration for *.tenant.kiwitcms.org

Workarounds

If serving Kiwi TCMS behind a reverse proxy make sure that additional header values are still passed to the client browser. If they aren't redefine them inside the proxy configuration. See etc/nginx.conf#L66-L68 and etc/nginx.conf#L87

References

Disclosed by M Nadeem Qazi.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded, see GHSA-fwcf-753v-fgcj and Content-Security-Policy definition to prevent cross-site-scripting attacks, see GHSA-2wcr-87wf-cf9j.

The upload validation checks were not robust enough which left the possibility of an attacker to circumvent them and upload a potentially dangerous file. Exploting this flaw a combination of files could be uploaded so that they work together to circumvent the existing Content-Security-Policy and allow execution of arbitrary JavaScript in the browser.

Patches

• File upload validation code has been improved
• Kiwi TCMS will now force Content-Type: text/plain when serving uploaded files

Workarounds

1. Force the Content-Type header via a custom Django middleware, see ExtraHeadersMiddleware in https://github.com/kiwitcms/Kiwi/blob/master/tcms/core/middleware.py#L23 and/or
2. Force the Content-Type header via Nginx overrides, see location /uploads/ in https://github.com/kiwitcms/Kiwi/blob/master/etc/nginx.conf

References

Disclosed by Antonio Spataro and ek1ng. Additional credits to Ahmed Rabeaa Mosa.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. In earlier versions there is no control over what kinds of files can be uploaded. Thus a malicious actor may upload an .exe file or a file containing embedded JavaScript and trick others into clicking on these files causing vulnerable browsers to execute malicious code on another computer or attempting XSS attacks.

Stored XSS attacks via file uploads have been fixed in earlier versions of Kiwi TCMS, see GHSA-2wcr-87wf-cf9j. This advisory deals with prohibiting users to upload potentially compromised files in the first place.

Patches

Kiwi TCMS v12.2 comes with functionality that allows administrators to configure additional upload validator functions which give them more control over what file types are accepted for upload. By default .exe are denied. Other files containing the <script> tag, regardless of their type are also denied b/c they are a path to XSS attacks.

Workarounds

Upgrade to version 12.2 or later.

References

Originally reported by Ahmed Rabeaa Mosaa.

Impact

In previous versions of Kiwi TCMS users were able to update their email addresses via the "My profile" admin page. This page allowed them to change the email address registered with their account without the ownership verification performed during account registration.

Patches

With Kiwi TCMS v12.2 or later it is not possible to edit the email field associated with a user account!

Workarounds

No workaround exists.

References

Disclosed by @novemberdad.

Impact

Kiwi TCMS accepts SVG files uploaded by users which could potentially contain JavaScript code. If SVG images are viewed directly, i.e. not rendered in an HTML page, this JavaScript code could execute.

Patches

This vulnerability has been fixed by configuring Kiwi TCMS to serve with the Content-Security-Policy HTTP header which blocks inline JavaScript in all modern browsers.

Workarounds

Configure Content-Security-Policy header, see commit 6617cee0.

References

You can visit https://digi.ninja/blog/svg_xss.php for more technical details.

Independently disclosed by Antonio Spataro and @1d8.

Kiwi TCMS is an open source test management system. In kiwitcms/Kiwi v12.2 and prior and kiwitcms/enterprise v12.2 and prior, the changelog.yml workflow is vulnerable to command injection attacks because of using an untrusted github.head_ref field. The github.head_ref value is an attacker-controlled value. Assigning the value to zzz";echo${IFS}"hello";# can lead to command injection. Since the permission is not restricted, the attacker has a write-access to the repository. Commit 834c86dfd1b2492ccad7ebbfd6304bfec895fed2 of the kiwitcms/Kiwi repository and commit e39f7e156fdaf6fec09a15ea6f4e8fec8cdbf751 of the kiwitcms/enterprise repository contain a fix for this issue.

Summary

In Kiwi TCMS the fields TestCase.extra_link and TestPlan.extra_link were meant to represent URLs to external resources however in versions prior to 16.1 user input was not being sanitized and values were rendered verbatim which represents an opportunity for cross-site scripting exploitation. In version 16.1 these fields are properly sanitized and existing database records which don't validate will be reset to a null value.

Impact

Deployments which use the official Docker images and/or unmodified Kiwi TCMS middleware send a Content-Security-Policy header which makes this vulnerability difficult to exploit in practice because this header blocks the browser from executing inline JavaScript. Customized deployments which modify the default security settings may still be vulnerable.

Summary

An open redirect vulnerability in the account confirmation endpoint allows an unauthenticated attacker to craft a URL hosted on a legitimate Kiwi TCMS instance that redirects victims to an arbitrary external domain. The attack surface is particularly relevant for phishing campaigns targeting Kiwi TCMS users, as the malicious link originates from a trusted organizational hostname.

Impact

This is an open redirect vulnerability (CWE-601). Any unauthenticated attacker can exploit it against any user of a Kiwi TCMS deployment.

The primary risk is phishing. Because Kiwi TCMS is typically deployed as an internal tool for engineering and QA teams, a redirect from the organization's own hostname carries high implicit trust. An attacker can use this endpoint to:

• Redirect victims to a credential-harvesting page styled to match the Kiwi TCMS or corporate SSO login.
• Bypass email security filters and link-reputation checks that allowlist the organization's domain.
• Distribute malware via a convincing "confirm your account" lure.

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:

• 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.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced changes which were meant to serve all uploaded files as plain text in order to prevent browsers from executing potentially dangerous files when such files are accessed directly!

The previous Nginx configuration was incorrect allowing certain browsers like Firefox to ignore the Content-Type: text/plain header on some occasions thus allowing potentially dangerous scripts to be executed.

Additionally file upload validators and parts of the HTML rendering code have been found to require additional sanitation and improvements.

Patches

• Updated Nginx content type configuration
• Improved file upload validation code to prevent more potentially dangerous uploads
• Sanitization of test plan names used in the tree_view_html() function

References

Disclosed by M Nadeem Qazi and Mahshooq Zubair.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded and Content-Security-Policy definition to prevent cross-site-scripting attacks.

The upload validation checks were not 100% robust which left the possibility to circumvent them and upload a potentially dangerous file which allows execution of arbitrary JavaScript in the browser. Additionally we've discovered that Nginx's proxy_pass directive will strip some headers negating protections built into Kiwi TCMS when served behind a reverse proxy.

Patches

• Improved file upload validation code
• Updated Nginx reverse proxy configuration for *.tenant.kiwitcms.org

Workarounds

If serving Kiwi TCMS behind a reverse proxy make sure that additional header values are still passed to the client browser. If they aren't redefine them inside the proxy configuration. See etc/nginx.conf#L66-L68 and etc/nginx.conf#L87

References

Disclosed by M Nadeem Qazi.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded, see GHSA-fwcf-753v-fgcj and Content-Security-Policy definition to prevent cross-site-scripting attacks, see GHSA-2wcr-87wf-cf9j.

The upload validation checks were not robust enough which left the possibility of an attacker to circumvent them and upload a potentially dangerous file. Exploting this flaw a combination of files could be uploaded so that they work together to circumvent the existing Content-Security-Policy and allow execution of arbitrary JavaScript in the browser.

Patches

• File upload validation code has been improved
• Kiwi TCMS will now force Content-Type: text/plain when serving uploaded files

Workarounds

1. Force the Content-Type header via a custom Django middleware, see ExtraHeadersMiddleware in https://github.com/kiwitcms/Kiwi/blob/master/tcms/core/middleware.py#L23 and/or
2. Force the Content-Type header via Nginx overrides, see location /uploads/ in https://github.com/kiwitcms/Kiwi/blob/master/etc/nginx.conf

References

Disclosed by Antonio Spataro and ek1ng. Additional credits to Ahmed Rabeaa Mosa.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. In earlier versions there is no control over what kinds of files can be uploaded. Thus a malicious actor may upload an .exe file or a file containing embedded JavaScript and trick others into clicking on these files causing vulnerable browsers to execute malicious code on another computer or attempting XSS attacks.

Stored XSS attacks via file uploads have been fixed in earlier versions of Kiwi TCMS, see GHSA-2wcr-87wf-cf9j. This advisory deals with prohibiting users to upload potentially compromised files in the first place.

Patches

Kiwi TCMS v12.2 comes with functionality that allows administrators to configure additional upload validator functions which give them more control over what file types are accepted for upload. By default .exe are denied. Other files containing the <script> tag, regardless of their type are also denied b/c they are a path to XSS attacks.

Workarounds

Upgrade to version 12.2 or later.

References

Originally reported by Ahmed Rabeaa Mosaa.

Impact

In previous versions of Kiwi TCMS users were able to update their email addresses via the "My profile" admin page. This page allowed them to change the email address registered with their account without the ownership verification performed during account registration.

Patches

With Kiwi TCMS v12.2 or later it is not possible to edit the email field associated with a user account!

Workarounds

No workaround exists.

References

Disclosed by @novemberdad.

Impact

Kiwi TCMS accepts SVG files uploaded by users which could potentially contain JavaScript code. If SVG images are viewed directly, i.e. not rendered in an HTML page, this JavaScript code could execute.

Patches

This vulnerability has been fixed by configuring Kiwi TCMS to serve with the Content-Security-Policy HTTP header which blocks inline JavaScript in all modern browsers.

Workarounds

Configure Content-Security-Policy header, see commit 6617cee0.

References

You can visit https://digi.ninja/blog/svg_xss.php for more technical details.

Independently disclosed by Antonio Spataro and @1d8.

Impact

Previous versions of Kiwi TCMS do not impose rate limits which makes it easier to attempt brute-force attacks against the login page.

Patches

Users should upgrade to v12.0 or later.

Workarounds

Users may install and configure a rate-limiting proxy in front of Kiwi TCMS. For example nginx.

References

Disclosed by spyata

Impact

Previous versions of Kiwi TCMS do not impose rate limits which makes it easier to attempt denial-of-service attacks against the Password reset page. An attacker could potentially send a large number of emails if they know the email addresses of users in Kiwi TCMS. Additionally that may strain SMTP resources.

Patches

Users should upgrade to v12.0 or later.

Workarounds

Users may install and configure a rate-limiting proxy in front of Kiwi TCMS such as Nginx and/or configure rate limits on their email server when possible.

References

Disclosed by Ahmed Rabeaa Mosaa

Kiwi TCMS is an open source test management system. In kiwitcms/Kiwi v12.2 and prior and kiwitcms/enterprise v12.2 and prior, the changelog.yml workflow is vulnerable to command injection attacks because of using an untrusted github.head_ref field. The github.head_ref value is an attacker-controlled value. Assigning the value to zzz";echo${IFS}"hello";# can lead to command injection. Since the permission is not restricted, the attacker has a write-access to the repository. Commit 834c86dfd1b2492ccad7ebbfd6304bfec895fed2 of the kiwitcms/Kiwi repository and commit e39f7e156fdaf6fec09a15ea6f4e8fec8cdbf751 of the kiwitcms/enterprise repository contain a fix for this issue.

Summary

In Kiwi TCMS the fields TestCase.extra_link and TestPlan.extra_link were meant to represent URLs to external resources however in versions prior to 16.1 user input was not being sanitized and values were rendered verbatim which represents an opportunity for cross-site scripting exploitation. In version 16.1 these fields are properly sanitized and existing database records which don't validate will be reset to a null value.

Impact

Deployments which use the official Docker images and/or unmodified Kiwi TCMS middleware send a Content-Security-Policy header which makes this vulnerability difficult to exploit in practice because this header blocks the browser from executing inline JavaScript. Customized deployments which modify the default security settings may still be vulnerable.

Summary

An open redirect vulnerability in the account confirmation endpoint allows an unauthenticated attacker to craft a URL hosted on a legitimate Kiwi TCMS instance that redirects victims to an arbitrary external domain. The attack surface is particularly relevant for phishing campaigns targeting Kiwi TCMS users, as the malicious link originates from a trusted organizational hostname.

Impact

This is an open redirect vulnerability (CWE-601). Any unauthenticated attacker can exploit it against any user of a Kiwi TCMS deployment.

The primary risk is phishing. Because Kiwi TCMS is typically deployed as an internal tool for engineering and QA teams, a redirect from the organization's own hostname carries high implicit trust. An attacker can use this endpoint to:

• Redirect victims to a credential-harvesting page styled to match the Kiwi TCMS or corporate SSO login.
• Bypass email security filters and link-reputation checks that allowlist the organization's domain.
• Distribute malware via a convincing "confirm your account" lure.

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:

• 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.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced changes which were meant to serve all uploaded files as plain text in order to prevent browsers from executing potentially dangerous files when such files are accessed directly!

The previous Nginx configuration was incorrect allowing certain browsers like Firefox to ignore the Content-Type: text/plain header on some occasions thus allowing potentially dangerous scripts to be executed.

Additionally file upload validators and parts of the HTML rendering code have been found to require additional sanitation and improvements.

Patches

• Updated Nginx content type configuration
• Improved file upload validation code to prevent more potentially dangerous uploads
• Sanitization of test plan names used in the tree_view_html() function

References

Disclosed by M Nadeem Qazi and Mahshooq Zubair.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded and Content-Security-Policy definition to prevent cross-site-scripting attacks.

The upload validation checks were not 100% robust which left the possibility to circumvent them and upload a potentially dangerous file which allows execution of arbitrary JavaScript in the browser. Additionally we've discovered that Nginx's proxy_pass directive will strip some headers negating protections built into Kiwi TCMS when served behind a reverse proxy.

Patches

• Improved file upload validation code
• Updated Nginx reverse proxy configuration for *.tenant.kiwitcms.org

Workarounds

If serving Kiwi TCMS behind a reverse proxy make sure that additional header values are still passed to the client browser. If they aren't redefine them inside the proxy configuration. See etc/nginx.conf#L66-L68 and etc/nginx.conf#L87

References

Disclosed by M Nadeem Qazi.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded, see GHSA-fwcf-753v-fgcj and Content-Security-Policy definition to prevent cross-site-scripting attacks, see GHSA-2wcr-87wf-cf9j.

The upload validation checks were not robust enough which left the possibility of an attacker to circumvent them and upload a potentially dangerous file. Exploting this flaw a combination of files could be uploaded so that they work together to circumvent the existing Content-Security-Policy and allow execution of arbitrary JavaScript in the browser.

Patches

• File upload validation code has been improved
• Kiwi TCMS will now force Content-Type: text/plain when serving uploaded files

Workarounds

1. Force the Content-Type header via a custom Django middleware, see ExtraHeadersMiddleware in https://github.com/kiwitcms/Kiwi/blob/master/tcms/core/middleware.py#L23 and/or
2. Force the Content-Type header via Nginx overrides, see location /uploads/ in https://github.com/kiwitcms/Kiwi/blob/master/etc/nginx.conf

References

Disclosed by Antonio Spataro and ek1ng. Additional credits to Ahmed Rabeaa Mosa.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. In earlier versions there is no control over what kinds of files can be uploaded. Thus a malicious actor may upload an .exe file or a file containing embedded JavaScript and trick others into clicking on these files causing vulnerable browsers to execute malicious code on another computer or attempting XSS attacks.

Stored XSS attacks via file uploads have been fixed in earlier versions of Kiwi TCMS, see GHSA-2wcr-87wf-cf9j. This advisory deals with prohibiting users to upload potentially compromised files in the first place.

Patches

Kiwi TCMS v12.2 comes with functionality that allows administrators to configure additional upload validator functions which give them more control over what file types are accepted for upload. By default .exe are denied. Other files containing the <script> tag, regardless of their type are also denied b/c they are a path to XSS attacks.

Workarounds

Upgrade to version 12.2 or later.

References

Originally reported by Ahmed Rabeaa Mosaa.

Impact

In previous versions of Kiwi TCMS users were able to update their email addresses via the "My profile" admin page. This page allowed them to change the email address registered with their account without the ownership verification performed during account registration.

Patches

With Kiwi TCMS v12.2 or later it is not possible to edit the email field associated with a user account!

Workarounds

No workaround exists.

References

Disclosed by @novemberdad.

Impact

Kiwi TCMS accepts SVG files uploaded by users which could potentially contain JavaScript code. If SVG images are viewed directly, i.e. not rendered in an HTML page, this JavaScript code could execute.

Patches

This vulnerability has been fixed by configuring Kiwi TCMS to serve with the Content-Security-Policy HTTP header which blocks inline JavaScript in all modern browsers.

Workarounds

Configure Content-Security-Policy header, see commit 6617cee0.

References

You can visit https://digi.ninja/blog/svg_xss.php for more technical details.

Independently disclosed by Antonio Spataro and @1d8.

Impact

Previous versions of Kiwi TCMS do not impose rate limits which makes it easier to attempt brute-force attacks against the login page.

Patches

Users should upgrade to v12.0 or later.

Workarounds

Users may install and configure a rate-limiting proxy in front of Kiwi TCMS. For example nginx.

References

Disclosed by spyata

Impact

Previous versions of Kiwi TCMS do not impose rate limits which makes it easier to attempt denial-of-service attacks against the Password reset page. An attacker could potentially send a large number of emails if they know the email addresses of users in Kiwi TCMS. Additionally that may strain SMTP resources.

Patches

Users should upgrade to v12.0 or later.

Workarounds

Users may install and configure a rate-limiting proxy in front of Kiwi TCMS such as Nginx and/or configure rate limits on their email server when possible.

References

Disclosed by Ahmed Rabeaa Mosaa

Kiwi TCMS is an open source test management system. In kiwitcms/Kiwi v12.2 and prior and kiwitcms/enterprise v12.2 and prior, the changelog.yml workflow is vulnerable to command injection attacks because of using an untrusted github.head_ref field. The github.head_ref value is an attacker-controlled value. Assigning the value to zzz";echo${IFS}"hello";# can lead to command injection. Since the permission is not restricted, the attacker has a write-access to the repository. Commit 834c86dfd1b2492ccad7ebbfd6304bfec895fed2 of the kiwitcms/Kiwi repository and commit e39f7e156fdaf6fec09a15ea6f4e8fec8cdbf751 of the kiwitcms/enterprise repository contain a fix for this issue.

Summary

In Kiwi TCMS the fields TestCase.extra_link and TestPlan.extra_link were meant to represent URLs to external resources however in versions prior to 16.1 user input was not being sanitized and values were rendered verbatim which represents an opportunity for cross-site scripting exploitation. In version 16.1 these fields are properly sanitized and existing database records which don't validate will be reset to a null value.

Impact

Deployments which use the official Docker images and/or unmodified Kiwi TCMS middleware send a Content-Security-Policy header which makes this vulnerability difficult to exploit in practice because this header blocks the browser from executing inline JavaScript. Customized deployments which modify the default security settings may still be vulnerable.

Summary

An open redirect vulnerability in the account confirmation endpoint allows an unauthenticated attacker to craft a URL hosted on a legitimate Kiwi TCMS instance that redirects victims to an arbitrary external domain. The attack surface is particularly relevant for phishing campaigns targeting Kiwi TCMS users, as the malicious link originates from a trusted organizational hostname.

Impact

This is an open redirect vulnerability (CWE-601). Any unauthenticated attacker can exploit it against any user of a Kiwi TCMS deployment.

The primary risk is phishing. Because Kiwi TCMS is typically deployed as an internal tool for engineering and QA teams, a redirect from the organization's own hostname carries high implicit trust. An attacker can use this endpoint to:

• Redirect victims to a credential-harvesting page styled to match the Kiwi TCMS or corporate SSO login.
• Bypass email security filters and link-reputation checks that allowlist the organization's domain.
• Distribute malware via a convincing "confirm your account" lure.

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:

• 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.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced changes which were meant to serve all uploaded files as plain text in order to prevent browsers from executing potentially dangerous files when such files are accessed directly!

The previous Nginx configuration was incorrect allowing certain browsers like Firefox to ignore the Content-Type: text/plain header on some occasions thus allowing potentially dangerous scripts to be executed.

Additionally file upload validators and parts of the HTML rendering code have been found to require additional sanitation and improvements.

Patches

• Updated Nginx content type configuration
• Improved file upload validation code to prevent more potentially dangerous uploads
• Sanitization of test plan names used in the tree_view_html() function

References

Disclosed by M Nadeem Qazi and Mahshooq Zubair.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded and Content-Security-Policy definition to prevent cross-site-scripting attacks.

The upload validation checks were not 100% robust which left the possibility to circumvent them and upload a potentially dangerous file which allows execution of arbitrary JavaScript in the browser. Additionally we've discovered that Nginx's proxy_pass directive will strip some headers negating protections built into Kiwi TCMS when served behind a reverse proxy.

Patches

• Improved file upload validation code
• Updated Nginx reverse proxy configuration for *.tenant.kiwitcms.org

Workarounds

If serving Kiwi TCMS behind a reverse proxy make sure that additional header values are still passed to the client browser. If they aren't redefine them inside the proxy configuration. See etc/nginx.conf#L66-L68 and etc/nginx.conf#L87

References

Disclosed by M Nadeem Qazi.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded, see GHSA-fwcf-753v-fgcj and Content-Security-Policy definition to prevent cross-site-scripting attacks, see GHSA-2wcr-87wf-cf9j.

The upload validation checks were not robust enough which left the possibility of an attacker to circumvent them and upload a potentially dangerous file. Exploting this flaw a combination of files could be uploaded so that they work together to circumvent the existing Content-Security-Policy and allow execution of arbitrary JavaScript in the browser.

Patches

• File upload validation code has been improved
• Kiwi TCMS will now force Content-Type: text/plain when serving uploaded files

Workarounds

1. Force the Content-Type header via a custom Django middleware, see ExtraHeadersMiddleware in https://github.com/kiwitcms/Kiwi/blob/master/tcms/core/middleware.py#L23 and/or
2. Force the Content-Type header via Nginx overrides, see location /uploads/ in https://github.com/kiwitcms/Kiwi/blob/master/etc/nginx.conf

References

Disclosed by Antonio Spataro and ek1ng. Additional credits to Ahmed Rabeaa Mosa.

Impact

Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. In earlier versions there is no control over what kinds of files can be uploaded. Thus a malicious actor may upload an .exe file or a file containing embedded JavaScript and trick others into clicking on these files causing vulnerable browsers to execute malicious code on another computer or attempting XSS attacks.

Stored XSS attacks via file uploads have been fixed in earlier versions of Kiwi TCMS, see GHSA-2wcr-87wf-cf9j. This advisory deals with prohibiting users to upload potentially compromised files in the first place.

Patches

Kiwi TCMS v12.2 comes with functionality that allows administrators to configure additional upload validator functions which give them more control over what file types are accepted for upload. By default .exe are denied. Other files containing the <script> tag, regardless of their type are also denied b/c they are a path to XSS attacks.

Workarounds

Upgrade to version 12.2 or later.

References

Originally reported by Ahmed Rabeaa Mosaa.

Impact

In previous versions of Kiwi TCMS users were able to update their email addresses via the "My profile" admin page. This page allowed them to change the email address registered with their account without the ownership verification performed during account registration.

Patches

With Kiwi TCMS v12.2 or later it is not possible to edit the email field associated with a user account!

Workarounds

No workaround exists.

References

Disclosed by @novemberdad.