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