Five findings.
Five scans that said nothing.

A simple “notes” box at checkout. Harmless on the store itself. But staff see that note later in their dashboard, and there it runs as live code, not text.

Our AI placed a normal-looking order with hidden code in the note. Hours later a staff member opened it, the code ran inside their account, and the attacker took over: a new admin login, and control of pricing and payouts.

A stored XSS the scanner never caught.

Not just “you have a bug.” We showed the exact page at fault, the one-line fix, and how to block anything like it in future, with steps a developer can replay in 5 minutes.

Authentication was enforced on every request. Whether the record you asked for is yours is a second, separate check - and it is the one automated scanning is least able to see.

Our AI signed up as a new tenant, then requested a record belonging to another. It came back in full. We confirmed it from two accounts.

A broken access control flaw, also called IDOR.

Before the app hands over a record, confirm it belongs to the account asking. We showed where that check belongs, with a re-test a developer can run on every release.

The one-time code travelled on the sign-in request as well as by email. When a value is supplied and verified on the same side, the verification stops being one.

Our AI put its own code on the request and told the app it was correct. It logged us in as another user, with no password and no access to their inbox.

An account takeover, with no credentials at all.

We pointed to the exact field the server must stop trusting, explained why it was reachable, and handed over a five-minute test to confirm the door was shut.

Admin-only features were taken off the menu for ordinary users. A request does not read the menu - it addresses the endpoint directly, and that is where the same decision has to be made a second time.

Our AI signed in as an ordinary user, worked out what that account was meant to be able to do, then asked the app to run the admin-only actions anyway. It ran them: adding and removing users, changing settings, privileged actions, all from an ordinary account.

A broken function-level authorization flaw, also called BFLA.

We listed every admin action that answered a normal user, the one check each of them was missing, and the single place to enforce it for all of them, with a re-test a developer can run on every release.

The form displayed two fields. The endpoint behind it accepted whatever the request carried, including one it never displayed: the field that decides whether an account is an administrator.

Our AI saved its own profile the normal way, with one extra field attached. Before the save, the admin pages turned it away. After the save, they opened. Same account, same button, nothing in between but an edit to its own profile.

A mass-assignment flaw, ending in full admin access.

We named the exact field the server must stop accepting, the short list of fields it should accept instead, and the before-and-after steps a developer can replay in five minutes to watch the escalation close.