CVE-2026-29788: Wikitide Tsportal Auth Bypass Vulnerability

CVE-2026-29788 Overview

CVE-2026-29788 is a high-severity authorization bypass vulnerability in WikiTide Foundation's TSPortal platform, an internal tool used by the Trust and Safety team to manage reports, investigations, appeals, and transparency work. Prior to version 30, the application incorrectly converts empty strings to null values, which allows malicious actors to disguise Data Protection Act (DPA) reports as legitimate self-deletion reports. This vulnerability undermines the integrity of the Trust and Safety workflow by enabling report classification manipulation.

Critical Impact

Attackers can manipulate report classifications by exploiting the empty string to null conversion flaw, potentially disguising DPA-related reports as self-deletion requests. This could lead to improper handling of sensitive user data requests, compliance violations, and erosion of trust in the platform's report management processes.

Affected Products

• WikiTide TSPortal versions prior to 30

Discovery Timeline

• 2026-03-06 - CVE CVE-2026-29788 published to NVD
• 2026-03-11 - Last updated in NVD database

Technical Details for CVE-2026-29788

Vulnerability Analysis

This vulnerability falls under CWE-283 (Unverified Ownership), where the application fails to properly verify and maintain the integrity of report type classifications. The root issue stems from how TSPortal handles empty string inputs during report processing. When certain fields are submitted as empty strings, the application incorrectly converts these to null values, effectively stripping critical metadata that distinguishes between different report types.

In the context of TSPortal's workflow, DPA reports and self-deletion reports serve fundamentally different purposes and require distinct handling procedures. DPA reports typically involve regulatory compliance considerations and may require specific documentation and audit trails, while self-deletion requests follow a different processing path. By exploiting this conversion behavior, an attacker can submit a DPA report that appears to the system as a self-deletion request, bypassing the appropriate review and compliance workflows.

Root Cause

The vulnerability originates from improper input validation and type coercion logic within TSPortal's report handling mechanism. The application's data processing layer converts empty string values ("") to null without validating whether this conversion is appropriate for the specific field context. This behavior affects fields that are used to differentiate between report types, allowing the report classification to be altered through carefully crafted input.

Attack Vector

The attack can be executed over the network without requiring authentication, though user interaction is needed. An attacker would craft a report submission with specific fields set to empty strings, exploiting the conversion behavior to alter how the report is classified and subsequently processed by the Trust and Safety team. The attack flow involves:

1. Identifying which input fields control report type classification
2. Submitting a DPA report with those fields set to empty strings
3. The application converts empty strings to null values
4. The report is misclassified as a self-deletion request
5. The report bypasses DPA-specific compliance workflows

The vulnerability mechanism involves the application's data layer performing unsafe type coercion. When report fields are submitted as empty strings, the backend converts these to null values. This null state then causes the report classification logic to default to an incorrect report type, effectively masking the true nature of the submitted report. For detailed technical information, refer to the GitHub Security Advisory and the Miraheze Issue Tracker Entry.

Detection Methods for CVE-2026-29788

Indicators of Compromise

• Unusual patterns of self-deletion reports that may contain characteristics inconsistent with typical self-deletion requests
• Reports with null values in classification-related fields that should contain explicit type identifiers
• Discrepancies between reported actions and actual user requests in audit logs
• Elevated volume of self-deletion reports compared to historical baselines

Detection Strategies

• Implement logging and alerting for reports where empty string to null conversion occurs on classification fields
• Monitor for sudden changes in report type distribution ratios
• Review audit trails for reports that were reclassified or had type fields modified during processing
• Deploy integrity checks that flag reports with missing or null classification metadata

Monitoring Recommendations

• Enable detailed logging for all report submission and classification events
• Configure alerts for anomalous patterns in report type distributions
• Implement periodic audits comparing submitted report content against assigned classifications
• Monitor database queries for null-based filtering on report type fields

How to Mitigate CVE-2026-29788

Immediate Actions Required

• Upgrade TSPortal to version 30 or later immediately
• Review existing reports submitted prior to the patch for potential misclassification
• Audit self-deletion reports processed recently to identify any disguised DPA reports
• Enable enhanced logging to detect exploitation attempts

Patch Information

WikiTide has released version 30 of TSPortal which addresses this vulnerability. The patch corrects the empty string to null conversion behavior, ensuring that report type classification fields maintain their integrity and cannot be manipulated through specially crafted input. Organizations should upgrade to this patched version immediately. Additional details are available in the GitHub Security Advisory.

Workarounds

• Implement server-side validation that explicitly rejects empty strings in report type classification fields
• Add database constraints to prevent null values in fields that determine report classification
• Deploy a middleware layer that validates report submissions before they reach the core application
• Establish manual review processes for reports with unusual field patterns until the patch can be applied

# Configuration example - Input validation middleware
# Add validation rules to reject empty strings in classification fields
# Ensure report_type and related fields require explicit non-empty values
# Enable strict mode for report submission endpoints