Fanlore Wiki Accounts Circulating After OTW's Self Reported Breach
A forum actor posting as 584 has published what they describe as the account database of Fanlore.org, the fan culture wiki operated by the Organization for Transformative Works, the non profit behind Archive of Our Own. The post states that OTW identified unauthorised access in August 2026, that around 145,000 unique email addresses were exposed along with names, usernames and passwords stored as MD5 or PBKDF2 hashes, and that OTW self reported the incident and submitted the data to Have I Been Pwned. The published sample matches the standard MediaWiki user table, including verification and authentication tokens. The files are unlocked for a forum fee. The underlying incident is acknowledged by the organisation; this copy is unverified.
▣Post details
!What the post claims
- About 145,000 unique emails
- Account usernames
- Real name field
- Email addresses
- Password hashes
- MD5 hashes present
- PBKDF2 hashes present
- Reset password field
- Email verification tokens
- Authentication tokens
- Registration timestamps
- Last activity timestamps
- Edit counts
- Email verified flags
- Temporary account flags
- Unauthorised access in August 2026
- Incident self reported by OTW
- Data submitted to Have I Been Pwned
◱Screenshot
☷Mapped techniques
The post describes no intrusion method. Both entries are inferred from the artefacts, not stated.
- Collection T1213 Data from information repositories Inferred The sample is the complete user table of the wiki software, including token and flag columns that no public interface exposes.
- Exfiltration T1567 Exfiltration over web service Inferred Distribution runs through forum hosting behind a points wall. The route out of the environment is not described.
⚠Potential impact
The password hashes are the least of this. A mix of MD5 and PBKDF2 suggests a long lived site where older accounts were never rehashed, so a subset is crackable and worth rotating anywhere the same password was reused, but PBKDF2 will hold for most. The real harm is deanonymisation. Fan communities are heavily pseudonymous, and for many contributors that is a safety measure rather than a preference: people write and catalogue under handles precisely because their fandom activity, and often their sexuality or identity, is not something they want attached to their name at work or at home. This file joins a wiki username to a working email address, and since handles are commonly reused across archives, forums and messaging platforms, one linkage frequently unlocks several. Some records also carry a real name field. For a population that has historically been targeted for harassment campaigns, that is the meaningful exposure, not the credentials. The authentication tokens in the table are worth a separate look, since they matter considerably more if any remain valid.
iStatus Acknowledged
This one sits differently to most listings. The underlying incident is not in dispute, since the organisation identified it, disclosed it and submitted the exposed data to a breach notification service, which is a considerably better response than the silence that follows most of the posts covered here. What remains unverified is whether this particular copy is genuine and complete, and the actor supplies no method, no date beyond the month, and no account of how they came to hold it. The sample is consistent with the wiki software's own schema, which is a point in its favour, though that schema is public and its column names are documented, so structure alone proves less than it would elsewhere. The practical position for affected people is unchanged either way: anyone who registered on the wiki should assume their email and username are now linked in public, and rotate that password anywhere it was reused. Dark Web Informer has not retrieved the files and is not linking them.
Dark Web Informer // Threat Intelligence
