The short answer
On January 29, 2019, starting at 12:45 p.m. Central, Basecamp was hit by a credential-stuffing attack: more than 30,000 login attempts in the following hour from a wide array of IP addresses. Attackers successfully authenticated to 124 accounts — in every case using the correct username and password, most likely obtained from third-party breach compilations such as Collection #1, Anti Public, or Exploit.in. Basecamp’s preliminary review found no actions performed in affected accounts, and CTO David Heinemeier Hansson later clarified that none of the 124 accounts had content accessed. Basecamp reported no compromise of its own systems. [1][2]
Basecamp stopped the attack by blocking offending IP addresses and enabling CAPTCHA, reset passwords for the affected accounts, logged out intruders, and emailed affected account holders. It disclosed the incident publicly the next day, January 30, 2019, in a Signal v. Noise post by CTO David Heinemeier Hansson. A follow-up wave on January 31, 2019 from more than 5,000 IP addresses proved credentials for 89 additional accounts valid, but no account content was accessed in that wave. [1][2]
This record covers Basecamp, the project management product by 37signals. The documented event is a credential-stuffing attack against user accounts; Basecamp reported no compromise of its own systems. [1][2]
Classification: Credentials stolen elsewhere were replayed against user accounts. Learn how incident terms differ.
Attack type
Credential stuffing — replaying username/password pairs that Basecamp said were most likely obtained from breaches of other services [1][2]
Scale
More than 30,000 login attempts within one hour on January 29, 2019 [1]
Successful account logins
124 unauthorized logins using correct credentials; Basecamp later said none of those accounts had content accessed [1]
Likely credential origin
Basecamp said third-party breach compilations were highly likely and named Collection #1, Anti Public, and Exploit.in as examples [1]
Response
Offending IPs blocked, CAPTCHA enabled, passwords reset, intruders logged out, affected users emailed [1]
Incident timeline.
-
Credential-stuffing attack
Starting at 12:45 p.m. Central, more than 30,000 login attempts arrive within an hour from a wide array of IP addresses. Attackers authenticate to 124 accounts using correct usernames and passwords. Basecamp blocks offending IPs, enables CAPTCHA, resets affected passwords, logs out intruders, and emails account holders; its review found no actions performed, and it later said none of the 124 accounts had content accessed. [1]
-
Public disclosure
Basecamp CTO David Heinemeier Hansson publishes “Yesterday’s mass-login attack on Basecamp is another reminder to protect yourself” on Signal v. Noise, describing the attack, the 124 affected accounts, and the likely credential-compilation origin of the passwords. [1][2]
-
Follow-up wave
A second wave arrives from more than 5,000 IP addresses. Credentials for 89 additional accounts are proven valid, but no account content is accessed in this wave. [1]
What happened on January 29, 2019
Basecamp’s own account is unusually precise. The attack began at 12:45 p.m. Central time on January 29, 2019, followed by more than 30,000 login attempts within an hour from a wide array of IP addresses — the signature of a distributed credential-stuffing run. Of those attempts, 124 produced successful account logins using correct credentials. Basecamp’s preliminary review found no actions performed, and David Heinemeier Hansson later said none of those accounts had content accessed. [1]
Basecamp said it was “highly likely” that the correct passwords came from credential compilations circulating after breaches of other sites, naming Collection #1, Anti Public, and Exploit.in. The available evidence therefore points to password reuse, but the source of each credential was not independently established. [1][2]
Why this is not a compromise of Basecamp’s systems
Credential stuffing replays username/password pairs obtained elsewhere against a target’s normal login flow. It does not require penetrating the target’s password database: the attacker attempts to log in with valid credentials. That is the mechanism Basecamp reported here; every unauthorized access used the account’s correct credentials, and the automated wave stopped after IP blocking and CAPTCHA friction. [1][2]
One caveat we flag for transparency: the incident narrative is first-party — it comes from Basecamp’s own disclosure. Contemporaneous security reporting repeated the timing, figures, and response. No product-attributed Basecamp entry was located in Have I Been Pwned on July 13, 2026, but HIBP absence cannot prove that no other incident occurred. [1][2][3]
Basecamp’s response and public disclosure
The response sequence was fast and specific: Basecamp blocked the offending IP addresses, enabled CAPTCHA to break the automated wave, reset passwords on the 124 affected accounts, logged out intruders, and emailed the affected account holders directly. The public write-up followed within a day, authored by the company’s CTO and including concrete figures. [1][2]
When a second wave hit on January 31, 2019 from more than 5,000 IP addresses, Basecamp reported it too — including the detail that credentials for 89 more accounts were validated but no content was accessed. Speed, specificity, and naming password reuse as the likely root cause make this a notably detailed incident disclosure. [1][2]
What Basecamp users should take from it
Basecamp’s evidence points to password reuse on the affected accounts. The durable defenses are the ones Basecamp itself urged: use a unique password per service, preferably through a password manager, and enable two-factor authentication where available. Checking an email address on Have I Been Pwned can show whether it appears in known breach corpuses, though it cannot prove the origin of a particular login attempt. [1][3]
How SealTask relates to this incident class
Credential stuffing threatens password-based accounts when users reuse credentials. A second factor can block a login even when the password is known, and end-to-end encryption is not a substitute for that login protection. SealTask’s content encryption addresses a different scenario: an attacker who obtained only persisted server data would obtain ciphertext for protected workspace content, while account data and operational metadata remain server-visible. For this incident class, the immediate defense is still a unique password plus a second factor where offered; SealTask accounts support optional authenticator-app two-factor authentication (TOTP) with one-time backup codes. [4]
Frequently asked questions.
Has Basecamp ever had a data breach?
The January 29, 2019 event documented here was credential stuffing, not a confirmed compromise of Basecamp’s systems: attackers authenticated to 124 accounts with correct passwords that Basecamp said were most likely obtained from breaches of other services. Basecamp later said none of those accounts had content accessed. No product-attributed Basecamp entry was located in HIBP on July 13, 2026, but that absence is not a complete incident history. [1][3]
What happened in the 2019 Basecamp attack?
Starting at 12:45 p.m. Central on January 29, 2019, attackers made more than 30,000 login attempts within an hour from many IP addresses, successfully authenticating to 124 accounts using credentials that Basecamp said were most likely sourced from third-party breach compilations. Basecamp blocked the IPs, enabled CAPTCHA, reset affected passwords, and disclosed publicly the next day. Its review found no actions performed, and it later said none of the 124 accounts had content accessed. [1][2]
Were Basecamp passwords stolen?
Basecamp reported no theft from its own password store. It said the valid credentials were highly likely to have come from breach compilations of other services, naming Collection #1, Anti Public, and Exploit.in. [1]
How did Basecamp respond to the attack?
It blocked the offending IP addresses, enabled CAPTCHA to stop the automated attack, reset passwords for the 124 affected accounts, logged out intruders, and emailed affected account holders — then published a detailed public post by CTO David Heinemeier Hansson the next day, January 30, 2019. [1][2]
Is Basecamp listed in Have I Been Pwned?
No product-attributed Basecamp entry was located in the live HIBP index on July 13, 2026. Basecamp attributed the 2019 login attempts to credentials most likely obtained from other services rather than from Basecamp; HIBP absence does not establish a clean incident history. [3][1]
Related records
Sources
All sources last accessed . Corrections: email hello@sealtask.com with a source and we will review and correct.
- 01 Signal v. Noise: “Yesterday’s mass-login attack on Basecamp is another reminder to protect yourself” - Primary source — David Heinemeier Hansson’s January 30, 2019 disclosure and follow-up clarification covering attack timing, scale, response, and the finding that no content was accessed
- 02 BleepingComputer: “Basecamp Successfully Defends Against Credential Stuffing Attack” - Independent contemporaneous reporting corroborating the date, figures, and response sequence of the January 29 attack
- 03 Have I Been Pwned: breached-sites index - No product-attributed Basecamp entry located; checked against the live index on July 13, 2026
- 04 SealTask security architecture - What SealTask encrypts client-side and which operational metadata remains server-visible
Prefer task content protected at rest?
SealTask encrypts task titles, notes, comments, and attachments before upload. A compromise limited to stored server data would expose ciphertext for that content; account metadata, active sessions, client delivery, and devices remain separate risks.