CVE-2026-77433: Kiwi TCMS account confirmation open redirect through protocol-relative URLs
Summary
In Kiwi TCMS version 16.1, the fix for CVE-2026-54724 (open redirect via unvalidated next parameter) in the account confirmation endpoint is incomplete. The validation uses startswith("/") to check if the redirect URL is local, but this is bypassed by protocol-relative URLs like //evil.com which start with / but redirect the browser to an external attacker-controlled domain. 16.1’s incomplete mitigation still allows protocol-relative destinations and earlier releases lack the mitigation.
Vulnerable Code
In tcms/kiwiauth/views.py, the Confirm view (line ~113):
def getredirecturl(self, args, kwargs): self.url = self.request.GET.get("next", reverse("core-views-index")) if not self.url.startswith("/"): self.url = reverse("core-views-index")
The check startswith("/") passes for //evil.com because it begins with /, but browsers interpret //evil.com as a protocol-relative URL that redirects to https://evil.com (or http://evil.com depending on the current page's protocol).
Proof of Concept
GET /confirm/<activationkey>/?next=//evil.com/phishing HTTP/1.1 Host: kiwi.example.com
Response:
HTTP/1.1 302 Found Location: //evil.com/phishing
The browser follows the redirect to https://evil.com/phishing.
Verification:
>>> url = "//evil.com/phishing" >>> url.startswith("/") True # passes the check!
Impact
An attacker can craft a confirmation link that, after the user confirms their account, redirects them to a phishing page. This is useful for:
- Credential phishing (fake login page on attacker domain) - Malware delivery after trusted action - Social engineering (user trusts the link because it's from the legitimate Kiwi TCMS instance)
The attack requires sending a crafted activation link to a user who is registering, or intercepting/predicting the activation key.
Suggested Fix
Use Django's urlhasallowedhostandscheme() utility instead of a simple startswith check:
from django.utils.http import urlhasallowedhostandscheme
def getredirecturl(self, args, kwargs): self.url = self.request.GET.get("next", reverse("core-views-index")) if not urlhasallowedhostandscheme( self.url, allowedhosts={self.request.gethost()}, requirehttps=self.request.issecure(), ): self.url = reverse("core-views-index")
This properly rejects protocol-relative URLs, absolute URLs to other hosts, and other bypass patterns.
Fixed in Version 16.2
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Kiwi TCMSto a version that resolves this vulnerability.Fixed in 16.2
Event History
Frequently Asked Questions
Does the earlier redirect validation in version 16.1 prevent this issue?
No. Version 16.1 checks only whether the destination starts with a slash, so a value such as //evil.com/phishing passes validation and is interpreted by browsers as an external destination. Earlier releases lack this mitigation entirely.
What does an attacker need to exploit this?
An attacker can supply a protocol-relative value in the next parameter, such as //evil.com/phishing, in a link to the account confirmation endpoint. Exploitation requires a victim to follow that link; no attacker authentication is required.
How can I verify whether an instance is vulnerable?
Request the confirmation endpoint with a next value beginning with two slashes and observe the redirect response. An affected instance returns a 302 response with a Location header such as //evil.com/phishing rather than replacing it with the local index destination.