CVE-2026-73529: Plainpad Missing Rate Limiting via POST /v1/sessions
Plainpad through 1.1.1, fixed in commit d3823fc, contains a missing rate limiting vulnerability that allows unauthenticated attackers to send unbounded login requests to the POST /v1/sessions endpoint due to dead code in App\Http\Kernel.php that is never instantiated under the Laravel 11+ skeleton, leaving the API throttle configuration unattached to any route. Attackers can exploit this by sending unlimited credential attempts with no lockout or CAPTCHA enforcement, and additionally trigger CPU exhaustion by forcing repeated bcrypt comparisons on each request.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Plainpadto a version that resolves this vulnerability.Fixed in 1.1.1Patch d3823fc - Compensating control
As an immediate mitigation, enforce rate limiting at the network/API layer for unauthenticated requests to POST /v1/sessions to prevent unlimited credential attempts (since the API throttle configuration is unattached).
- Compensating control
As an additional mitigation, add request limiting/queuing for unauthenticated traffic targeting POST /v1/sessions to reduce CPU exhaustion caused by repeated bcrypt comparisons on each request.
Event History
Frequently Asked Questions
Which deployments are affected?
Plainpad installations through version 1.1.1 are affected. The issue is fixed in commit d3823fc.
What does an attacker need to exploit this?
An attacker does not need authentication or user interaction. They can send unlimited requests to POST /v1/sessions, enabling unrestricted credential attempts and repeated bcrypt work.
Is the login endpoint protected by the configured API throttling?
The API throttle configuration is unattached to routes because the relevant code is never instantiated under the Laravel 11+ skeleton. As a result, login requests have no rate limit, lockout, or CAPTCHA enforcement.
How could this affect service availability?
Repeated requests to POST /v1/sessions can force bcrypt comparisons on every request, which can exhaust CPU resources. This can make the issue an availability concern even without successful credential guessing.