Breach clock · shipping agents keep losing customer data
Since the latest claimed leak.
Kakobuy is the third agent in this timeline. The companies change; the customer data — names, phones, addresses and orders — does not.
The timeline
- PandaBuy1.3m accounts
- Sugargooclaimed, never published
- Kakobuy854,150 address records claimed
Blog 002
What the claimed Kakobuy data leak actually contains.
An extortion site claims it took 4.87 gigabytes of Kakobuy customer data and is now billing customers ninety-nine dollars each to be left out of it. We read its inventory files instead of taking the claim at face value — here is what they support, what they do not prove, and why nobody should pay.
A shipping agent is an unusual kind of company to hand your details to.
A shop knows what you bought. A courier knows where you live. An agent is both, on purpose, for years — because the whole job is to receive your parcels under their address and forward them under yours.
So the file builds up. Your legal name, because customs wants it. Your street, because somebody has to knock. Your phone, because the last mile texts you. What you ordered and what you paid. And, if you ever took one of those share-to-earn deals, the handle of the account you posted the haul from.
One company holding all of that is fine right up until the moment it is not.
What is being claimed
Since late August a site at kakobuyhack.com has been publishing what it says is data taken from Kakobuy. Its own inventory labels the source staff_user_scrape. That is where the word “staff” comes from; it is the attacker’s label, not a term Kakobuy has confirmed. The author writes as a cat called Ginger. The tone is jokey. The material is not.
- Aug 4, 2026The date baked into the packaged archive’s filename — users_addresses_devices_20260804_070255.zip. The busiest day in the raw order dump is August 3. Both point at a scrape window in early August.
- Aug 25–29Four public “drops” — the site says 5,000 accounts with address rows attached, then a thousand more per day.
- Kakobuy’s replyAccording to the site: first that there was no leak, then silence, then that 1–2% of customer data was affected. We could not find any statement from Kakobuy on their own site, and the homepage carried no notice when we checked.
- The demand$99 in crypto, per person, to be deleted from the file. Not from the company — from you. The site says Kakobuy came back to the table and then walked.
- Sep 1, 2026The stated deadline for publishing everything, unredacted, at midnight China time.
A ransom note is not evidence. It is an advertisement written by somebody with an obvious reason to exaggerate. So we ignored the prose and went looking for the parts of the site a stranger can check.
There turn out to be quite a few.
He published his own inventory
The counters on that page are not decorations. They are fed by two JSON files sitting in the open next to the HTML, and those files are far more specific than anything in the write-up.
{
"source": "staff_user_scrape inventory snapshot",
"totals": {
"folder_size_gb": 4.87,
"core_records": 1156754,
"other_table_records": 5011475,
"jsonl_rows_approx": 6168283,
"surface_datasets_with_data": 20
},
"unique_identifiers": {
"emails": 566867,
"phone_numbers": 686669,
"names_usernames_nicknames_recipients": 405248
}
… core[] and surfaces[] follow — see the ledger below
}Nobody made him write this. It is his own accounting of the haul, served as a static file, and it is the spine of everything below.
The inventory says 854,150 user IDs had an address attached
“6.2 million” is the number on the poster, and it is the number every video repeated. It is also the least useful figure in the file.
Rows are not people. Look at what the rows actually are, from his own surfaces[] list:
| What the folder contains | Saved as | Rows |
|---|---|---|
| VIP / points log | user_log_vipList_html | 1,245,430 |
| Affiliate codes | cps_affiliate_codeList_html | 1,038,356 |
| Email send log | etc_email_userSend_html | 828,754 |
| Recharges | pay_recharge_index_html | 538,204 |
| Share rewards (orders) | activity_share_applyPo_html | 320,186 |
| Short links | etc_link_index_html | 283,117 |
| Balance ledger | pay_money_index_html | 232,985 |
| Orders | order_order_index_html | 208,510 |
| Coupon activations | shop_coupon_rulelog_html | 139,434 |
| Share rewards (waybills) | activity_share_apply_html | 135,484 |
| 10 smaller surfaces | — | 41,015 |
| Other table records | 5,011,475 |
Five of the six million rows are logs. A points ledger with 1.2 million lines. An affiliate-code table with a million. A record of every marketing email sent. One person generates dozens of those rows without doing anything unusual.
The honest headcount is in the identifier counts, and it is smaller and much more concrete:
566,867 unique email addresses. 686,669 unique phone numbers. 991,388 address rows across 854,150 distinct user IDs.
So: not six million victims. On the order of half a million to eight hundred thousand real people, most of them with a home address attached. That is smaller than the poster and worse than a password dump, and we would rather print the number that survives arithmetic than the one that trends.
One more figure argues against the attacker’s completeness claim: the users table holds 92,096 rows, while the address table references 854,150 distinct user IDs. Those do not reconcile. Whatever he took, he did not take all of it evenly — which is also the first clue about how he took it.
The folder names say how it happened
Read that middle column again.
order_order_index_html → /order/order/index pay_recharge_index_html → /pay/recharge/index user_log_vipList_html → /user/log/vipList cps_affiliate_codeList_html → /cps/affiliate/codeList etc_email_userSend_html → /etc/email/userSend
Those are not database tables. They are page URLs with the slashes turned into underscores, and the _html suffix says what was saved: pages. The declared source on both his JSON files is the string staff_user_scrape.
The filenames are consistent with saved internal web pages rather than a direct database dump. Together with the attacker’s own staff_user_scrape label, that supports an internal-interface scrape. It does not prove what Kakobuy called that interface or how access was obtained.
That interpretation also explains the mismatch. A direct users-table export would normally give one coherent population. A paginated scrape can stop partway through one section while collecting more rows from another, which is consistent with 92,096 users sitting next to 854,150 user IDs in the address export.
The evidence supports a claimed scrape of internal pages. It does not independently establish the attacker’s full story.
We cannot tell you how the door opened — stolen staff credentials, an admin route reachable without them, a contractor account nobody closed. The file does not say and we are not going to guess. What the file does establish is the shape: sustained authenticated-looking access to internal screens, not a leaked backup.
We checked whether the index is real
The site offers a “check if you are in it” box. Those are usually theatre. This one is not, and the way it works is checkable without trusting anybody.
The page hashes what you type in your browser and asks the server only for a shard of an index, named after the first two characters of that hash:
const digest = await crypto.subtle.digest("SHA-256", data); … const hash = await sha256Hex(email); const prefix = hash.slice(0, prefixLen); // prefixLen = 2 const res = await fetch(`proof/${prefix}.json`, { cache: "no-store" });
The plaintext address really does stay in the browser. That is the one claim on the site we can confirm outright — it is four lines of his own JavaScript. What still reaches his server is the two-character hash prefix and your IP, and the page loads Google Analytics and Microsoft Clarity alongside it. Checking is not anonymous. It is just not a plaintext hand-over.
Then we did the arithmetic he was hoping nobody would do. He claims 566,867 indexed emails across 256 shards. We pulled a single shard — hashes and the integer 1, no personal data in it — and counted.
entries in shard "00" 2,235 × 256 shards 572,160 claimed emails indexed 566,867 difference 0.93% ← what an even hash spread looks like
A fabricated index does not land within one percent of its own claimed size by accident. Something real was counted. It does not prove the data came from Kakobuy — only Kakobuy can confirm that, and they have not — but the index is not a bluff about its own scale.
He is not bluffing about the scale
He has published four sample “drops” — 5,000 accounts in total, with the street, city and region stamped over. Two questions decide how much the rest of his claim is worth, and both can be answered without reproducing a single record.
Is he recycling the same people to look busy? No. Across the four files there are 5,000 rows and 5,000 distinct email addresses — no duplicates, and no overlap between any two drops. Each one is fresh material.
Do the drops and the hash index describe the same haul? Yes. We hashed every address in the drops the way his own page does and looked each one up in his 256-shard index.
found in his index 4,998 not found 2 shards unreachable 0 match rate 99.96%
Two artifacts he published separately, agreeing at 99.96 percent. Fabricated data does not do that.
The drops also answer the question the row counts left open. Every one of the 5,000 accounts was registered in July or August 2026 — 3,330 in July, 1,670 in August, none earlier. And their user IDs span a range of 92,057, against a users table of 92,096 rows.
That is one row per consecutive ID, with almost no gaps.
So his users file is not a sample of Kakobuy’s customers. It is an unbroken block of the most recent ~92,000 registrations — which is exactly the shape you get when somebody opens an admin list sorted newest-first and pages until they stop. It explains the mismatch above: the address screens gave up far more of the customer base than the user screens did.
It also means the exposure is not evenly spread. For the account fields, the people most likely to be in this file are Kakobuy’s newest customers — the ones who signed up in the two months before the scrape.
One last thing worth knowing if you are looking at those drops yourself. The site presents the masking as a courtesy, and street, city and region genuinely are stamped. But across all 5,208 address rows in the four drops, the recipient name, the phone number and the postal code are untouched. In most countries a name plus a postcode is a household. The redaction is thinner than the word suggests.
What is in the file
From his published field list, cross-checked against the tables in the inventory:
- Login email and registration email
- Username, nickname, numeric user ID
- Phone number on the account, and on every shipping label
- Recipient name — the person who opens the door
- Street, city, region, postal code
- Signup IP and last-login IP
- Device fingerprint and user agent
- Orders: what, when, and the warehouse notes
- Top-ups: method, amount, status
- Balance, points, coupons claimed
- Support notes staff typed about you
- Referral codes and the short links you shared
- Share-reward posts, including the TikToks
- Every marketing email they sent you
There is a reason this is worse than the breaches people are used to shrugging off.
A leaked password is a problem you can end in ninety seconds. You change it. Done. Nothing in the list above can be changed in ninety seconds. Your legal name cannot be rotated. Your street cannot be rotated. The phone number that has been on every parcel you have ever received cannot be rotated without a genuinely miserable afternoon.
And the pieces compose. A referral code links to an email; an email links to a shipping profile; a shipping profile links to a door. His own aggregates count 403,479 share-reward rows tied to TikTok — which means for hundreds of thousands of accounts the file contains both a public handle and the private address behind it.
That join is the actual harm. Not the row count.
A password leak tells somebody how to get into your account. This one tells them where you sleep.
Do not pay the ninety-nine dollars
There is no version of this where paying gets your data deleted.
The offer was $99 in crypto to be erased from “every database, backups included.” Read that as a product and it falls apart immediately. You cannot see his storage. You cannot audit a deletion. The transaction is irreversible and unattributable, and the only evidence you would ever get that it worked is his word — from a person whose current business model is publishing other people’s home addresses.
He also stated he had already handed partial data out in public drops. Deleting his copy would not recall those. And an address that has been copied once is not a thing anybody can un-copy for you.
Paying does one reliable thing: it confirms to an extortionist that a confirmed-affected email belongs to somebody who pays. That is a list worth more than ninety-nine dollars to the next person who buys it.
We will go further, because this is the part of the story that actually deserves the anger.
Extorting a company is one thing. Through August this site extorted the victims — individually, at ninety-nine dollars a head, on a countdown. It ran a page naming individual customers, with their real phone numbers, as punishment for saying the wrong thing about the breach online, and invited readers to call them.
Whatever Kakobuy did or did not do, the people on that page are not the ones who failed here.
That is why this post has no screenshots. We could not photograph that site without republishing somebody’s phone number, and cropping the evidence is precisely the thing our other post refuses to accept from anybody else. The JSON above is better evidence anyway. You can fetch the same URLs and diff them; you cannot do that with a JPEG.
This is the third time
The reason to write any of this down is that it is not an accident that keeps happening to one unlucky company.
- Mar 2024 · PandaBuy1.3 million verified email addresses, with names, phone numbers, IP addresses, physical addresses and order details, posted to a hacking forum and confirmed independently by Have I Been Pwned. The attacker cited PandaBuy API vulnerabilities. PandaBuy paid a ransom — and was extorted a second time that June for a claimed 17 million rows. Reporting at the time described the company deleting user questions on Discord and Reddit rather than disclosing.
- Apr 2024 · SugargooThe same two actors claimed a second agent weeks later. Smaller and never published — mostly user activity and settings, including email addresses. It went largely unnoticed until Sugargoo administrators began timing out people who asked about it in their own Discord, which is what made it news.
- Aug 2026 · KakobuyEverything above. Plus a footer on the same site claiming 6,074,001 rows from MuleBuy, with no proof files published for it at all — so treat that one as a claim and nothing more, which is exactly how we are treating it.
The pattern is the same every time, and it is three steps long:
Deny it. Delete the questions. Concede a percentage.
Not one of these companies published a breach notice on its own front page. In each case customers found out from the attacker, from a screenshot, or from a stranger on TikTok. That is a disclosure practice, and it is the industry’s, not one firm’s.
None of this should have been your job
They lost your data. They have not told you. They are not going to fix it for you. Everything below is work that fell to you because of that, and they are not the first — it went the same way at PandaBuy and at Sugargoo.
Assume the address is out. Not because we know your row is in the file, but because everything here is worth doing anyway and none of it costs money.
Change the password everywhere you reused it. Not on the agent — on the email account that agent knows about. Order confirmations make a very good target list.
Turn on two-factor authentication on that email. The file contains no passwords. It contains an enormous amount of material for talking somebody into a reset.
Expect the scam to be well-informed. The convincing version is not a stranger asking for your card. It is a text about a specific parcel, using your real name and your real order, from a number you have no reason to doubt. Treat any delivery message that wants a payment or a login as false, and go to the site yourself.
Search your address for yourself. Have I Been Pwned carries the PandaBuy set already, and it is free.
Use an address you can abandon. A parcel locker, a pickup point, a forwarding service. This is the only item on the list that actually solves the problem rather than mitigating it, and it is the one nobody wants to hear.
What this board does about it
Three of the agents named above are rows on this scoreboard.
We have not added a security column, and we are not going to invent one this week. We would have to score companies on something we cannot measure from the outside, and a comparison that grades an unmeasurable thing is the failure mode this whole site exists to complain about. What we can do is what we just did: write down what is checkable, show our arithmetic, and archive the source so it survives the page coming down.
We are also a shipping agent. NinjaBuy holds the same kind of file on its own customers, and it would be worth exactly nothing for us to stand here and assure you it is safer. We have not been audited either. Nobody reading this should take a security claim from a company that is also selling shipping — including ours.
What we will say is the same thing we say about prices, which we also decline to publish for ourselves until we can stand behind them: the standard applies to us first.
If we ever lose your file, you will hear it from us, on this domain, before you hear it from a cat.
Nobody paid for this post. Nobody paid for the board. There are no affiliate links on this site — not to Kakobuy, not to the agents in a better position this week, not to us.
Where this came from
- Every figure attributed to the attacker comes from files he serves himself at kakobuyhack.com — counts.json, fun_stats.json, proof/manifest.json, proof/00.json and app.js. Captured anonymously on 2026-08-29 at 22:36 UTC with their response headers and a sha256 of each file.
- We did fetch the four public sample drops, on 2026-08-30, to test the two claims in “He is not bluffing about the scale” — whether the drops are padded, and whether they and the hash index describe the same corpus. They contain real people’s data, so they are held in the same private archive under a restricted folder, nothing was copied out of it, and every figure derived from them in this post is an aggregate. No record, and no fragment of one, appears here or anywhere we publish.
- The PandaBuy figures are from Have I Been Pwned’s breach record and contemporaneous reporting by BleepingComputer; the Sugargoo account is from vx-underground’s April 2024 write-up. The MuleBuy claim has no supporting files and is reported here only as a claim.
- Kakobuy has published no statement we could find. Their homepage carried no notice on 2026-08-29. If they publish one, this post gets updated rather than quietly corrected.
You can change a password. You cannot change which house is yours.