An automated sign-up attack, and what we built so it doesn't happen again
LeraLink, November 2026
What happened
In early November we noticed something odd on one of the installations on LeraLink. New accounts were being created one after another, each with a different email address. Each one confirmed its address, signed in, and started writing notes in the margins of published pieces straight away. The speed and the pattern made it clear that this was an automated script, not real readers.
These accounts had the permissions of a new reader and nothing more. They could read and write in the margin. They had no access to any administrative area or to anyone else's account.
What we did first
To stop it, we put the whole platform into read-only mode for a while. That worked, but it came at a cost: for that period nobody could write, including authors and genuine readers who had done nothing wrong.
What it showed us
Looking back at the incident, we found three gaps.
- There was no narrow emergency switch. The only way to stop the attack was to freeze the entire platform. We could not pause just new sign-ups, or just margin notes.
- There were no bulk tools. Accounts could only be blocked or anonymised one at a time, both at the platform level and inside each installation. Against hundreds of accounts, that is not a real option.
- New accounts could write without any limit. An account created a few seconds earlier had exactly the same freedom as a reader who had been around for years.
What we built
We worked from one rule: a real member should not notice any of this. Every new check applies only to email addresses that are new to an installation. If you are already a member, nothing about signing in, reading or writing has changed for you.
Automatic protection
- Checks at sign-up. Addresses from well-known disposable email services are not accepted, and neither are domains that cannot receive email at all. Addresses that look different but deliver to the same inbox are treated as one.
- An automatic circuit breaker. If an unusual number of accounts is created on one installation in a short time, that installation switches by itself to "approval before writing". The accounts created during the surge are held until someone approves them. The rest of the site carries on as normal.
- An immediate alert. When the breaker trips, the installation's owner and administrators are emailed, and so are the platform administrators. It also shows up on the platform's operations page.
- A starting period for new members. For their first days, new members can write a sensible number of notes per hour. A real reader will never reach that limit. For a script, it is the end of the road.
- An optional human check. An installation can turn on Cloudflare's unobtrusive check that a person, not a program, is filling in the sign-up form. It is only shown to people who are signing up for the first time, and only when it is needed.
For the people who run an installation
Installation admins have a new page, Sign-up protection, where they can:
- Choose how people join. Open, approval before writing, or invitation only. None of these affects existing members.
- Pause margin writing. Readers' notes and appreciations can be paused for a while. Authors and the Studio keep working.
- See who has just joined. New accounts are grouped when they share an email domain, a network or a browser, so a whole wave can be selected in one click.
- Ban in bulk. In one step, the selected accounts are signed out, their membership is suspended, their notes and appreciations are hidden from everyone, and they cannot come back with the same address.
- Undo a ban completely. If someone was banned by mistake, lifting the ban restores everything exactly as it was.
- Approve in bulk. Real members who were held for approval can be approved in one click.
Team members and administrators can never be selected in these bulk actions, so a mistake in a filter cannot lock anyone out of their own installation.
For the platform
- Two emergency switches that are narrower than read-only. These work for the whole platform or for a single installation: "pause new sign-ups" and "pause margin writing". Members keep signing in and authors keep writing.
- One view of every installation. It shows each installation's sign-up mode, how many people joined recently, and any installation where the breaker has tripped.
- Platform-wide bans. These include pasting in a list of addresses. There is also a list of blocked email domains that applies to every installation and to the contact form.
- Permanent deletion of fake accounts. This uses the same process as when a person deletes their own account. Once an account is deleted, its address is not kept anywhere, but it is still refused.
- Clean-up tools that work during read-only. If we ever have to freeze the platform again, we can clean up at the same time.
Wherever passkey sign-in is required, sensitive actions ask you to confirm with your passkey again. Every one of these actions is recorded in the audit log.
What changes for readers?
Almost nothing. If you are a member, signing in, reading and writing work exactly as before. If you are joining for the first time, you may occasionally see one of two messages: sign-up is closed for the moment, or margin writing opens once the team has approved your membership. You can always start reading straight away.
What comes next
- Turning on the human check for each installation once its domains are set up in Cloudflare.
- Adding another layer of rate limiting at Cloudflare's edge, before requests reach LeraLink at all.
- Watching how the circuit breaker behaves over the coming weeks, and tuning it against real sign-up patterns.
Thank you to everyone who was patient while the platform was paused. The safety of the place where we read and write is part of the place itself, and we take it seriously.