A Vendor Account, Jira and 89 Repositories: The Żabka Breach

On Monday 3 August 2026, at 22:20, the press office of Żabka Polska sent the Niebezpiecznik newsroom answers to four questions. Eight minutes later, at 22:28, the story went live. Between those two moments sits the whole modern art of incident response: a company confirms the event, but in a narrower scope than the attacker claims, and the reader is left with two versions of a single incident and has to decide which one to believe.

Żabka's version reads as follows. Late in the previous week the company detected unauthorised access to selected technical resources supporting the exchange of information between the franchisor and its franchisees. The access was gained using the account of an external service provider; it was detected and immediately blocked. According to the company's present knowledge, the intruder reached the ticket queuing system. Transactional data, the confidentiality of the Żappka app and operations remain unaffected. The matter was referred to the data protection officer, reported to the President of the Polish supervisory authority (UODO) and to law enforcement, and the individuals concerned are being notified directly.

The attacker's version, posted on a criminal forum alongside an offer to sell the data for five thousand euros, is several orders of magnitude broader. It speaks of 541,000 Jira issues across 48 projects, 229,734 tickets from IT and service desk teams, and source code from 89 Git repositories comprising nearly twelve thousand files. It also lists the part that should keep any infrastructure owner awake at night: production credentials, including a GitLab personal access token reused across all 89 repositories, messaging system passwords, Solace broker credentials, MongoDB administrator passwords and tokens hardcoded in .env files. On top of that, a map of the Azure/AKS environment with sixteen production database clusters and SSH access patterns to servers in individual stores.

We do not know which version is closer to the truth, and it is only fair to say so upfront. What we do know is that the architecture of this incident — entry through a third party's account, a stopover in the ticketing system, an exit with material touching the franchisor, eleven thousand franchisees and five partner firms at once — is precisely the scenario the authors of the NIS-2 Directive have been warning about for three years. And it is a scenario that can be reproduced in a company a hundred times smaller than Żabka.

A timeline worth taking apart

The events fell into a sequence that is itself a lesson. The samples published by the attacker indicate access to the infrastructure until at least 29 July. Żabka detected the unauthorised access late that same week. On the morning of Sunday 2 August, an enigmatic message suggesting a security problem, with no details, arrived in the inboxes of Niebezpiecznik and several foreign newsrooms. A few hours later, an advertisement with a data sample appeared on a criminal forum. In parallel, the attacker emailed employees of Żabka's subcontractors directly, telling them their data had leaked.

That last move matters and is rarely discussed. The perpetrator did not stop at the market — he began performing the function that under Article 34 GDPR belongs to the controller, namely notifying data subjects. He did it faster than anyone else and in a form nobody could control. For a response team this means the communications clock starts not when the decision to notify is made, but when the first subcontractor employee forwards that email to their manager.

Two other things were happening in the background. Over the same weekend, Żabka stores suffered a failure of the discount mechanism — random products rang up at absurd reductions, and some franchisees closed their shops until it was fixed. Żabka denied any link to the attack, pointing to an internal error in the configuration of the promotional mechanism. A few days earlier, Alimentation Couche-Tard, owner of the Circle K chain, announced its intention to tender for 100 per cent of Żabka Group shares at PLN 32 apiece, valuing the company at close to PLN 32.6bn. Niebezpiecznik noted that the absurdly low asking price for the data and the freshly created forum account suggest profit was not the main motive here — while also observing that the attacker was inside the infrastructure before the transaction became public knowledge.

An external vendor's account, attack vector number one

The sentence in Żabka's statement — "the unauthorised access was gained using the account of an external service provider" — is the most important and the most universal element of this case. There is nothing exotic about it. No zero-day, no advanced state-sponsored group, nothing that could not be repeated at a municipal utility, a law firm or a clinic.

In most organisations the vendor account is a peculiar creature. It is created quickly, because a rollout is underway and "the integrator's people need access yesterday". Permissions are granted generously, because nobody wants to revisit the subject next week. The name is often functional rather than personal, so it is unclear who is actually using it. It falls outside the company's offboarding process, because that process covers employees, not contractors. Multi-factor authentication is either switched off "because the integration does not support it" or runs on a shared token. And finally, when the project ends, the account stays — just in case something needs fixing.

The GDPR describes this relationship in Article 28. The processor must provide sufficient guarantees to implement appropriate technical and organisational measures, and the processing agreement must set out the subject matter, duration, nature and purpose of processing along with the processor's obligations, including assistance to the controller under Articles 32 to 36 and submission to audits. All of this is in the contracts. The trouble is that a contract does not disable an account, does not enforce MFA, and does not notice that a token issued for three weeks has been live for fourteen months. We covered this when the Polish supervisory authority fined DPD Polska: a chain of subcontractors is not a legal question but an operational one, and paper is not a safeguard. (in Polish)

The NIS-2 Directive and the Polish National Cybersecurity System Act go a step further and treat supply chain security as a standalone obligation of the entity rather than an appendix to a contract. An entity must take account of the vulnerabilities of each direct supplier, the quality of that supplier's cybersecurity practices, and the secure development practices it applies. In other words: your supplier's risk is your risk and your reporting obligation.

Jira is not a ticketing system. It is a secrets store

If one thing should survive from this incident, it is this. The ticket queuing system — Jira, a service desk, a helpdesk, any tracker — plays a role in most organisations that nobody formally assigned to it: it is an informal repository of credentials, configurations and test data.

The mechanism is mundane. A developer files a bug and, so the team can reproduce it, pastes a sample request complete with the authorisation header. An administrator documents a procedure and, for convenience, includes a fragment of a configuration file. An analyst attaches a production dump, because "it doesn't reproduce on synthetic data". A test account is given a real store identifier, because otherwise the integration will not pass. Each of these moves is individually rational. Together they build an archive that after a few years contains everything an attacker needs to move from a low-criticality system into the most critical ones.

Niebezpiecznik advanced exactly this hypothesis: the attacker probably used tokens, passwords and test accounts stored in Jira to reach further systems. If so, the sentence "the perpetrator gained access to the ticket queuing system" is both true and misleading — true as to the point of entry, misleading as to the reach.

The conclusions are easy to state and hard to implement, because they concern habits rather than technology. First: secret scanning cannot stop at code repositories; it must cover trackers, wikis and messaging tools. Second: ticket retention is not a disk space question but an attack surface question — 541,000 tickets means half a million opportunities for someone to have pasted something. Third: test data should be test data, not a copy of production, which is the same lesson Fortum and Pika paid for with fines upheld in court. (in Polish) ISO/IEC 27001:2022 names these requirements plainly in Annex A: control A.5.17 covers authentication information, A.8.4 access to source code, A.8.9 configuration management and A.8.33 protection of test information.

One token for eighty-nine repositories

Among the data the attacker boasts about is an item described as a "GitLab Personal Access Token (reused across all 89 repositories)". That is one line, and it contains a separate story about key management.

A personal token reused across every repository is convenient right up to the moment it has to be revoked. That is when it turns out it is embedded in dozens of CI/CD pipelines, in several internal tools, in the ArgoCD configuration, in scripts remembered only by the person who left. Rotating such a credential is not an hour's work — it is a project spanning weeks, run under pressure, while forensic analysis and correspondence with the supervisory authority proceed in parallel.

Here we reach the point that is hardest to get across in boardrooms. The real cost of this kind of incident rarely comes down to an administrative fine. It consists of rotating every credential that may have been exposed, reviewing the entire codebase for whatever else was hardcoded in it, verifying sixteen database clusters, rebuilding access patterns to store servers, and finally answering the question nobody wants to hear: if we do not know exactly when he got in, how do we know he is out. Source code disclosure has one further property — it acts with a delay. An attacker holding the code has time to hunt calmly for flaws no penetration test found, and can come back in six months.

The franchise seam, or eleven thousand controllers

Żabka described the affected assets as "supporting the exchange of information between the franchisor and its franchisees". That phrasing deserves to be taken seriously, because it describes a structure that is discussed far too rarely in a Polish cybersecurity context.

Żabka Group reports 13,063 stores as at the end of June 2026, with the network run by more than eleven thousand franchisees. Each of them is a separate entrepreneur. Each employs people or works with them on some other basis. Each — with respect to the personal data of their own staff — is an independent controller within the meaning of Article 4(7) GDPR, with their own obligations under Articles 33 and 34, their own liability, and their own, usually non-existent, breach register.

When a platform shared by the whole network breaks, the notification duty has no single addressee. It has thousands, and most of them learn about the event from a news portal or from the attacker's email rather than from a statement that knows the scope. The practical questions a franchise agreement must answer well before the day of the incident are these: who notifies the franchisee and within what time, in what respect the franchisor acts as a processor and in what respect as a separate controller, who prepares the assessment of risk to rights and freedoms, who bears the cost of notifying individuals, and who is answerable if the statement turns out to be imprecise.

The same logic applies well beyond franchising. Every accounting firm serving two hundred clients, every vendor of a line-of-business system used by forty municipalities, every operator of a booking platform used by two thousand hotels is the same kind of seam — a point at which a single technical event turns into hundreds of independent proceedings. We described exactly this mechanism after the Hotres breach, and the conclusion was identical: a hotel that was never itself attacked still had to carry out its own assessment and file its own notification. (in Polish)

Two clocks that start in the same minute

An organisation covered by both the GDPR and the National Cybersecurity System Act faces two independent calendars and two different authorities after an incident.

The first clock is Article 33 GDPR: notify the supervisory authority without undue delay and no later than 72 hours after becoming aware, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. Where the risk is high, Article 34 adds the duty to inform the data subjects in clear and plain language. Independently of that, Article 33(5) requires every breach to be documented, including those not reported, together with the reasoning behind the decision. It is worth recalling the now settled line: access to data by an unauthorised person is itself a breach within the meaning of Article 4(12), and the absence of proof that the data were actually exfiltrated is no argument for waiving the obligation.

The second clock is the NIS-2 regime transposed into Polish law: an early warning to the competent CSIRT within 24 hours of becoming aware of a significant incident, a full notification within 72 hours together with an initial assessment and indicators of compromise, and a final report within one month. It is a separate track, a separate form and a separate line of accountability, and its purpose is not the protection of personal data but the resilience of the service.

Both clocks start in the same minute, and both require somebody in the organisation to know they exist at all. In practice this is the most common gap we find in audits: the company has a procedure for notifying the data protection authority, because the GDPR has applied for eight years, and no procedure at all for notifying the CSIRT, because that duty is new.

Retail and food on the KSC register. Sixty days left

The amendment to the National Cybersecurity System Act entered into force on 3 April 2026 and widened the catalogue of sectors to areas the previous version did not cover — including the production, processing and distribution of food, ICT service management, waste management, the manufacture of machinery and equipment, and postal services. Sectors listed in the second annex generally confer the status of an important entity, with a maximum fine of EUR 7m or 1.4 per cent of worldwide annual turnover, while the scope of risk management obligations is identical to that applying to essential entities.

Self-registration on the register of essential and important entities opened on 7 May 2026 and closes on 3 October 2026. Sixty days remain from the publication of this piece. The state does not send individual notices — the duty to self-assess rests with the entity, and the size threshold begins at medium-sized enterprise, that is fifty employees or EUR 10m in turnover or balance sheet total.

For a retail network on Żabka's scale the classification is obvious. Far more interesting is the question of the rest of the chain: food producers supplying the network, logistics operators, vendors of point-of-sale and warehouse systems, firms maintaining the infrastructure. Some of them fall within the catalogue in their own right. The rest — even where the Act formally does not apply to them — will receive security requirements through contracts anyway, because a regulated entity must manage the risk posed by its suppliers. This is the moment at which NIS-2 stops being a large-company problem and becomes a condition for small companies to keep their contracts.

How to communicate an incident whose scope you do not yet know

Żabka's statement is formally sound: it confirms the event, identifies the vector, lists the steps taken and names the authorities notified. Yet it contains a construction that in cases of this kind almost always comes back to bite — the qualifier "according to our present knowledge" paired with an unqualified assurance that transactional data and the Żappka app remain unaffected.

The problem with that pairing is that the public remembers the reassuring half, not the conditional one. If forensic analysis widens the picture — and with access to code and credentials it almost always does — every subsequent correction will read as a retreat from earlier words, even if the first statement was entirely honest at the moment it was made.

The rule we apply in communications playbooks is simple and uncomfortable: in the first statement, describe what you know and name explicitly what you do not yet know, without narrowing the scope prematurely. "We have not confirmed access to systems X and Y and are verifying this" is communicatively weaker than "systems X and Y remain unaffected", but it has the advantage of never needing to be withdrawn. The same lesson emerged from the Hotres breach, where a statement inviting customers to presume the problem did not concern them complicated matters for every property using the system. (in Polish)

The second element is speed relative to the attacker. In this case the perpetrator was notifying subcontractors through his own channel before anyone else did. An organisation without a ready contact list for partners and franchisees and a fill-in-the-blanks statement template loses that race by a dozen or so hours — and those hours decide whose narrative becomes the default version.

Cybersecurity as a due diligence line item

The coincidence of dates — the announced intention to tender for 100 per cent of the shares and the disclosure of the incident a few days later — proves nothing in itself, and there is no reason to build theories on it. Niebezpiecznik fairly noted both possibilities while pointing out that the attacker was inside the infrastructure before the transaction became public.

There is, however, a general conclusion worth drawing, because it applies to any company preparing for a sale, an investor round or a major tender. The state of cybersecurity has stopped being a technical line item and become a valuation line item. Buyers now ask about recorded incidents over the past three years, penetration test results, certificates and the scope of the statement of applicability, dependencies on key suppliers, and how much a credential rotation would cost if repositories were exposed. The answer "we have had no incidents" is often worse than a description of an incident handled properly, because it sounds like a declaration of absent monitoring rather than absent events.

It works the same way in the other direction. A NIS-2 regulated entity asking a supplier about its security practices is not being officious — it is discharging its own statutory obligation. A supplier who can answer with specifics wins. A supplier who sends back a statement about its commitment to the highest standards is asked for evidence and usually does not have any.

Why Fib.Code for incidents and supply chain

We work on information security where three orders meet: legal, technical and organisational. We serve as data protection officer and information security officer, implement and audit management systems aligned with ISO/IEC 27001 and ISO 22301, prepare entities for their obligations under the National Cybersecurity System Act, and steer them through notifications to the data protection authority and the CSIRT when something does happen.

We work to three principles. First: scope follows risk analysis, not a product catalogue — until you know which assets and which dependencies are critical, every purchase is guesswork. Second: evidence outranks documentation — a restore test record, a screenshot from an access review and a list of vendor accounts with their last-used dates count for more than a policy signed and filed away. Third: a procedure nobody has rehearsed is not a procedure, it is an intention.

The outcome of working with us is a set of materials you can put in front of an inspector, an auditor and a buyer: an asset and supplier register with assigned risk, a statement of applicability, an incident playbook with both notification tracks and statement templates, a business continuity plan with tested recovery times, and a review schedule that keeps all of it alive after the project ends.

What to do this week: review your vendor accounts

Call one forty-five-minute meeting with the person responsible for IT, the data protection officer and someone from the board, and work through seven questions, writing a name and a date next to each.

First: how many active accounts belong to external entities, who specifically uses them, and when was each last used. Second: which of them operate without multi-factor authentication, and what stands in the way of changing that by the end of the month. Third: has anyone ever searched our Jira, wiki and service desk archive for passwords, tokens and production data — and if not, who will do it and by when.

Fourth: where is the list of credentials used in CI/CD pipelines, and how many hours would rotating them take if we had to do it today. Fifth: do we know which CSIRT team we report an incident to, who has access, and whether that person has a deputy while on leave. Sixth: have we filed an application for entry on the register of essential and important entities — and if we concluded it does not apply to us, where is that assessment written down. Seventh: do our contracts with key suppliers and partners specify the deadline and form for notifying us of an incident on their side.

If any of these questions is met with silence in the room, you have just found your starting point. The 3 October 2026 deadline is fixed, and reviewing vendor accounts is the only item on this list that requires no budget — just a decision and two hours of somebody's time.

Get in touch: l.grabowski@fibcode.com | fibcode.com/en/contact. Directly related material: the Hotres breach and the line between controller and processor (in Polish), the DPD Polska fine and the subcontractor chain under Article 28 GDPR (in Polish), self-identification and entry on the register of essential and important entities — three angles on the same problem: someone else's account, someone else's system, your accountability.