GHSA-f346-8rp3-4h9h

Summary

A flaw in TSPortal allowed attackers to create arbitrary user records in the database by abusing validation logic. While validation correctly rejected invalid usernames, a side effect within a validation rule caused user records to be created regardless of whether the request succeeded. This could be exploited to cause uncontrolled database growth, leading to a potential denial of service (DoS).

Details

When submitting a Data Processing Agreement (DPA) request in TSPortal, the DPAAlreadyLive validation rule previously called User::findOrCreate().

This method created a user record if one did not already exist.

Although username validation (via MirahezeUsernameRule) correctly rejected invalid usernames, the DPAAlreadyLive rule was still executed during validation. Because it performed a state-changing operation, it created user records even when the overall validation failed and no DPA was created.

As a result:

• Validation correctly rejected invalid input
• However, user records were still inserted into the database as a side effect

These records were created:

• Without a successful DPA request
• Without audit logging tied to a completed action
• Without visibility into their origin

Impact

An attacker could exploit this behavior by automating requests with invalid usernames, resulting in:

• Mass creation of arbitrary user records
• Unbounded database growth
• Increased storage and indexing overhead
• Potential degradation of application performance

At scale, this could lead to a denial of service condition due to resource exhaustion.

Proof of Concept

1. Submit a DPA request using an invalid username
2. Ensure the request fails validation due to MirahezeUsernameRule
3. Observe that a corresponding user record is still created in the database

This behavior was confirmed prior to remediation.

Root Cause

The issue stemmed from:

• Performing state-changing operations (findOrCreate) inside validation logic
• Validation rules executing regardless of overall validation success
• Lack of separation between validation and persistence layers

Mitigation

The issue has been fixed by removing database write operations from validation logic.

Specifically:

• Replaced User::findOrCreate() with a non-mutating lookup (User::firstWhere(...))
• Ensured validation rules only perform read operations
• Prevented user creation unless all validation passes