Żabka Polska has confirmed a security breach after a dataset drawn from its systems was listed on a data-leak forum for €5,000. The retailer says an attacker reached technical systems used to communicate with its franchise network through an external service provider’s account late last week, and that it has notified Poland’s data protection authority and law enforcement. Żabka has not confirmed the seller’s claimed scale of roughly 541,000 Jira tickets and source code from 89 GitLab repositories. Ransomnews reviewed the sample archive, and the counts that can be checked hold up.
Update, 4 August 2026: Żabka has confirmed the incident. When this article first published, the company had said nothing and every claim rested on an anonymous seller. Żabka has since acknowledged unauthorized access through an external service provider’s account and notified the authorities. It has not confirmed the seller’s specific figures or that the dataset being sold is authentic in full. This article now separates what Żabka has confirmed from what remains the seller’s claim, and our sample review is unchanged.
What Żabka confirmed
Żabka issued a public statement on 4 August 2026. It said it had detected “unauthorized access to technical systems used to communicate with its franchise network” late the previous week, and that the access was detected and blocked under its security procedures. The company said the entry point was an account belonging to an external service provider, not a direct compromise of its own core infrastructure. Those details are drawn from Żabka’s statement as reported by Recorded Future News and Poland’s cyberdefence24.pl.
Żabka also said it notified Poland’s data protection authority (UODO) and law enforcement, and sought to reassure customers: it stated that the security of transaction data, the confidentiality of Żappka app data, and its operations remain unaffected. That reassurance matters, and it is consistent with our own read of the sample, which contained no consumer records, no loyalty data and no payment-card data.
What the company has not confirmed is just as important. Żabka has not endorsed the seller’s headline figures, has not said what volume of data left its systems, has not addressed the €5,000 sale, and has not attributed the intrusion to any named actor. So the incident is now established. The advertised scale is not. The rest of this article keeps those two things apart.
What the seller claims to have
The post is titled “[BREACH] Żabka Poland – Employee & Project Data Leak (August 2026)” and describes a 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. Żabka has confirmed an incident, but not this specific inventory.
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 dataset being sold.
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. Żabka’s confirmation of an incident raises the prior that it is, but does not by itself vouch for these numbers.
| 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 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. 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 data?
Fresh enough to matter. 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, and that lines up with Żabka detecting the access “late last week”. The sequence runs: data pulled around the end of July, archive packed on 1 August, listing posted on 2 August, company confirmation on 4 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, and it is the one Żabka’s statement speaks to most directly. In a slice this small we saw addresses at BlueSoft, Accenture, Onwelo, Sygeon, Billennium, Sii, NTT Data Business Solutions, Natek and a dozen more. Żabka says the intruder came in through an external service provider’s account. A Jira estate this densely populated with supplier staff is precisely the environment where one compromised contractor login opens the door to everyone else’s data.
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, and Żabka confirmed the breach four days after the bid. 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 suggest the data was assembled before the bid was public. But a confirmed breach that exposes a technology estate documented down to the cluster names, with a reused platform credential in the export, is now a live question for anyone doing diligence on a company with roughly 13,000 stores and 11,000 franchisees. Żabka says it notified UODO and law enforcement, which is the action RODO’s 72-hour rule requires once a controller becomes aware of a personal-data breach.
How the data most likely left
Almost never through a Jira vulnerability. The pattern that has dominated since 2024 is stolen employee or contractor credentials, many 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.
Żabka has now said the access came through an external service provider’s account. That is the credential route, not an exploit, and it fits the shape of the sample: a project-tracker export plus source code, taken with a valid login rather than a vulnerability. The company has not said how that supplier account was itself compromised, and the candidates are the usual ones: phishing, a reused password, or infostealer malware on a contractor’s machine. If you want the wider picture of how that access is 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
This is now a confirmed incident, so the checklist is active, not precautionary. The credential exposure is the part worth acting on first, because it is the only element with a live blast radius.
- 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.
- Review every external service provider account first. Żabka has named the vector as a supplier account. Force credential resets and MFA re-enrolment on third-party and contractor identities, and scope down what any single provider login can reach.
- Treat every secret in the infrastructure repositories as 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 are part of the package. Any notification duty that follows is 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.
What this means beyond Żabka
The interesting thing about this incident is not the personal data, it is the shape of the exposure. 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 hand an attacker the vendor list, the platform architecture, the cluster topology and a working credential, which is most of what is needed to plan a second, worse visit. That a single supplier account was the way in makes the point sharper.
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. It may well be in the leak.
We approached this the way we approach every listing on Ransomtracker: assume the seller is exaggerating, then check what they handed over. Most of it stood up to internal scrutiny, and Żabka has since confirmed the incident and the access route, which is close to what the sample implied. The scale the seller advertises is still unconfirmed, and that distinction is the one to hold onto.
Żabka Group confirmed the incident on 4 August 2026. We have quoted its statement above and will update this article as the company or investigators disclose more, and we will publish any further response in full. Press contact for this piece is via the Ransomnews editorial team.
Frequently asked questions
Has Żabka confirmed a data breach?
Yes. On 4 August 2026 Żabka confirmed unauthorized access to technical systems it uses to communicate with its franchise network, gained through an external service provider’s account late the previous week. It said the access was detected and blocked, and that it notified Poland’s data protection authority and law enforcement.
How did attackers get into Żabka?
Through an account belonging to an external service provider, according to Żabka’s statement. The company described it as unauthorized access to systems used with its franchise network, not a compromise of its core infrastructure, and did not say how the provider account itself was compromised.
Is the Żabka leak real?
The breach is confirmed; the advertised scale is not. Żabka has confirmed an incident and the access route but has not endorsed the seller’s figures of about 541,000 Jira tickets and 89 repositories. The sample Ransomnews reviewed is internally consistent with those figures.
Was Żabka customer or loyalty data leaked?
Żabka says transaction data, the Żappka app and its operations are unaffected. In the sample we reviewed we found employee, contractor and supplier data plus source code, with no consumer records, no Żappka data and no payment-card data.
How much is the Ż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. Żabka has not addressed the sale.
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 sample?
The Jira project keys 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, the listing appeared on 2 August and Żabka confirmed the breach on 4 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
- Recorded Future News (The Record): Żabka hacked through third-party account
- cyberdefence24.pl: Żabka confirms the incident (Polish)
- 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
- Baker McKenzie: Poland security requirements and breach notification
- Ransomnews threat group catalogue
- Business ransomware protection, tested