GHSA-f346-8rp3-4h9h
MEDIUMGHSA-f346-8rp3-4h9h is a medium-severity (CVSS 6.5) Uncontrolled Resource Consumption vulnerability in miraheze/ts-portal. O3 Security confirms whether GHSA-f346-8rp3-4h9h is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
TSPortal's Uncontrolled User Creation via Validation Side Effects Leads to Potential Denial of Service
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-f346-8rp3-4h9h.
Real-World Exposure
miraheze/ts-portalReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
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
- Submit a DPA request using an invalid username
- Ensure the request fails validation due to
MirahezeUsernameRule - 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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | miraheze/ts-portal | all versions | 34 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for miraheze/ts-portal. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update miraheze/ts-portal to 34 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f346-8rp3-4h9h is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-f346-8rp3-4h9h is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-f346-8rp3-4h9h. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-f346-8rp3-4h9h in your dependencies?
O3 detects GHSA-f346-8rp3-4h9h across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.