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