Żabka, Poland’s largest convenience store chain with over 10,000 locations, confirmed it was breached through a compromised third-party account. Attackers accessed the company’s Jira project management environment and according to reporting by The Record, made off with passwords, authentication tokens, API keys and source code. The stolen data was advertised for sale online at €5,000. Żabka confirmed the incident to Polish authorities and stated that payment data and store operations were not affected.
The company described the incident as unusual in public communications which is one way to characterise a breach that handed attackers the keys to your internal development infrastructure. Jira environments routinely contain project documentation, integration credentials and access tokens that connect directly to production systems. What the attackers actually extracted beyond what Żabka has disclosed is not yet confirmed.
One Third-Party Account, Full Jira Access
The attack vector here is worth examining carefully. No vulnerability was exploited in the traditional sense. No CVE has been assigned. The attacker compromised an account belonging to an external party with legitimate access to Żabka’s Jira instance and that was enough.
This is the supply chain access problem in its most direct form. The organisation’s own security controls are largely irrelevant when a trusted third party holds credentials that grant internal access. Żabka’s perimeter, whatever it looked like, was not the point of entry. The attacker went around it.
Cybernews which reviewed the incident, reported that the breach was traced to an external service provider. The Record’s reporting confirms the third-party account as the entry point. Neither Żabka nor the sources covering this incident have named the third party and Żabka has not disclosed how long the attacker had access before detection.
API Keys and Source Code Are the Longer-Term Risk
The €5,000 asking price for the stolen data is low enough to suggest either a small dataset or a seller testing the market. Either way, the more consequential question is what the stolen API keys and authentication tokens connect to.
API keys extracted from a Jira environment do not expire when a breach is discovered unless they are explicitly rotated. If Żabka has not already invalidated every credential, token and key that was accessible within that Jira instance, those credentials remain live. Source code in the wrong hands is a slower-burning problem, it gives future attackers a detailed map of how internal systems are built and where to look for weaknesses.
Żabka has not confirmed publicly whether credential rotation has been completed. That is the most important operational question the company has not yet answered.
The Third-Party Access Problem Runs Across European Retail
The Żabka incident sits in a well-established pattern. Retail organisations routinely grant Jira, Confluence and similar collaboration platform access to external development partners, logistics vendors and IT contractors. Those accounts are frequently not subject to the same MFA requirements and access reviews applied to internal employees. When one of those accounts is compromised, through credential stuffing, phishing or infostealer malware, the attacker inherits whatever permissions the third party held.
The Marks and Spencer breach in April 2025 attributed to Scattered Spider by investigators including CrowdStrike, followed a different entry method but the same structural weakness, a third party with internal access became the point of failure. M&S quantified roughly £300 million in operating profit impact. Żabka’s operational damage appears far more limited but the structural lesson is identical.
I would be cautious about the framing in some coverage that presents the payment data and operational continuity assurances as a near-clean outcome. The breach of development credentials and source code is not a minor incident. The damage will depend on what those credentials connected to and how quickly they were rotated neither of which Żabka has fully addressed in public.
Audit Third-Party Access Before Regulators Ask You To
Any organisation running Jira, Confluence or similar platforms with external contributor access should pull an active user audit this week. The question is not whether your third parties have access. They do. The question is whether that access is scoped correctly, whether MFA is enforced without exception and whether inactive accounts have been removed.
Under NIS2 which Sweden’s Cybersäkerhetslagen brought into force on 15 January 2026, supply chain security controls are an explicit Article 21 requirement. An organisation that cannot demonstrate it has reviewed and governed third-party access to internal systems is not compliant regardless of how clean its own infrastructure is. The Żabka incident is the kind of case supervisory authorities will reference when they begin enforcement reviews.
Rotate credentials immediately following any third-party account compromise. Do not wait for forensic confirmation of what was accessed. Rotate everything that was accessible, then scope the investigation. The alternative is leaving live credentials in circulation while you work out exactly what was taken.
References
- Polish Convenience Store Chain Żabka Hacked Through Third-party Account
- Żabka Polska Breached Through External Service Provider
- Żabka Confirms Major Cyberattack
- Cyberattack Hits Polish Convenience Chain Żabka
- NIS2 Directive Full Text, Article 21
This post is also available in:
Svenska
Related News
Philips Confirms Breach, GE Investigates Clop Data Theft Claims
General Electric and Philips have confirmed they are investigating claims from the Clop extortion gang that it stole data from their systems, joining oil giant…
August 18, 2026 
