I gave 10 NZ SaaS apps to our hackers. 7 were breached in under 60 minutes. Here's what they found.

Most security conversations start with a hypothetical. What if someone tried to break in. Capture The Bug decided to skip the hypothetical and run the real thing.

Ten New Zealand SaaS products, all live, all in production, all with paying customers behind them, were handed to the Capture The Bug testing team with one simple brief: get in, however you can, and stop the clock the moment you do. No advance notice to the product teams about what would be targeted first. No friendly hints. Just a login page, a public URL, and sixty minutes on the clock for each one.

Seven of the ten fell before the hour was up. Some fell in the first fifteen minutes.

The reality of a sixty-minute test

The companies are not named here, because the point of this exercise was never to embarrass anyone. It was to show founders and CTOs something they rarely get to see firsthand, which is exactly how fast a determined tester moves once they are inside a real product instead of a test environment.

None of the seven breaches involved anything dramatic. There was no zero-day, no months of patient reconnaissance, no exotic exploit pulled from a research paper. Every single one came down to something ordinary that had been sitting in plain sight, often for months.

Here is what the testing team actually found

1. Admin panels reachable with reused credentials. Three of the seven were breached because an admin or staff login still worked with a password that had appeared in an older, unrelated data leak. Multi-factor authentication was missing on the exact accounts that mattered most.
2. Broken access control between customer accounts. Two products let a logged-in user reach another customer's records simply by editing an ID in the address bar or an API request. No password needed. No alert triggered. The data was just there for the taking.
3. API keys sitting in plain view in client-side code. One product shipped a key with far more access than the browser ever needed, visible to anyone who opened the page source. That single key opened a door to backend systems the front-end was never supposed to touch.
4. Session tokens that never expired. One login session, once issued, stayed valid indefinitely. A token captured once gave a tester permanent access, with no need to ever log in again.
5. No limit on login attempts. The fifth breach did not need cleverness at all. The login form accepted unlimited attempts with no lockout and no slowdown, so a list of common passwords got there eventually, well inside the hour.

Five categories. Seven breaches. Not one of them required advanced skill. They required a tester who knew where to look and an application that had never been pushed hard enough to reveal the gap.

Why strong engineering teams still get caught out

It would be easy to assume the seven breached products were built by inexperienced teams. They were not. Several had funding, real customers, and engineers who knew their craft. The gap was never talent. It was timing.

Most teams test security once, usually before a big launch or a compliance deadline, then move on to the next sprint. The product they tested that day is rarely the product running six months later. New features ship. New endpoints appear. A contractor adds a quick admin tool nobody flags for review. Each change is small on its own, but each one is also a fresh chance for a permission check to go missing or a credential to get reused.

A single point-in-time pentest cannot see any of that. It is a photograph of a product that keeps moving. That is the entire argument behind continuous penetration testing, where the product gets checked as it changes rather than once a year on a fixed date.

What separated the three that held

Three of the ten products did not fall, and the difference was not luck. All three had something the other seven lacked: someone testing their authorization logic and their login flow recently, with real attempts to break it, not just a checklist review.

One had locked down session expiry after a previous round of testing flagged it as a risk. Another had already removed a key with excessive access after a routine check caught it months earlier. The third had simply rate-limited its login form, closing the door that one of the seven walked straight through.

None of these fixes were expensive. None required new headcount or a major rebuild. They were small, specific, and already in place because someone had gone looking before an attacker did.

What this means for your roadmap

If a sixty-minute test can take down seven out of ten real products, the takeaway is not that NZ SaaS teams are careless. It is that the gap between shipping fast and testing properly has become the most common way real companies get breached. Most of it has nothing to do with sophistication. It has to do with whether anyone tried the obvious thing before someone with bad intentions did.

For founders preparing for a Series A or a SOC 2 audit, this also matters for a different reason. A buyer or investor who asks how security is handled wants to hear about testing that happens continuously, not a certificate from last year sitting in a drawer. Capture The Bug's penetration testing service is built around that continuous rhythm, with CREST-certified testers who work the way a real attacker would and a live dashboard that shows exactly what was found and when it was fixed.

Seven breaches in under an hour is not a scare tactic. It is what happens when nobody has tested the obvious path in a while. The fix is rarely complicated. It just has to happen before the hour starts, not after.

Plan Security Better

Plan Your Annual Pentesting Strategy the Right Way

Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.

Get the Annual Pentesting Plan

FAQ