On 2026-07-16 between 06:56 and 06:59 UTC, a credential stuffing attack was launched against the login endpoint from IP 88.198.21.243 (Hetzner datacenter, Germany). The attacker used HeadlessChrome and attempted 20+ unique email/password combinations in rapid succession. All attempts failed (returned 401/403), but the attack highlights the absence of rate limiting on the login endpoint. A separate incident targeting the account lensflare@gmx.de from 3 different IPs over multiple days (16th and 17th July) is also reported.
Steps to Reproduce
Not provided.
Expected Behaviour
The login endpoint should have rate limiting to block or throttle rapid successive requests from a single IP, preventing brute-force and credential stuffing attacks.
Actual Behaviour
No rate limiting is present on the login endpoint. The attacker was able to attempt 20+ unique email/password combinations within one minute from a single IP without any throttling or blocking.
Environment
Not provided.
Reported by retoor via DevPlace.
## Summary
On 2026-07-16 between 06:56 and 06:59 UTC, a credential stuffing attack was launched against the login endpoint from IP 88.198.21.243 (Hetzner datacenter, Germany). The attacker used HeadlessChrome and attempted 20+ unique email/password combinations in rapid succession. All attempts failed (returned 401/403), but the attack highlights the absence of rate limiting on the login endpoint. A separate incident targeting the account lensflare@gmx.de from 3 different IPs over multiple days (16th and 17th July) is also reported.
## Steps to Reproduce
1. Not provided.
## Expected Behaviour
The login endpoint should have rate limiting to block or throttle rapid successive requests from a single IP, preventing brute-force and credential stuffing attacks.
## Actual Behaviour
No rate limiting is present on the login endpoint. The attacker was able to attempt 20+ unique email/password combinations within one minute from a single IP without any throttling or blocking.
## Environment
Not provided.
---
*Reported by **retoor** via DevPlace.*
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
I am picking this ticket up now.
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
I am now reading the relevant source, tests, and prior work in the live checkout to verify the ticket and gather the context needed for a concrete plan. This can take a while; I will post periodic progress updates until it completes.
Starting research round 1 of at most 5.
I am now reading the relevant source, tests, and prior work in the live checkout to verify the ticket and gather the context needed for a concrete plan. This can take a while; I will post periodic progress updates until it completes.
This ticket has reached its outcome. The ticket is closed and the workspace is no longer needed.
Would you like me to clean up the branch and workspace for this ticket? Reply with /typosaurus cancel-and-cleanup to confirm, or leave it as is.
This ticket has reached its outcome. The ticket is closed and the workspace is no longer needed.
Would you like me to clean up the branch and workspace for this ticket? Reply with `/typosaurus cancel-and-cleanup` to confirm, or leave it as is.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
On 2026-07-16 between 06:56 and 06:59 UTC, a credential stuffing attack was launched against the login endpoint from IP 88.198.21.243 (Hetzner datacenter, Germany). The attacker used HeadlessChrome and attempted 20+ unique email/password combinations in rapid succession. All attempts failed (returned 401/403), but the attack highlights the absence of rate limiting on the login endpoint. A separate incident targeting the account lensflare@gmx.de from 3 different IPs over multiple days (16th and 17th July) is also reported.
Steps to Reproduce
Expected Behaviour
The login endpoint should have rate limiting to block or throttle rapid successive requests from a single IP, preventing brute-force and credential stuffing attacks.
Actual Behaviour
No rate limiting is present on the login endpoint. The attacker was able to attempt 20+ unique email/password combinations within one minute from a single IP without any throttling or blocking.
Environment
Not provided.
Reported by retoor via DevPlace.
nO, YO CAN close ticket, inore..
Posted by retoor via DevPlace.
I said close ticket.
Posted by retoor via DevPlace.
I am picking this ticket up now.
First I will bring up an isolated workspace with a fresh checkout and investigate whether the ticket matches the current state of the code before planning any change. I will announce every step here before I take it.
Starting research round 1 of at most 5.
I am now reading the relevant source, tests, and prior work in the live checkout to verify the ticket and gather the context needed for a concrete plan. This can take a while; I will post periodic progress updates until it completes.
This ticket is now closed. All work has been stopped per the agreed decision. No further action is planned.
This ticket has reached its outcome. The ticket is closed and the workspace is no longer needed.
Would you like me to clean up the branch and workspace for this ticket? Reply with
/typosaurus cancel-and-cleanupto confirm, or leave it as is.Just do it. NIKE
Posted by retoor via DevPlace.