CVE-2026-33541: 
PHP vulnerability analysis and mitigation

CVE-2026-33541 is a denial-of-service vulnerability in TSPortal, the WikiTide Foundation's in-house platform used by the Trust and Safety team to manage reports, investigations, appeals, and transparency work. A flaw in validation logic allows authenticated attackers to cause uncontrolled database growth by triggering arbitrary user record creation as a side effect of failed validation. All versions prior to v34 (i.e., <= v33) of the miraheze/ts-portal Composer package are affected. The advisory was published on March 23, 2026, and the CVE was assigned on March 26, 2026. The CVSS v3.1 base score is 6.5 (Medium) (GitHub Advisory, Miraheze Advisory).

The root cause is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). When a Data Processing Agreement (DPA) request is submitted, the DPAAlreadyLive validation rule invoked User::findOrCreate(), a state-changing database operation that creates a user record if one does not already exist. Although the MirahezeUsernameRule correctly rejected invalid usernames, the DPAAlreadyLive rule still executed during the validation pipeline — before the overall validation result was evaluated — causing user records to be persisted even when the request ultimately failed. This architectural flaw (performing write operations inside validation logic) meant that an attacker with low-level authenticated access could automate repeated DPA submissions with invalid usernames to continuously insert orphaned user records into the database without any audit trail (Miraheze Advisory).

Successful exploitation results in mass creation of arbitrary, unaudited user records in the TSPortal database, leading to unbounded database growth, increased storage and indexing overhead, and potential degradation of application performance. At scale, this constitutes a denial-of-service condition through resource exhaustion. There is no confidentiality or integrity impact; the vulnerability is limited to availability (Miraheze Advisory, GitHub Advisory).

A proof-of-concept (PoC) with concrete reproduction steps is publicly documented in the official security advisory, describing a three-step process to trigger the vulnerability (Miraheze Advisory). Exploitation requires low-privilege authenticated access over the network, with low attack complexity and no user interaction. The EPSS score is approximately 0.039–0.066%, indicating a low probability of exploitation in the wild within 30 days. There is no evidence of active in-the-wild exploitation, no known threat actor attribution, and the vulnerability is not listed in the CISA KEV catalog (GitHub Advisory).

1. Authenticate: Obtain low-privilege authenticated access to a TSPortal instance running version 33 or earlier.
2. Craft a malicious DPA request: Prepare an HTTP request to submit a Data Processing Agreement (DPA) with an intentionally invalid username (one that will fail MirahezeUsernameRule validation).
3. Submit the request: Send the crafted DPA request to the TSPortal application endpoint. The DPAAlreadyLive validation rule will invoke User::findOrCreate() as a side effect before overall validation fails.
4. Observe side effect: Although the DPA request is rejected due to the invalid username, a corresponding user record is silently created in the database without audit logging.
5. Automate for DoS: Script or automate repeated submissions with varying invalid usernames to continuously insert orphaned user records, causing unbounded database growth and eventual resource exhaustion leading to denial of service (Miraheze Advisory).

• Database: Rapid or anomalous growth in the users table with records lacking associated DPA entries, audit log entries, or traceable origin; user records with invalid or malformed usernames.
• Logs: High volume of failed DPA submission requests in application logs, particularly with repeated invalid username patterns; absence of corresponding audit log entries for user creation events.
• Application: Degraded TSPortal performance, increased database query latency, or storage alerts coinciding with a spike in failed validation requests.
• Network: Repeated authenticated HTTP requests to the DPA submission endpoint from a single source IP or user account in a short time window (Miraheze Advisory).

Upgrade TSPortal to version 34 or later, which resolves the issue by replacing User::findOrCreate() with the non-mutating User::firstWhere() in the DPAAlreadyLive validation rule, ensuring validation logic performs only read operations and that user records are never created unless all validation passes. No configuration-based workaround is documented; upgrading to v34 is the only recommended remediation (Miraheze Advisory, GitHub Advisory).

The advisory was authored and published by Universal-Omega of the Miraheze/WikiTide project on March 23, 2026, and subsequently reviewed and listed in the GitHub Advisory Database on March 27, 2026. Coverage has been limited to automated vulnerability tracking platforms (e.g., CIRCL, ENISA EUVD, VulDB, CVEFeed) and a brief write-up on infinitsec.net. No significant broader community discussion, vendor statements beyond the advisory itself, or notable media coverage has been identified (GitHub Advisory).