Archive of Our Own went offline just after 3AM ET on October 29 for what the Organization for Transformative Works said would be 12 hours of maintenance. By evening the estimate was two weeks, possibly four, and “maintenance” had become “security incident.”
That’s a long time for a site hosting millions of works, with an audience that pushed the status posts to millions of views within two hours. Fans are angry and scared. I think the OTW is doing exactly what it should.
What we actually know
Not much, and the OTW is saying so. Its statement says it detected evidence of a security incident, is in the early stages of response, and is still determining scope. It doesn’t believe the user database was stolen but can’t rule it out. That database holds usernames, email addresses, IP addresses and hashed passwords.
Engadget, citing a former volunteer who moderates r/AO3, reports that the site’s data is intact. Good news for the stories. It doesn’t settle the account question, though. A copy of a database can leave while the original sits untouched, so read “intact” as being about fics surviving. Your email address is a separate matter.
There’s an earlier hint, too. The OTW logged problems with email notifications, search, history and listings on October 23 and 24. Nobody has tied those to this incident, and I won’t either. If you were reconstructing a timeline, though, that’s where you’d start.
Stop blaming PHP
The tempting explanation is last week’s “PHP Armageddon,” when tools from OpenAI and Google’s Wiz turned up two critical flaws in PHP. Another OTW site, Fanlore, did briefly go offline to deal with that flaw. A separate TLS certificate vulnerability has also had admins pulling sites down to patch.
AO3 runs on Ruby on Rails. TechCrunch points out that makes a PHP connection unlikely, and the OTW hasn’t suggested either vulnerability is involved. Fans matching this to last week’s headline are filling silence with confident guesses, which only adds noise for the people doing the work.
The climate still matters. AI-assisted bug hunting is surfacing old holes faster than before, and every disclosure lands on someone’s to-do list. At a large company that’s a ticket in a queue. At a nonprofit whose engineers are volunteers, it’s somebody’s evenings and weekends. Engadget notes volunteer staffing could slow fixes. That’s just how the hours add up.
Why four weeks is fine
A site that comes back in 48 hours after a breach it hasn’t scoped is a site that can get hit again on day three. The OTW is choosing to rebuild properly. It’s floating a possible degraded return sooner, and it’s warning up front that the site may need to come down again before the job is done. Companies with paid security teams routinely say less, later.
What users should do now is small and boring. If your AO3 password is reused anywhere else, change it there. The OTW says it uses industry-standard hashing, which buys time against cracking. It doesn’t make a reused password safe forever.
One thing I want answered when the site returns: when did the OTW first spot the evidence, and was it before or after those October 23 glitches in search and notifications?