7 min read
What Attackers Tried on Shoppex in 60 Days, and How We Stopped Them
The hardest attacks on Shoppex from 5 September to 3 November 2026: what each attacker tried, what Shoppex did, and the numbers behind it.
Shoppex TeamThese are the attacks on Shoppex from 5 September to 3 November 2026, the hardest first. The numbers come from our production database, our server logs and our error tracker, and each case names its own window.
Someone uploaded a storefront built to explore our servers
vite.config.ts execSync('<shell command>') then print the output into the build logAnswer: No password, key or database login. No network.- storefront builds from 2 accounts
- 46
- builds that carried probe code
- 36
- passwords, keys or database logins obtained
- 0
Advanced storefronts let a merchant upload their own code, which Shoppex builds on its servers. An account created that evening uploaded 32 versions of a storefront in one hour and 42 minutes. Each build carried commands that hunted for passwords and keys, for the database, for other customers’ builds and for the cloud metadata address, the place where a cloud server can ask for its own access keys.
Every build runs in a locked box with its own temporary user and no network. The probes got 0 passwords, 0 keys and 0 database logins.
We banned the account 8 minutes after its last build. Two hours later the same attacker came back with a new account and 14 more builds, and we banned that account too. We found no other build in the 60 days that carried probe markers.
They ordered in other shops, then tried to mark the orders as paid
POST /dev/v1/invoices/<another shop’s invoice>/completeAnswer: 404 Invoice with ID '<id>' not found- orders placed in other shops by accounts we banned
- 292
- shops those orders went to
- 52
- orders completed without a payment
- 0
This attack takes three steps. Open a shop and create an API key for it. Go to a different shop as a buyer and place an order without paying. Then use your own shop’s key to mark that order as paid, so the other shop delivers it for free.
Accounts we later banned placed 292 orders in 52 shops they did not own. 31 of those orders were paid through checkout and completed normally. None was completed without a payment. In the Developer API, from 5 October to 3 November, 37 requests from 7 keys reached for another shop’s orders, customers or products, and every one got the same "not found" as an id that never existed. On 3 November one attacker opened two shops of their own and used the first shop’s key to read, change and delete the second shop’s records. All 14 calls got "not found". 5 accounts were banned automatically for this kind of request.
Webhooks that bounced through redirects to reach our network
POST /dev/v1/webhooks url=https://<public redirector>/redirect-to?url=http://169.254.169.254/latest/meta-data/Answer: Call failed. Nothing connected to the internal address.- webhooks aimed at internal addresses
- 28
- accounts behind them, all banned
- 5
- calls Shoppex made to them, all failed
- 34
- of 64,622 webhook calls reached an internal address
- 0
A webhook is a URL that Shoppex calls when something happens in your shop. These attackers wanted Shoppex to call addresses inside our own network instead. The main target was 169.254.169.254, the fixed address where a cloud server can ask for its own access keys. Others pointed at the server itself and at common database ports.
The attackers changed their approach as they went. 9 webhooks pointed at an internal address directly. 17 went through a public redirect service, so the URL looked harmless when it was saved. 2 hid the internal address in the part of a URL that usually holds a user name. Shoppex checks where an address really leads before every call and again at every redirect. All 34 calls failed, and none reached an internal address.
Banned, and back within minutes
ban → new email → new account → new shop → new API keyAnswer: Banned again- accounts created after a ban by the same attacker
- 18
- of them within 15 minutes of the ban
- 8
- fastest return
- 2.7 min
- banned again
- 18
A ban ends every session and revokes every API key and app access of the account’s shops in one step. The most persistent attackers answered with new accounts. 18 accounts were created after an earlier account of the same attacker had been banned. The fastest came back in under 3 minutes. All 18 are banned.
On 4 October an older merchant account with real sales started running attack scripts against the Developer API. Shoppex flagged 11 of its requests in 11 minutes, and we banned it. Within 21 minutes the same attacker opened six new accounts. In the same hour they sent 1,602 requests to 191 different sign-in routes. The first two new accounts were banned within 6 minutes. We found the rest and a second account of the same person, and banned them too.
Also caught: shops dressed as payment emails
Shop name: “you’ve successfully paid …”, “invoice placed …”, “order placed …”Answer: Banned before the first order- shops named like payment emails
- 3
- orders taken
- 0
Three shops took names that copy payment emails, so a message from them would read like "You’ve successfully paid". One listed an antivirus renewal, a common lure for callback scams. None took an order. All three were banned within a day.
The routine probing, in one table
Most attacks are scripts that try the same things on every site. This is what reached our API in the days up to 3 November.
| What they tried | Window | Attempts | Answer |
|---|---|---|---|
| Guessing merchant passwords | 60 days | 1,076 wrong passwords, 299 more slowed down. The 6 busiest clients got 0 sessions | 401, 429 |
| Sign-in and admin routes that do not exist | 60 days | 3,580 requests to 1,259 routes from 56 clients | 404 |
| Fake sign-ups and sign-ins | 60 days | 315 failed the bot check, of 2,027 | Refused |
Secret files such as .env, .git and cloud keys | 14 days | 1,142 requests for 385 paths from 35 clients | 404 |
| API keys calling outside their permissions | 30 days | 175 calls from 20 keys on 53 endpoints | 403 |
| Attack strings in place of an id (SQL, NoSQL) | 30 days | 11 requests from 2 keys | 404 |
What this means for your shop
- Another shop cannot read, change or delete your orders, customers or products through the API. 0 of 3,741,490 single-record answers from 5 October to 3 November carried another shop’s record.
- An order is delivered only after it is paid. 0 of 50,146 orders waiting for payment, expired or underpaid in the 60 days were delivered.
- Your webhook URLs cannot be turned against Shoppex’s network. 0 of 64,622 webhook calls reached an internal address.
- Code you upload for an Advanced storefront is built in a locked box with no network.
- Turn on two-factor sign-in with an authenticator app. A guessed password is then not enough to sign in.
- Add a passkey to sign in without typing your password, so a fake login page has nothing to catch.
- Give each API key only the scopes it needs. A call outside them gets 403.
How we look for weak spots first
We use frontier AI security models to attack our own code before anyone else can, including OpenAI’s Daybreak Blue, its trusted-access program for cyber defenders. Every change to payments, logins, shop isolation and the Developer API is reviewed adversarially before it ships: 579 reviews in the last 60 days, 962 issues fixed before release. The reviewer did not write the change. It reads the change fresh and tries to break it. Once per release, a deep audit reads the code for risks that a review of one change cannot see.
Numbers: production database, server logs and error tracker, read on 4 November 2026 for 5 September to 3 November 2026, unless a case names a shorter window.