We recently had a security incident where an attacker used an old AWS access key to generate millions of tokens from various Claude models via AWS Bedrock. While we don’t have any specific reason to think that any user data was accessed (and some reasons[1] to think it wasn’t), most possible methods by which this key could have been found by an attacker would also have exposed our database credentials to the attacker. We don’t know yet how the key was leaked, but we have taken steps to reduce the potential surface area in the future and rotated relevant credentials. This is a reminder that LessWrong does not have Google-level security and you should keep that in mind when using the site.
The main reason we don’t think any user data was accessed is because this attack bore several signs of being part of a larger campaign, and our database also contains other LLM API credentials which would not have been difficult to find via a cursory manual inspection. Those credentials don’t seem have been used by the attackers. Larger hacking campaigns like this are mostly automated, and for economic reasons the organizations conducting those campaigns don’t usually sink time into manually inspecting individual targets for random maybe-valuable stuff that isn’t part of their pipeline.
We recently had a security incident where an attacker used an old AWS access key to generate millions of tokens from various Claude models via AWS Bedrock. While we don’t have any specific reason to think that any user data was accessed (and some reasons[1] to think it wasn’t), most possible methods by which this key could have been found by an attacker would also have exposed our database credentials to the attacker. We don’t know yet how the key was leaked, but we have taken steps to reduce the potential surface area in the future and rotated relevant credentials. This is a reminder that LessWrong does not have Google-level security and you should keep that in mind when using the site.
The main reason we don’t think any user data was accessed is because this attack bore several signs of being part of a larger campaign, and our database also contains other LLM API credentials which would not have been difficult to find via a cursory manual inspection. Those credentials don’t seem have been used by the attackers. Larger hacking campaigns like this are mostly automated, and for economic reasons the organizations conducting those campaigns don’t usually sink time into manually inspecting individual targets for random maybe-valuable stuff that isn’t part of their pipeline.
This might be worth pinning as a top-level post.