Twelve breaches in nineteen days

I stopped counting after the sixth notification. Then the seventh arrived. Then three more in a single weekend. By the time I sat down to write this, the tally was twelve security incidents in nineteen days, spread across personal accounts, business tools, and production infrastructure. This wasn't a coordinated attack. Nobody targeted me specifically. That's the part that should concern you. This is just what it looks like to be a builder in 2026, to have fifty-plus accounts, a handful of side projects, a few API integrations, and a normal amount of digital surface area. The incidents kept coming because the surface area never stops growing.

The list

Carousell sent a breach notification. My data from years ago, back when I used the platform regularly, had resurfaced on a dark web forum. A fresh dump, not the original 2022 incident, but a new dataset circulating in February 2026. Canva credentials appeared on a dark web marketplace. The original breach was 2019, 139 million accounts. But breached data has a long tail. Old datasets get repackaged, recombined with data from other breaches, and sold again. Seven years later, my old Canva credentials were still making the rounds. GitHub notified me that webhook secrets had been inadvertently exposed. Between September 2025 and January 2026, a bug in their webhook delivery platform included secrets in an HTTP header sent to receiving endpoints. The bug was fixed in January, but GitHub didn't notify affected users until April, nearly three months later. A webhook secret I set two years ago and never rotated was potentially readable by any endpoint that received my payloads during that window. Google blocked a suspicious login attempt on my account. Credential stuffing, most likely. Someone, somewhere, was running automated login attempts using email and password combinations from old breach databases. My two-factor authentication held. But the alert was a reminder that old passwords from 2017 are still circulating and still being tried. Eurail disclosed a data breach affecting over 300,000 travelers. In December 2025, attackers exfiltrated files from Eurail's network, including names and passport numbers. I'd bought a rail pass years ago on a trip through Europe. By April 2026, the stolen data was being offered for sale on the dark web and samples were published on Telegram. Passport numbers. Not passwords, not email addresses. Passport numbers. Revolut sent two separate security alerts in the same week. The first was a notification about suspicious activity on my account, likely triggered by the same credential stuffing campaigns hitting everything else. The second came days later, a general advisory about an ex-employee who had threatened to leak customer KYC data unless paid in cryptocurrency. The incident made the news. It also made my inbox. A SaaS analytics tool I'd signed up for in 2021 and forgotten about sent a breach notification. The service had been acquired, the original team was gone, and the new owners discovered unauthorized access to their legacy database. My email, name, and hashed password were in the exposed dataset. I hadn't logged into the service in three years. An npm advisory flagged a compromised dependency in one of my side projects. Not a direct dependency, but a transitive one, three levels deep in the dependency tree. The malicious version had been live for a few hours before being pulled. My lockfile saved me, but only because I'd pinned versions. If I'd been using loose ranges, the compromised package would have been pulled in automatically on the next install. Have I Been Pwned sent a notification for an old email alias I'd used for testing. The alias was tied to a service I couldn't even remember signing up for. The breach was months old, but HIBP had only recently ingested the dataset. Another ghost account, another set of credentials in someone else's hands. A connected OAuth application I'd authorized years ago had its tokens revoked after the provider detected anomalous API activity. The app had read access to a subset of my data. I don't know if anything was actually accessed. The provider's notification was vague, a boilerplate "out of an abundance of caution" email that told me almost nothing about what happened or what was at risk. Twelve incidents. Nineteen days. Not from a single attack, but from the compounding surface area of existing online in 2026.

The pattern nobody talks about

Each incident, taken individually, is manageable. A breach notification here, a suspicious login there. You change a password, enable two-factor auth if you haven't already, and move on. The problem is the accumulation. Every developer, every builder, every person who ships software for a living carries an invisible inventory of attack surfaces. The GitHub tokens. The webhook secrets. The OAuth grants. The API keys sitting in environment variables across a dozen projects. The SaaS accounts you signed up for to try a feature and never cancelled. The email aliases you used once for a signup form. Have I Been Pwned tracks 978 breaches exposing 17.5 billion accounts. GitGuardian's 2026 report found 28.65 million new hardcoded secrets added to public GitHub repositories in 2025 alone, a 34% increase year over year. These aren't statistics about other people. They're statistics about you and me. The toolchain is the vulnerability. Not any single tool, but the aggregate. Every integration is a door. Every connected service is a trust relationship. Every API key is a credential that will eventually need to be rotated, revoked, or explained in a breach notification.

Every integration is a door

I build agents. I write software that connects to APIs, processes data, and automates workflows. Every one of those connections requires credentials, and every credential is a liability. This isn't a theoretical concern. The supply chain attacks of early 2026 proved it. Axios, with 100 million weekly npm downloads, was compromised through a stolen maintainer account. LiteLLM, the AI gateway library with 95 million monthly downloads, was backdoored through a cascade that started with a compromised security scanner. The Bitwarden CLI was hit through a poisoned GitHub Action. In each case, the update mechanism itself was the attack vector. The Vercel breach in April traced back to an AI productivity tool called Context.ai. An employee at Context.ai searched for game exploit scripts, got infected with malware, had their credentials harvested, and the attacker pivoted through OAuth trust relationships into a Vercel employee's Google Workspace account. The entire chain started with one person installing one browser extension. I think about this every time I authorize a new OAuth connection or install a new package. The uncomfortable truth is that I've written about security being the real risk of AI agents, not sentience. Twelve incidents in nineteen days is the lived experience of that claim. Every agent I build needs API keys, webhook endpoints, OAuth tokens, cloud credentials. Each one expands the surface area. Each one is a door I'm responsible for monitoring, and each one is a door I'll probably forget about within a month.

The asymmetry

What keeps me up at night isn't any single incident. It's the asymmetry between how easy it is for one credential to leak and how far the damage can travel. A single compromised webhook secret can let an attacker inject payloads into your CI/CD pipeline. A single leaked API key can cascade through every service it touches. A single OAuth token with overly broad permissions can give an attacker access to data you forgot the app could even reach. Security researchers call this the blast radius, the total scope of damage that results from a single point of compromise. In a flat network with over-privileged accounts, one phished credential can walk an attacker from your inbox to your production infrastructure. In a developer's personal setup, one compromised service can expose credentials for a dozen others. The blast radius of my GitHub webhook secret being exposed wasn't just the webhook itself. It was every system that trusted payloads signed by that secret. Every deployment triggered by a webhook event. Every automation that ran in response. One secret, potentially months of exposure, and a blast radius I can only estimate because I don't have perfect visibility into every system that received those payloads.

What nobody tells indie builders

Most security advice is written for enterprises. Dedicated security teams, compliance budgets, automated scanning pipelines. None of that maps to a solo developer running three side projects, a blog, and an agent framework from a laptop. Here's what an honest security posture looks like for an indie builder or a small startup. It's not a checklist. It's a set of principles, and the honest part is admitting that nobody follows all of them all the time. Least privilege is the single most important principle, and the one most consistently ignored. Every API key should have the minimum permissions it needs. Every OAuth grant should be scoped as narrowly as possible. Every service account should have access to exactly what it requires and nothing else. I know this. I still have API keys with broader permissions than they need because scoping them down properly takes time I haven't made. Hard spending limits on every cloud service and API provider. Not soft alerts, hard caps. If a compromised key starts making requests, the damage should stop at a dollar amount you've chosen in advance, not at the moment you happen to check your billing dashboard. This is the one principle I actually follow religiously, because the alternative is waking up to a five-figure cloud bill. Kill switches for every integration. You should be able to revoke any credential, disconnect any service, and shut down any agent within minutes. If revoking a single API key requires hunting through three repositories and two deployment configs, your incident response time is measured in hours, not minutes. That's too slow. Audit your ghost accounts. I had a SaaS tool from 2021 send me a breach notification. I hadn't used it in three years. My data was still there. Every service you've ever signed up for is a potential breach notification waiting to happen. Periodically review and delete accounts you no longer use. You can't control whether they get breached, but you can control whether your data is there when they do. Rotate on evidence, not on a schedule. NIST's updated guidelines recommend against mandatory periodic password changes because they lead to weaker passwords. But "change when compromised" only works if you're actually monitoring for compromise. Check Have I Been Pwned. Watch for breach notifications. And when evidence arrives, act on it immediately, not "this weekend." The gap between knowing these principles and actually following them is the real vulnerability. I wrote about this recently. Nine incidents in seventeen days, and my first response was to write a blog post instead of rotating my credentials. Now it's twelve incidents in nineteen days, and I'm doing it again. The psychology of security behavior is that concrete effort always loses to abstract risk when you're tired and have other things to do.

The compounding surface area

Here's what twelve incidents in nineteen days actually taught me. The problem isn't any single breach. It's that the surface area only grows. Every new project, every new SaaS signup, every new API integration adds another node to the graph of things that can go wrong. The graph never shrinks on its own. It only shrinks when you actively prune it. I'm not going to pretend I have a solution. The transition to a world where credentials manage themselves, through passkeys, short-lived tokens, and automated rotation, is underway but not finished. We're stuck in the uncomfortable middle. Too many credentials to manage well, not enough infrastructure to eliminate them. What I do know is that the next cluster of incidents is already forming. Somewhere, a service I signed up for is about to get breached. Somewhere, a dependency I'm using is being targeted. Somewhere, a webhook secret I set and forgot about is sitting in a log file on someone else's server. The compounding surface area of being a builder in 2026 means that security isn't something you achieve. It's something you practice, imperfectly, continuously, knowing that the pile of things to worry about grows faster than your ability to address them. Twelve incidents. Nineteen days. And the counter hasn't stopped.

References