Threat reportData BreachTL-2026-1834

Alleged Żabka Polska Breach: 541K Jira Issues, 230K IT Tickets, 89 GitLab Repos, and Cloudflare/MongoDB/Broker Credentials Offered for €5,000

highACTIVE

A forum account created 2026-08-02 and used only once claims to be selling a full data dump from Żabka Polska — Poland's largest convenience-store franchise (11,000+ locations) — for €5,000: exactly 541,463 Jira issues, 229,734 IT service-desk tickets, source code from 89 GitLab repositories, Cloudflare API keys, a MongoDB admin password, and messaging-broker credentials, including one reusable 62-character GitLab access token embedded across all 89 repo clone URLs.

Key facts for Żabka Polska Jira GitLab leak

Identifiers	TL-2026-1834
Severity	HIGH
Exploitation status	Exploited in the wild
Affected products	Żabka Polska (internal) Nowa Kasa point-of-sale platform; Żabka Polska (internal) Cyberstore platform; Żabka Polska (internal) zMarket platform; Atlassian Jira (issue tracker instance used by Żabka Polska); GitLab Inc. GitLab (89 self-hosted or Group-hosted repositories); MongoDB Inc. MongoDB (administrative-level database instance); Cloudflare Inc. Cloudflare account API; SAP SE SAP ERP (integration referenced in leaked tickets)
Weaknesses (CWE)	CWE-798, CWE-522
Tools	Atlassian Jira, Cloudflare, GitLab, MongoDB, SAP ERP
MITRE ATT&CK techniques	T1074 Data Staged, T1078 Valid Accounts, T1087 Account Discovery, T1119 Automated Collection, T1195 Supply Chain Compromise, T1199 Trusted Relationship, T1213 Data from Information Repositories, T1528 Steal Application Access Token, T1550 Use Alternate Authentication Material, T1552 Unsecured Credentials, T1560 Archive Collected Data, T1567 Exfiltration Over Web Service and 6 more in the attack flow
Motivation	FINANCIAL
Target sectors	retail, convenience retail, ecommerce, franchise operations
Target regions	poland, Central and Eastern Europe, Europe
Detection rules	9 (1 shown free)
Sources	7 cited sources

Detection coverage for Żabka Polska Jira GitLab leak

As of 2026-08-03, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1834 across Splunk SPL, Microsoft KQL and Sigma, covering 27 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: Reused GitLab Personal Access Token Across Multiple Repository Clone URLs — SPL

Detects a single GitLab personal/deploy access token (embedded oauth2 clone-URL form) used to clone or read more than a handful of distinct repositories within a short window — the single point-of-failure credential-reuse pattern reported in the TL-2026-1834 Żabka listing, where one 62-character PAT was allegedly embedded across all 89 leaked repository clone URLs (CWE-798).

Languages: Splunk SPL, Microsoft KQL, Sigma
ATT&CK: T1552.001, T1213.003, T1528
Data sources: gitlab_audit_logs, gitlab_api_logs
Severity: high
Confidence: high

Splunk SPL

index=gitlab (sourcetype="gitlab:audit" OR sourcetype="gitlab:api") earliest=-24h
| rex field=url "oauth2:(?<token_prefix>[A-Za-z0-9_-]{6})"
| eval token_id=coalesce(token_prefix, access_token_id)
| where isnotnull(token_id)
| stats dc(project_path) AS distinct_repos, values(project_path) AS repos, dc(clientip) AS distinct_source_ips, earliest(_time) AS first_seen, latest(_time) AS last_seen by token_id, username
| where distinct_repos > 5
| eval duration_minutes=round((last_seen-first_seen)/60,1)
| table first_seen, last_seen, username, token_id, distinct_repos, repos, distinct_source_ips, duration_minutes
| sort - distinct_repos

Microsoft KQL

GitLabAuditLogs_CL
| where TimeGenerated > ago(24h)
| where EventType_s in ("repository_clone", "personal_access_token_used", "project_read")
| extend TokenId = extract(@"oauth2:([A-Za-z0-9_-]{6})", 1, TargetDetails_s)
| where isnotempty(TokenId)
| summarize DistinctRepos = dcount(ProjectPath_s), Repos = make_set(ProjectPath_s, 20), DistinctSourceIPs = dcount(SourceIP_s), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by TokenId, ActorUsername_s
| where DistinctRepos > 5
| extend DurationMinutes = datetime_diff('minute', LastSeen, FirstSeen)
| project FirstSeen, LastSeen, ActorUsername_s, TokenId, DistinctRepos, Repos, DistinctSourceIPs, DurationMinutes
| order by DistinctRepos desc

Sigma

title: Reused GitLab Personal Access Token Across Multiple Repository Clone URLs
id: 6f1a1e9e-1834-4a10-9c2a-a10000000001
status: experimental
description: Detects a single GitLab personal/deploy access token embedded in oauth2 clone-URL form being used to clone or read more than a handful of distinct repositories within a short window, consistent with a single point-of-failure credential-reuse pattern.
references:
    - https://securityaffairs.com/196510/data-breach/alleged-zabka-breach-exposes-jira-data-source-code-and-api-keys.html
author: AII-Detector — ThreadLinqs Intelligence
date: 2026/08/03
tags:
    - attack.credential-access
    - attack.t1552.001
    - attack.collection
    - attack.t1213.003
    - attack.t1528
cve: []
logsource:
    category: application
    product: gitlab
detection:
    selection:
        url|contains: 'oauth2:'
    condition: selection | count(distinct_project_path) by token_prefix > 5
    timeframe: 24h
falsepositives:
    - Legitimate CI/CD service accounts using one scoped deploy token across a small, known set of pipeline repos
    - Group-level runner registration tokens intentionally shared within a single GitLab group
level: high

Known false positives:

Legitimate CI/CD service accounts using one scoped deploy/runner token across a small, known set of pipeline repositories
Group-level shared runner registration tokens used intentionally across every project in a GitLab group

Tuning notes: Tune the distinct-repo threshold (default >5) to the organization's normal per-token repo-access pattern; exclude known CI/CD service-account token IDs via an allowlist lookup before alerting.

8 more detection rules (Splunk SPL, Microsoft KQL, Sigma) · unlock with TL Creds. Sign up free to unlock the detection rules or query them with the Threadlinqs MCP server (Purple)

Reused GitLab Personal Access Token Across Multiple Repository Clone URLs — KQL · unlock with TL Creds
Mass Bulk Export of Jira/Service-Desk Records with Local Archive Staging — KQL · unlock with TL Creds
Cross-Service Stolen-Credential Reuse Followed by Exfiltration to Newly-Observed Domain — KQL · unlock with TL Creds
Reused GitLab Personal Access Token Across Multiple Repository Clone URLs — Sigma · unlock with TL Creds
Mass Local Archive Creation Following Bulk Ticketing/Repository Export — Sigma · unlock with TL Creds
Outbound Connection to Newly-Observed Domain Following Cross-Service Token Reuse — Sigma · unlock with TL Creds
Mass Bulk Export of Jira/Service-Desk Records with Local Archive Staging — SPL · unlock with TL Creds
Cross-Service Stolen-Credential Reuse Followed by Exfiltration to Newly-Observed Domain — SPL · unlock with TL Creds

Indicators of compromise for Żabka Polska Jira GitLab leak

As of 2026-08-03, Threadlinqs Intelligence tracks 27 indicators of compromise for TL-2026-1834.

27 indicators of compromise · unlock with TL Creds. Compare plans

How Żabka Polska Jira GitLab leak works

Third-party reviewer Ransomnews confirmed the headline record counts as exact matches, though secondary claims (35,206 GDPR-reference records, ~4,000 bank-account mentions) largely did not surface in the reviewed samples, and Żabka has issued no public confirmation.

On 2026-08-02, a brand-new account on an underground cybercrime forum posted a single listing — 14 minutes after registration and with zero prior trading history — offering a purported full data dump from Żabka Polska for €5,000. Żabka Polska is the franchise-operating subsidiary of publicly traded Żabka Group, Poland's largest convenience-store network with more than 11,000 locations; notably, the listing appeared just two days after Alimentation Couche-Tard publicly announced a PLN 32.62 billion (~€7.56B/US$8.6B) agreement to acquire a controlling stake in Żabka Group (2026-07-31), a timing coincidence that raises the possibility of deliberate extortion or reputational-pressure leverage tied to the pending tender offer, though this motive is not confirmed by any source.

The claimed dump spans internal collaboration and DevOps tooling rather than customer-facing systems: exactly 541,463 Jira issues and 229,734 IT service-desk tickets, plus source code from 89 GitLab repositories. Reporting further details the repository architecture: the leaked estate includes the internal cs-market platform, comprising 44 DevOps repositories, 26 backend services, 7 frontend applications, and an API gateway — giving a buyer not just code but a structural blueprint of how Żabka's retail platform is decomposed and deployed. Most significantly, the seller claims a single 62-character GitLab personal access token was embedded across all 89 repository clone URLs — a credential-reuse pattern that, if the token is still valid, would grant uniform access to Żabka's entire disclosed source-code estate rather than requiring per-repository compromise. The same repositories reportedly contain hardcoded Cloudflare API keys, a MongoDB administrative password, and messaging-broker credentials within infrastructure-as-code files — a textbook case of CWE-798 (Use of Hard-Coded Credentials) at organizational scale.

Leaked Jira/service-desk tickets reportedly reference Żabka's internal technology stack by name: the Nowa Kasa point-of-sale platform, the Cyberstore and zMarket platforms, SAP ERP, and a Lotto (lottery) integration, plus IT vendors Accenture, Netguru, and BlueSoft among more than 17 additional third parties named across the tickets — giving any buyer a de facto architecture map of Żabka's retail and back-office technology estate, and its outsourced-development supply chain, even before touching the source code itself.

Independent verification is partial. Ransomnews reviewed sample archives and confirmed the headline counts (541,463 Jira issues; 229,734 service-desk tickets) as exact matches to the seller's claims, lending strong credibility to the listing's scale. However, two more precise-sounding secondary claims — 35,206 GDPR-reference records and roughly 4,000 bank-account mentions within the dump — largely failed to surface in the reviewed samples, tempering confidence in the listing's completeness or accuracy beyond the core Jira/service-desk/GitLab figures. Żabka has not issued a public statement confirming or denying a breach as of this writing. Poland's RODO (the national GDPR implementation) requires a data controller to notify the national supervisory authority within 72 hours of becoming aware of a qualifying breach; absent public confirmation, it is unclear whether that regulatory clock has started. The threat actor's identity, initial access vector, and dwell time remain unknown; the forum account's brand-new, single-use, zero-history profile is consistent with a burner/sock-puppet account created specifically to monetize already-stolen data rather than an established data-broker persona. Ticket timestamps reportedly suggest the underlying data was assembled before the Couche-Tard tender offer became public, which argues against the listing being crafted purely in reaction to the acquisition news, even though the two-day proximity remains a notable coincidence.

Even unconfirmed, the exposure pattern described — a reusable high-privilege GitLab token, cloud API keys, and a database admin password all embedded in source code shared across dozens of repositories — represents a severe supply-chain and downstream-compromise risk: any buyer with a working token gains read (and potentially write) access to Żabka's proprietary retail, POS, and ERP-integration codebases, from which further credentials, business logic, or injectable code paths could be harvested for follow-on attacks against Żabka's franchise and POS infrastructure.

MITRE ATT&CK techniques by tactic:

Remediation for Żabka Polska Jira GitLab leak

Patches

Not applicable — this is an alleged credential/data-exposure incident, not a software vulnerability; no vendor patch exists

Immediate actions

Treat the reported 62-character GitLab access token as compromised and revoke/rotate it immediately across all 89 affected repositories, regardless of breach confirmation status
Rotate all Cloudflare API keys tied to Żabka's account and review Cloudflare audit logs for unauthorized DNS/WAF/CDN configuration changes since the token's creation date
Rotate the exposed MongoDB administrative password and any dependent service-account credentials; audit MongoDB access logs for anomalous admin-level connections
Rotate all messaging-broker credentials referenced in the leaked infrastructure code
Audit GitLab, Jira, and IT service-desk access/export logs for anomalous bulk-read or bulk-export activity consistent with the claimed record volumes
Notify and coordinate with named third-party IT vendors (Accenture, Netguru, BlueSoft) referenced in the leaked tickets, since their access/credentials may also be implicated

Workarounds

Enforce MFA and IP allow-listing on the Cloudflare account console and MongoDB administrative interfaces
Restrict and monitor Jira/GitLab bulk-export capabilities for anomalous large-scale data pulls
Assume all credentials appearing anywhere in the 89 GitLab repositories are compromised pending full rotation, not just the specifically named ones

Longer-term hardening

Deploy automated secret-scanning (e.g., GitLab native secret detection, gitleaks, trufflehog) in CI/CD pipelines and pre-commit hooks to block hardcoded credentials before merge
Replace long-lived, broadly-scoped personal access tokens with short-lived, narrowly-scoped, per-repository tokens or OIDC-based CI credentials
Migrate infrastructure secrets (Cloudflare keys, database passwords, broker credentials) out of source control and into a dedicated secrets manager/vault with audited access
Engage a DFIR firm to independently confirm or refute the breach's scope and validate whether any leaked credentials remain live
Review and tighten third-party/vendor access scoping (Accenture, Netguru, BlueSoft) under least-privilege principles for Jira, GitLab, and IT service-desk systems

Affected and fixed versions

Żabka Polska (internal) — Nowa Kasa point-of-sale platform
Vulnerable versions: not disclosed in source reporting
Żabka Polska (internal) — Cyberstore platform
Vulnerable versions: not disclosed in source reporting
Żabka Polska (internal) — zMarket platform
Vulnerable versions: not disclosed in source reporting
Atlassian — Jira (issue tracker instance used by Żabka Polska)
Vulnerable versions: not disclosed in source reporting
GitLab Inc. — GitLab (89 self-hosted or Group-hosted repositories)
Vulnerable versions: not disclosed in source reporting
MongoDB Inc. — MongoDB (administrative-level database instance)
Vulnerable versions: not disclosed in source reporting
Cloudflare Inc. — Cloudflare account API
Vulnerable versions: not disclosed in source reporting
SAP SE — SAP ERP (integration referenced in leaked tickets)
Vulnerable versions: not disclosed in source reporting

Timeline of Żabka Polska Jira GitLab leak

2026-07-31 locked-ioc-11 publicly announces a PLN 32.62 billion (~US$8.6B) agreement to acquire a controlling stake in locked-ioc-16 and launches a voluntary tender offer — the concurrent M&A context is cited as a possible factor in the breach listing's timing, though not confirmed as a motive.
2026-08-02 Analysis of the leaked tickets identifies more than 17 additional third-party vendors named alongside locked-ioc-20, locked-ioc-23, and locked-ioc-22, widening the scope of implicated supply-chain relationships.
2026-08-02 Reporting details that the 89 leaked locked-ioc-27 repositories include the internal 'cs-market' platform, comprising 44 DevOps repositories, 26 backend services, 7 frontend applications, and an API gateway.
2026-08-02 locked-ioc-17 confirms the seller's headline figures precisely as 541,463 Jira issues and 229,734 IT service-desk tickets, matching the reviewed sample archives exactly rather than merely approximating them.
2026-08-02 Secondary claims made by the seller — including references to GDPR-related content and bank-account data within the dump — largely fail to surface in the samples reviewed by locked-ioc-17, limiting confidence in the listing's completeness.
2026-08-02 Independent reviewer locked-ioc-17 examines sample archives from the listing and finds the seller's headline record counts (Jira and service-desk totals) internally consistent with the claims.
2026-08-02 The same account posts a single listing 14 minutes after registration, offering an alleged full locked-ioc-15 data dump (Jira, IT service-desk tickets, 89 locked-ioc-27 repositories, locked-ioc-18/locked-ioc-24/broker credentials) for €5,000.
2026-08-02 A previously unseen account is registered on an unnamed underground cybercrime forum, with no prior posting or trading history.
2026-08-03 Coverage notes that Poland's RODO (GDPR implementation) obligates a breached controller to notify the national supervisory authority within 72 hours of becoming aware of a qualifying breach — a compliance question left open by Żabka's lack of public acknowledgment.
2026-08-03 Security Affairs publishes a report summarizing the alleged breach, the seller's claims, and locked-ioc-17' partial corroboration.
2026-08-03 As of this report, locked-ioc-15 has issued no public statement confirming or denying the alleged breach.