A data-leak forum account registered on 2 August 2026 advertised an alleged Żabka Polska dataset the same afternoon, asking €5,000. The listing claims roughly 541,000 Jira issues, 229,734 IT service-desk tickets and source code from 89 GitLab repositories. Ransomnews reviewed the sample archive attached to the post. The headline counts are internally consistent, and a single GitLab access token appears in all 89 repository dumps. Żabka Group has not confirmed any breach.
Editorial note: every claim about a breach at Żabka in this article originates with an anonymous seller and is reported as an allegation. Żabka Group has not confirmed an incident. Our review is limited to the sample files the seller published voluntarily, and confirms only that those files are internally consistent with what the listing describes. It does not establish that a breach occurred, how any data was obtained, or that the full dataset exists as advertised.
What the seller claims to have
The post is titled “[BREACH] Żabka Poland – Employee & Project Data Leak (August 2026)” and describes an alleged breach that happened “last week”. The seller lists four buckets: personal data pulled from Jira, confidential project documentation, source code with infrastructure-as-code, and live production credentials. Buyers are told to make contact through a Rambler webmail address. None of this has been corroborated by Żabka.
The named systems are specific enough to be checkable, which is unusual and, as it turns out, unwise. The listing calls out Nowa Kasa (the point-of-sale platform), Cyberstore, zMarket, SAP ERP with Master Data Governance, and the Lotto integration. It claims 2.7 million user references across more than 20 vendor domains, naming Accenture, Netguru, Onwelo, BlueSoft and Sygeon among them.
What the sample archive actually contains
The seller attached a samples.zip to the thread. It holds two directories: 48 Jira project exports as JSON, and 89 text dumps summarising one Git repository each. We reviewed both. Note the scale of what a sample is: each Jira export is capped at 50 issues, so the 1,102 tickets we could read are about 0.2 percent of the alleged dataset.
Every Jira export carries its own header stating the project key, the declared issue count, and how many were sampled. That header is the most useful thing in the archive, because it lets you check the seller’s arithmetic without touching the full dataset. It is worth being precise about what this proves: the totals below are the seller’s own declarations inside their own files, so consistency here means the sample is coherent, not that the underlying data is genuine.
| Claim in the listing | What the sample shows | Our reading |
|---|---|---|
| Approximately 541,000 Jira issues | 48 project exports whose declared totals sum to 541,463 | Consistent |
| 229,734 IT service-desk tickets | The ITSD export declares a total of 229,734 | Exact match |
| More than 20 vendor domains | 22 distinct email domains and 405 unique user addresses inside a 1,102-issue slice | Consistent |
| 89 Git repositories | 89 repository dumps, all referencing gitlab.com/zabkapolska/cs-market | Exact match |
| GitLab token reused across all repositories | One 62-character glpat- token embedded in all 89 clone URLs | Confirmed in the sample |
| Roughly 11,739 files | 2,398 file entries, with each repository capped at 50 files | Cap explains the gap, total unverifiable |
| Five 64-character production messaging passwords | Three 64-character secrets, one inside a repository named for production | Partly supported |
| 35,206 RODO and GDPR references | Four in the sampled slice | Not supported by the sample |
| Around 4,000 IBAN mentions | Zero in the sampled slice | Not supported by the sample |
Two numbers failing is not the same as the alleged dataset being fake, and the ones that match are not proof it is real. RODO references and bank details would cluster in HR, legal and finance projects, and those are exactly the projects the 50-issue cap under-samples. But the seller quoted both figures to five significant digits, and neither survives contact with the evidence they chose to publish. Treat the precise-sounding secondary counts as marketing until somebody sees the full set.
One GitLab token, 89 repositories
This is the finding that should concern Żabka most, if the sample is what it appears to be. Each of the 89 repository dumps opens with a header block containing the remote URL used to clone it, and that URL carries an embedded GitLab personal access token in the oauth2:glpat-…@gitlab.com form. We extracted every token-shaped string across all 89 files and deduplicated them. There is exactly one, 62 characters long, identical in all of them.
On the seller’s own evidence, then, the whole cs-market platform, 44 devops repositories, 26 backend services, seven frontends, plus the API gateway and tooling, was cloned with a single credential. Whoever holds that token holds the codebase. We have not tested it, and we will not: probing a credential found in a criminal listing would be unauthorised access, and it would also tell the holder that someone is looking. Żabka can check its own audit log in about a minute, which is where that question belongs.
The repository dumps are not empty shells either. They include Helm charts, ArgoCD environment values, Terraform modules and Istio service-mesh configuration. Inside those we found Cloudflare secrets in UUID form, a MongoDB cluster admin password that looks like it was typed in a hurry, and three 64-character secrets, one of them in a repository whose name ends in -prod. There are 178 references to Istio and a set of AKS cluster names that map out an Azure estate by function.
How fresh is the alleged data?
Fresh enough to matter, if it is authentic. The oldest ticket in the sample was created in May 2022 and the newest on 29 July 2026. Of the 1,102 sampled issues, 469 were created in July 2026 alone, which is what an export taken from a live, busy system looks like rather than an old archive resurfacing. The file timestamps inside samples.zip point to 1 August 2026, so the sequence the seller’s own artefacts describe runs: data pulled around the end of July, archive packed on 1 August, listing posted on 2 August.
The Jira instance referenced throughout is self-hosted at do.zabka.pl, visible in the REST API URLs on every issue record. Issue types come through in Polish (Zadanie, Zgłoszenie, Błąd, Incydent), assignee records carry full names, corporate addresses, avatar URLs and the Europe/Warsaw timezone, and the 1,102 sampled tickets reference 1,183 attachments and 1,494 comments that are not in the sample but would sit in a full set. We also counted 139 distinct live store identifiers scattered through ticket text. That is the part franchisees should care about.
The vendor spread is the other detail worth pausing on. In a slice this small we saw addresses at BlueSoft, Accenture, Onwelo, Sygeon, Billennium, Sii, NTT Data Business Solutions, Natek and a dozen more. If a full export followed the same distribution, this would not only be a Żabka problem. Every one of those suppliers would have staff names, internal ticket history and project context sitting in a file being sold for the price of a used car.
Why the timing is awkward
Alimentation Couche-Tard announced a €7.56 billion offer for Żabka Group on 31 July 2026, valuing the chain at 32.6 billion zloty and securing commitments covering at least 57.2 percent of the shares. The listing went up two days later. Subscriptions are expected to open around 26 August, after review by Poland’s Financial Supervision Authority.
We have no evidence the two events are connected, and the ticket timestamps in the sample suggest the data was assembled before the bid was public. But an alleged leak that documents a technology estate down to the cluster names, with a reused platform credential in the export, is a question worth asking during diligence on a company with roughly 13,000 stores and 11,000 franchisees. Under RODO, a controller has 72 hours to notify the Polish supervisory authority once it becomes aware of a personal data breach. Whether that duty has been triggered here is for Żabka to determine, and the company has said nothing publicly either way.
How Jira data usually walks out the door
Almost never through a Jira vulnerability. The pattern that has dominated since 2024 is stolen employee credentials, most of them harvested by infostealer malware, then used to log into Jira and export it wholesale. HellCat built an entire run on this, hitting Ascom, Schneider Electric, Telefónica, Orange Group and Jaguar Land Rover with the same approach. In the Jaguar Land Rover case, BleepingComputer reported that the credentials had been exposed for years and still worked.
Nothing in this sample proves that route, and we are not attributing it or suggesting it is what happened at Żabka. What the sample does show is the same downstream shape: a project-tracker export plus source code, of the kind taken with credentials rather than exploits. If you want the wider picture of how that access gets bought and sold before anyone posts a sale thread, our piece on initial access brokers in 2026 covers the market, and StealerCheck lets you look up whether a corporate address has surfaced in stealer logs.
Who is selling it?
Almost nobody, on the available evidence. The account behind the listing, handle Lumia, was created at 3:53 PM and posted the Żabka thread at 4:07 PM the same day. Fourteen minutes. It has two posts in total, zero reputation and no reaction score. The other post offers a “Telegram Database [28M]” with a one-word description.
A throwaway account is not proof of a fake dataset, and established brokers burn identities routinely. But it removes the usual credibility shortcut. There is no trading history to weigh, no prior sales to check, and no vouching. All a buyer has is the sample, which is exactly why the sample is worth taking apart in public. On the numbers that can be checked, it is internally consistent. On the numbers that cannot, it overreaches.
What Żabka’s suppliers and franchisees should do now
Treat this as a precautionary checklist rather than a response to a confirmed incident. The credential exposure is the part worth acting on first, because it is the only element with a live blast radius if the sample is authentic.
- Rotate every GitLab personal access token on the cs-market group, then audit what any broadly scoped token touched and when. A token that can clone 89 repositories should not exist, and its access log is the fastest route to a timeline.
- Treat every secret in the infrastructure repositories as potentially burned. Cloudflare API secrets, database admin passwords, messaging broker credentials and any 64-character value in ArgoCD values files. Rotate first, investigate second.
- Pull the Jira access logs for July 2026 and look for a single account performing bulk issue exports or heavy REST API pagination across 48 projects. That signature is hard to hide.
- Suppliers should check their own exposure. If your domain appears in Żabka’s Jira, your employees’ names, addresses and internal comments would be part of the package. Any notification duty that follows would be yours as well as Żabka’s.
- Franchisees should watch for targeted pretexting. Live store identifiers plus real service-desk ticket history is a ready-made script for someone phoning a store claiming to be IT support.
- Check corporate addresses against stealer logs and force password resets with MFA re-enrolment on anything that hits. Credential-derived Jira access is the dominant pattern in this class of incident.
What this means beyond Żabka
The interesting thing about a listing like this is not the personal data, it is the shape of the exposure it describes. A Jira export and a code repository are not usually thought of as crown jewels, and neither tends to sit behind the controls that protect a customer database. Yet between them they would give a seller the vendor list, the platform architecture, the cluster topology and a working credential, which is most of what an attacker needs to plan a second, worse visit.
Retail keeps learning this the expensive way. The systems that run stores are boring, distributed, integrated with a dozen suppliers, and rarely modelled as a single attack surface. Somebody almost certainly filed a ticket about a reused token at some point. If the dataset is real, it may well be in it.
We approached this the way we approach every listing on Ransomtracker: assume the seller is exaggerating, then check what they handed over. In this case most of it stood up to internal scrutiny. That is not a common outcome, and it is the reason we are reporting the allegation rather than ignoring it as noise. It is not the same as confirming a breach, and we are not doing that.
Żabka Group has made no public statement about the listing and has not confirmed a breach. We will update this article if that changes, and we will publish any response from the company in full. Press contact for this piece is via the Ransomnews editorial team.
Frequently asked questions
Has Żabka confirmed a data breach?
No. Żabka Group has made no public statement as of 3 August 2026 and has not confirmed an incident. The breach claim originates entirely with an anonymous forum listing, and our review covers the seller’s sample archive rather than any company disclosure.
Is the Żabka leak real?
Unconfirmed. The sample files the seller published are internally consistent with the listing, which is a point in favour of authenticity, but consistency inside a sample is not proof that a breach happened or that the full dataset exists. Only Żabka can settle that.
Was Żabka customer or loyalty data leaked?
Nothing of that kind appears in what we reviewed. The sample contains employee, contractor and supplier data from internal Jira projects, plus platform source code. We found no consumer records, no Żappka loyalty data and no payment card data in it.
How much is the alleged Żabka dataset being sold for?
€5,000, described by the seller as a symbolic price. Contact runs through a Rambler webmail address, which Ransomnews has redacted from the published screenshots.
Is the leaked GitLab token still valid?
Unknown, and we did not test it. Testing a credential found in a criminal listing would be unauthorised access. Żabka can answer the question directly from its own GitLab audit log.
Which Żabka systems appear in the alleged leak?
The Jira project keys in the sample map to an IT service desk, the Nowa Kasa point-of-sale programme, Cyberstore, zMarket, SAP with Master Data Governance, and a Lotto integration. The repository dumps all reference the cs-market retail platform group.
Does this affect the Couche-Tard takeover of Żabka?
There is no evidence the two are linked. The bid was announced on 31 July 2026 and the listing appeared on 2 August, with the sample data dated to late July, so the sequencing looks coincidental rather than causal.
What should a Żabka supplier do if its domain appears in the sample?
Start your own assessment rather than waiting. Under RODO the notification duty follows the data, so a supplier whose staff records turn out to be in a Żabka export may carry its own obligation independent of Żabka’s.
Sources and further reading
- Ransomnews Research Team review of the seller’s
samples.ziparchive, 3 August 2026 (48 Jira project exports, 89 repository dumps) - BleepingComputer: HellCat hackers go on a worldwide Jira hacking spree
- Notes From Poland: Couche-Tard launches €7.5 billion bid for Żabka
- Żabka Group corporate site
- Baker McKenzie: Poland security requirements and breach notification
- Ransomnews threat group catalogue
- Business ransomware protection, tested