https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 02:51:18 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-277896 EUVD-2026-277896 https://cve.radiocsirt.org/vuln/euvd-2026-277896 https://cve.radiocsirt.org/vuln/fkie_cve-2026-33541 <p>TSPortal is the WikiTide Foundation’s in-house platform used by the Trust and Safety team to manage reports, investigations, appeals, and transparency work. Prior to version 34, 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). Version 34 contains a fix for the issue.</p> <p>TSPortal is the WikiTide Foundation’s in-house platform used by the Trust and Safety team to manage reports, investigations, appeals, and transparency work. Prior to version 34, 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). Version 34 contains a fix for the issue.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-33541 https://cve.radiocsirt.org/vuln/ghsa-f346-8rp3-4h9h <p><strong>Affected:</strong> Packagist: miraheze/ts-portal</p> <p>### 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).</p> <p>### Details When submitting a Data Processing Agreement (DPA) request in TSPortal, the `DPAAlreadyLive` validation rule previously called `User::findOrCreate()`.</p> <p>This method created a user record if one did not already exist.</p> <p>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.</p> <p>As a result: - Validation correctly rejected invalid input - However, user records were still inserted into the database as a side effect</p> <p>These records were created: - Without a successful DPA request - Without audit logging tied to a completed action - Without visibility into their origin</p> <p>### Impact An attacker could exploit this behavior by automating requests with invalid usernames, resulting in:</p> <p>- Mass creation of arbitrary user records - Unbounded database growth - Increased storage and indexing overhead - Potential degradation of application perf…</p> <p><strong>Affected:</strong> Packagist: miraheze/ts-portal</p> <p>### 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).</p> <p>### Details When submitting a Data Processing Agreement (DPA) request in TSPortal, the `DPAAlreadyLive` validation rule previously called `User::findOrCreate()`.</p> <p>This method created a user record if one did not already exist.</p> <p>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.</p> <p>As a result: - Validation correctly rejected invalid input - However, user records were still inserted into the database as a side effect</p> <p>These records were created: - Without a successful DPA request - Without audit logging tied to a completed action - Without visibility into their origin</p> <p>### Impact An attacker could exploit this behavior by automating requests with invalid usernames, resulting in:</p> <p>- Mass creation of arbitrary user records - Unbounded database growth - Increased storage and indexing overhead - Potential degradation of application perf…</p> https://cve.radiocsirt.org/vuln/ghsa-f346-8rp3-4h9h