---
schema: 1
kind: vulnerability
title: >
  Metabase CVE-2026-72898: an unauthenticated SQL-injection zero-day gave attackers administrator
  access to BI instances — exploited since at least 3 August, fifteen downstream victims confirmed
headline: >
  Metabase Cloud was breached through its own 0-day; self-hosted instances stay vulnerable until
  manually upgraded
summary: >
  Metabase disclosed on 2026-08-06 that its Metabase Cloud platform was attacked through a
  previously unknown vulnerability in versions 1.58 and above: an unauthenticated attacker injects
  arbitrary SQL against the application database and obtains administrator access to the instance,
  from which they can rewrite configuration, steal the stored credentials for every connected
  database and export the data those connections reach. The only interim workaround the vendor
  offers is to block the /api/session/reset_password endpoint, which is also where its published
  attack pattern runs. Cloud instances were patched by the vendor; self-hosted deployments stay
  vulnerable until manually upgraded to 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 or 0.63.5.
  Laptop maker Framework and form builder Tally were the first to confirm customer data was taken,
  on 2026-08-03. The flaw went a week without a CVE identifier before it was assigned
  CVE-2026-72898 and added to CISA's KEV catalog on 2026-08-11. VenariX now tracks fifteen publicly
  confirmed downstream incidents and ties two of them, at Statista and Dodo Payments, to the Dire
  Wolf extortion group working against self-hosted instances.
discovered_at: "2026-08-09T04:44:00Z"
updated_at: "2026-09-29T22:50:37Z"
event_date: 2026-08-03
run_id: 2026-08-09T0412Z-intel
priority: high
immediate_action: null
tags:
  - vulnerabilities
  - actively-exploited
  - zero-day
  - sqli
  - pre-auth
  - auth-bypass
  - data-breach
  - ransomware
  - patch-available
  - cisa-kev
  - supply-chain
regions:
  - global
  - europe
sectors:
  - technology
  - public-sector
  - finance
  - retail
entities:
  - "incident:metabase-sqli-zeroday-2026-08"
  - "actor:dire-wolf"
techniques:
  - T1190
  - T1213
  - T1552
  - T1078
  - T1552.001
affected_products:
  - Metabase
  - Metabase Cloud
cves:
  - id: CVE-2026-72898
    cvss: "10.0"
    epss: null
    type: sqli
    vector: zero-click
    auth: pre-auth
    status:
      - exploited
      - cisa-kev
      - patch-available
    affected: Metabase Cloud and self-hosted releases in the 58 through 63 branches
    fixed: >
      latest patched release for each affected self-hosted branch; Metabase Cloud patched by the
      vendor
sources:
  - url: "https://www.metabase.com/blog/security-update"
    publisher: Metabase
    date: 2026-08-06
    role: primary
  - url: "https://www.bleepingcomputer.com/news/security/framework-tally-disclose-metabase-data-theft-attacks/"
    publisher: BleepingComputer
    date: 2026-08-07
    role: corroborating
  - url: "https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf"
    publisher: Metabase (GitHub Security Advisory)
    date: 2026-08-06
    role: primary
  - url: "https://www.cisa.gov/news-events/alerts/2026/08/11/cisa-adds-three-known-exploited-vulnerabilities-catalog"
    publisher: CISA
    date: 2026-08-11
    role: corroborating
  - url: "https://venarix.com/blog/metabase-security-incident-downstream-impact-across-customer-environments"
    publisher: VenariX
    date: 2026-08-17
    role: primary
  - url: "https://databreaches.net/2026/08/17/israels-largest-crypto-broker-bits-of-gold-hit-by-data-breach-affecting-200000-customers/"
    publisher: DataBreaches.net
    date: 2026-08-17
    role: corroborating
  - url: "https://dodopayments.com/blogs/security-incident-internal-analytics-system"
    publisher: Dodo Payments
    date: 2026-08-17
    role: primary
  - url: "https://www.medianama.com/2026/09/223-dark-web-dodo-data-breach/"
    publisher: MediaNama
    date: 2026-09-01
    role: corroborating
  - url: "https://www.cyberattaque.org/carrefour-des-donnees-clients-exposees-apres-la-cyberattaque-de-son-prestataire/"
    publisher: "Cyberattaque.org"
    date: "2026-09-26"
    role: primary
  - url: "https://frenchbreaches.com/alertes/carrefour-shipup-muixw7rd535cstgrh65"
    publisher: "French Breaches"
    date: "2026-09-27"
    role: corroborating
closed_sources: []
evidence:
  - quote: "We recently identified that Metabase Cloud was attacked by someone utilizing an unknown (“0-day”) security vulnerability in versions 1.58 and above."
    publisher: Metabase
  - quote: "After gaining access to your instance, the attacker could inject arbitrary SQL against the Metabase application database, which can give them administrator access to the instance."
    publisher: Metabase
  - quote: "If you find that pattern in your application logs or in your Metabase server ingress logs, it is likely that your instance has been compromised."
    publisher: Metabase
  - quote: "This is a CRITICAL vulnerability that allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, which can give them administrator access to the instance,"
    publisher: BleepingComputer
  - quote: Metabase has confirmed active exploitation of this vulnerability.
    publisher: Metabase (GitHub Security Advisory)
  - quote: "This is a CRITICAL vulnerability that allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, which can give them administrator access to the instance."
    publisher: Metabase (GitHub Security Advisory)
  - quote: "The Metabase vulnerability has already been tied to fifteen publicly confirmed incidents"
    publisher: VenariX
  - quote: "VenariX has confirmed that Dire Wolf, a ransomware and data extortion threat actor, exploited CVE-2026-72898 in at least two incidents involving self-hosted Metabase deployments"
    publisher: VenariX
  - quote: "There is currently no evidence that the threat actor discovered the zero-day or is behind the other confirmed Metabase-related incidents."
    publisher: VenariX
  - quote: "The affected system is a self-hosted deployment of Metabase, a third-party open-source tool that we use for internal reporting only."
    publisher: Dodo Payments
  - quote: "Credential rotation is especially important if exploitation is suspected, because patching the application does not invalidate credentials that may already have been exposed."
    publisher: VenariX
  - quote: Metabase states that this pattern in application or ingress logs indicates that the instance was likely compromised.
    publisher: VenariX
verification: multi-source
sourcing_note: >
  First coverage on 2026-08-09, two to three days after the vendor advisory (2026-08-06) and the
  first victim disclosures (2026-08-07), while the story was still producing new confirmed
  victims. The CVE identifier, the CVSS 10.0 rating and the per-branch affected ranges come from
  the GitHub security advisory itself. The Dire Wolf attribution is VenariX's own assessment: Dodo
  Payments confirms the Metabase vector and the CVE but does not name an actor, and VenariX states
  it has no evidence the group found the flaw or is behind the other incidents.
confidence: high
references: []
deep_dive: false
deep_dive_category: null
org_triage: null
classification:
  reliability: A
  credibility: 1
watchlist_hit: false
actions:
  - "Upgrade every self-hosted Metabase to at least 0.58.24 / 0.59.21 / 0.60.17 / 0.61.11 / 0.62.9 / 0.63.5, then, for any instance that was reachable and unpatched during the exploitation window, revoke all active sessions by clearing the core_session table, delete unrecognised API keys, and rotate the credentials for every connected database and warehouse, not just the Metabase admin credentials, because the upgrade does not invalidate what was already retrieved."
  - "Search Metabase application or reverse-proxy ingress logs across the entire pre-upgrade exposure window for a POST to /api/session/reset_password returning HTTP 400 immediately followed by a GET to /api/user/current returning HTTP 200 from the same source; Metabase states that sequence indicates the instance was likely compromised."
updates:
  - at: "2026-08-12T04:46:30Z"
    run_id: 2026-08-12T0411Z-intel
    type: update
    summary: >
      Metabase's unauthenticated SQL-injection zero-day, covered here on 2026-08-09 when no CVE
      existed, has been assigned CVE-2026-72898 in GitHub Security Advisory GHSA-vwf4-m7j8-wcjf at
      CVSS 3.1 10.0, and CISA added it to the Known Exploited Vulnerabilities catalog on 2026-08-11.
      The advisory publishes affected ranges per release line and confirms active exploitation in
      Metabase's own words. For self-hosted instances nothing about the exposure changed — but the
      flaw is now visible to every scanner, SBOM pipeline and CVE-keyed patch process that could not
      see it a week ago.
    fields:
      - actions
      - cves
      - evidence
      - regions
      - sectors
      - sources
      - tags
      - techniques
      - body
    merged_from: 2026-08-12/cve-2026-72898-metabase-sqli-cve-assigned-kev
  - at: "2026-08-19T05:02:00Z"
    run_id: 2026-08-19T0410Z-intel
    type: update
    summary: >
      A tracker maintained by VenariX, updated 2026-08-17, now counts nine publicly confirmed
      organisations whose compromised Metabase environments were used to reach connected data
      warehouses — n8n, Framework, Tally and Kilo Code, joined on 2026-08-17 by Stocksy United Co-op,
      ShipMonk, Checkly, Cypress.io and Bits of Gold. This pipeline covered CVE-2026-72898 on
      2026-08-09 and 2026-08-12 as an exploited CVSS 10.0 unauthenticated SQL injection in the
      password-reset endpoint; the delta is the downstream pattern. Because Metabase stores the
      credentials for every database it connects to, administrative access to the application yields
      those credentials, and Metabase's own guidance is that patching does not invalidate credentials
      already exposed. Metabase also published a two-request log pattern that indicates a given
      instance was compromised.
    fields:
      - actions
      - cves
      - evidence
      - sectors
      - sources
      - tags
      - techniques
      - body
    merged_from: 2026-08-19/metabase-downstream-victims-nine-credential-rotation
  - at: "2026-09-27T04:38:00Z"
    run_id: 2026-09-27T0404Z-intel
    type: update
    summary: >
      The downstream victim list grows again through a further intermediary: Shipup, a French
      package-tracking platform used by 700+ e-commerce brands, was compromised through the same
      vulnerability, and at least six of its retail clients, including Carrefour, Printemps,
      Citadium, Aroma-Zone, Micromania and Easypara, have since notified their own customers of
      exposed contact data.
    fields: [sources, evidence, sourcing_note, actions, body]
  - at: "2026-09-27T13:28:04Z"
    run_id: 2026-09-27T1308Z-audit
    type: correction
    summary: >
      The Shipup section claimed the 31 July to 17 August access window was the same one this entry's
      earlier coverage had already established for the campaign. It was not: the earlier coverage says
      "since at least 3 August", three days later, so the Shipup window widens the campaign's known
      exposure period rather than confirming it. The sentence now states that difference instead of
      asserting agreement. Recorded for the audit trail and not otherwise fixable: the changelog record
      of the same day declared a change to the evidence list that its commit did not make.
    fields: [body]
  - at: "2026-09-29T22:50:37Z"
    run_id: 2026-09-29T2134Z-audit
    type: update
    summary: >
      VenariX's tracker now counts fifteen publicly confirmed downstream incidents, up from nine,
      adding Privy, Paradigm Connect Asia, Statista, Dodo Payments, Marsello and LEGO Certified Stores
      South Africa. It attributes two of them, at Statista and Dodo Payments, to the Dire Wolf
      ransomware and extortion group exploiting self-hosted Metabase, and suspects fourteen more
      targets. Dodo Payments' own disclosure confirms a self-hosted Metabase instance breached through
      CVE-2026-72898. The title, the summary and the main analysis no longer describe the flaw as
      having no CVE or Framework and Tally as its only victims.
    fields: [title, summary, tags, entities, sources, evidence, sourcing_note, body]
migrated_from: null
---

Metabase, an open-source business-intelligence platform run both self-hosted and as a managed cloud service, disclosed on 2026-08-06 that its own Metabase Cloud environment had been attacked by someone using an unknown vulnerability affecting versions 1.58 and above, and that it blocked the endpoints used in the attack before identifying and patching the flaw ([Metabase, 2026-08-06](https://www.metabase.com/blog/security-update)). The mechanism matters more than the platform: an unauthenticated caller injects arbitrary SQL against the Metabase application database, and that yields administrator access to the instance — from which the attacker can change the application configuration, steal the stored credentials Metabase holds for the databases it connects to, read anything reachable through those connections, and export it ([Metabase, 2026-08-06](https://www.metabase.com/blog/security-update)). Neither the vendor nor the reporting locates the injection point precisely, but the vendor's stated interim workaround for anyone who cannot upgrade immediately is to block the `/api/session/reset_password` endpoint outright, and its published attack pattern runs through that same route ([Metabase, 2026-08-06](https://www.metabase.com/blog/security-update)). BleepingComputer, quoting the associated security advisory, reports it is rated critical at CVSS 10.0 with active exploitation confirmed, and that no CVE identifier had been assigned ([BleepingComputer, 2026-08-07](https://www.bleepingcomputer.com/news/security/framework-tally-disclose-metabase-data-theft-attacks/)). The advisory later assigned CVE-2026-72898, and CISA added it to its Known Exploited Vulnerabilities catalog on 2026-08-11 ([CISA, 2026-08-11](https://www.cisa.gov/news-events/alerts/2026/08/11/cisa-adds-three-known-exploited-vulnerabilities-catalog)).

The exposure split is the part defenders need to act on. Metabase Cloud customers were upgraded and patched by the vendor, while self-hosted instances remain vulnerable until an administrator upgrades them by hand ([Metabase, 2026-08-06](https://www.metabase.com/blog/security-update)). The minimum safe point releases are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5 for their respective branches, and anything on a lower point release of those branches is still vulnerable; installations below version 58 are not affected ([Metabase, 2026-08-06](https://www.metabase.com/blog/security-update)).

Two organisations have confirmed data theft from their own instances. Framework, the laptop manufacturer, told customers that the attackers stole full names, email addresses, login IP addresses, billing and shipping address details, phone numbers and company names, with VAT, EIN and billing email address additionally in scope for its business customers, and said Metabase notified it on 6 August that its instance had been vulnerable and was accessed on 3 August ([BleepingComputer, 2026-08-07](https://www.bleepingcomputer.com/news/security/framework-tally-disclose-metabase-data-theft-attacks/)). Tally, an online form builder, notified users that its Metabase analytics environment was compromised on the same date and that the attackers reached email addresses and password hashes, while its forms and the responses submitted to them are stored separately and were not reached ([BleepingComputer, 2026-08-07](https://www.bleepingcomputer.com/news/security/framework-tally-disclose-metabase-data-theft-attacks/)). Those two were the first confirmed victims. The count has since grown to fifteen, set out in the updates below.

Detection is unusually well specified for a flaw that went its first week without a CVE, because the vendor published the request sequence rather than indicators. The attack shows up as a call to `POST /api/session/reset_password` returning a 400 status code followed by a call to `GET /api/user/current` returning 200, and Metabase states that finding that pattern in application logs or in Metabase server ingress logs means the instance was likely compromised ([Metabase, 2026-08-06](https://www.metabase.com/blog/security-update)). After upgrading, the vendor's own follow-up steps for any instance whose reset endpoint was publicly reachable are to revoke every active session by deleting all rows in the `core_session` table, review and delete unrecognised API keys, check administrator accounts for unexpected changes, rotate the credentials for every connected database, and review both data-warehouse logs and Metabase's own activity and query history for unauthorised access ([Metabase, 2026-08-06](https://www.metabase.com/blog/security-update)).

**Defender takeaway:** the reason this deserves attention beyond the patch is what a BI platform holds. Metabase sits in front of production data warehouses with standing credentials for each one, so administrator access converts directly into read access across every system it was ever pointed at — the stolen material in both confirmed cases came out of the connected data, not out of Metabase itself. Any self-hosted instance that was internet-reachable on an affected point release before the upgrade needs the credential rotation and the log review, not just the version bump. The week without a CVE is a process lesson worth naming internally: while exploitation was already under way, an asset patched on the strength of CVE feeds, KEV listings or scanner findings got no signal for this at all.

**Triage:** a 400 on the password-reset route is ordinary — users mistype addresses and reset flows reject malformed requests all day, and on its own the 400 means nothing. The discriminator is what follows it from the same source: an unauthenticated client that is genuinely failing a password reset has no session and cannot then get a 200 from `/api/user/current`, so it is the ordering and the success of the second call that separate exploitation from noise ([Metabase, 2026-08-06](https://www.metabase.com/blog/security-update)).

## Update — 2026-08-12T04:46:30Z

The entry on Metabase's unauthenticated SQL-injection zero-day closed on the observation that no CVE identifier had been assigned, so a purely CVE-driven patch process would not surface the exposure at all. That gap is now closed in both directions. GitHub Security Advisory GHSA-vwf4-m7j8-wcjf assigns CVE-2026-72898 with a CVSS 3.1 base score of 10.0 (`AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`), and Metabase's own advisory text states that "Metabase has confirmed active exploitation of this vulnerability" and that the flaw "allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, which can give them administrator access to the instance" ([Metabase, 2026-08-06](https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf)). CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2026-08-11 with a 14 August due date ([CISA, 2026-08-11](https://www.cisa.gov/news-events/alerts/2026/08/11/cisa-adds-three-known-exploited-vulnerabilities-catalog)).

The second half of the delta is the affected-version matrix, which the vendor's original blog post did not carry in this form. The advisory lists the affected ranges per release line as `>= x.58.0 < x.58.23`, `>= x.59.0 < x.59.20`, `>= x.60.0 < x.60.16`, `>= x.61.0 < x.61.10`, `>= x.62.0 < x.62.8` and `>= x.63.0 < x.63.3`, and names the patched versions separately as x.58.24, x.59.21, x.60.17, x.61.11, x.62.9 and x.63.5 — note the two lists do not meet, so a build sitting between an affected upper bound and its patched release is not described either way and should be treated as needing the named patched version ([Metabase, 2026-08-06](https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf)). That turns "upgrade Metabase" into a query an asset inventory can answer, and it is what a scanner needed in order to report anything at all.

Nothing here changes the exposure of an instance that has not been upgraded — the exploitation window has been open since at least 3 August per the earlier coverage, and the interim control is unchanged: block the `/api/session/reset_password` endpoint if an upgrade cannot happen immediately. What changed is visibility, and that is the operationally useful part. An organisation whose vulnerability management runs off CVE identifiers, SBOM matching or KEV feeds got no signal on this flaw for over a week while it was being exploited; the same tooling will now produce a finding on the next scan cycle. The advisory's post-upgrade guidance also stands and is worth re-reading against what an attacker with administrator access would already have taken: revoke active sessions, audit API keys and administrator accounts, and rotate the stored credentials for every connected data source, because those credentials are what an instance-level compromise reaches.

## Update — 2026-08-19T05:02:00Z

The count of downstream victims is now the story. A tracker maintained by VenariX, first published 2026-08-10 and updated 2026-08-17, states that "This brings the number of publicly confirmed downstream organizations tracked by VenariX to nine" ([VenariX, 2026-08-17](https://venarix.com/blog/metabase-security-incident-downstream-impact-across-customer-environments)) — n8n, Framework, Tally and Kilo Code from the first wave, with Stocksy United Co-op, ShipMonk, Checkly, Cypress.io and Bits of Gold added on 2026-08-17. The earlier entries covered the flaw itself: an unauthenticated SQL injection reachable at the password-reset endpoint, CVSS 10.0, exploited, catalogued as such on 2026-08-11.

The mechanism behind the growing list is a property of business-intelligence tooling rather than of this bug. Metabase stores the connection configuration, including credentials, for every external database and warehouse it queries; an attacker who reaches administrative context in the application can therefore read those stored credentials and query or export whatever they reach ([VenariX, 2026-08-17](https://venarix.com/blog/metabase-security-incident-downstream-impact-across-customer-environments)). The blast radius of any given instance is set entirely by what it was wired to — VenariX's own framing is that a deployment connected only to a restricted reporting database is a materially different incident from one connected to a production warehouse, which is the assessment question a defender should be answering first.

The victim disclosures show the range. n8n's investigation found the attacker queried 136 records containing names and email addresses, five of which also carried bcrypt password hashes tied to n8n Cloud accounts, and reported that the queries returned a variable set of rows, which prevented it from determining exactly which individual records were returned. Framework confirmed customer data was stolen including names, email addresses, phone numbers, login IP addresses and billing and shipping addresses, with payment information not included. Tally's exposure covered email addresses and password hashes while form content was stored separately and unaffected, and Kilo Code's included names, email addresses, billing addresses, location data and, for a subset of users, partial or full prompts ([VenariX, 2026-08-17](https://venarix.com/blog/metabase-security-incident-downstream-impact-across-customer-environments)). Of the newly added names, Bits of Gold separately disclosed on 2026-08-17 that an attacker gained unauthorized access to a third-party data analytics network and obtained names, national ID numbers and emails for roughly 200,000 customers ([DataBreaches.net, 2026-08-17](https://databreaches.net/2026/08/17/israels-largest-crypto-broker-bits-of-gold-hit-by-data-breach-affecting-200000-customers/)) — the company describes the platform class, not the product, and it is VenariX that places the incident in this campaign.

The operational point is the one most likely to be got wrong in a remediation ticket. Metabase's own guidance, as VenariX relays it, is that "Credential rotation is especially important if exploitation is suspected, because patching the application does not invalidate credentials that may already have been exposed" ([VenariX, 2026-08-17](https://venarix.com/blog/metabase-security-incident-downstream-impact-across-customer-environments)). An estate that upgraded Metabase and closed the ticket has fixed the injection and left the attacker holding working warehouse credentials. Metabase's fuller recommendation set for potentially exposed instances is to revoke active sessions, review administrator accounts and API keys, rotate credentials for connected databases, and review both Metabase and warehouse logs; where an immediate upgrade is impossible it recommends temporarily blocking access to the reset-password endpoint.

Detection has an unusually crisp anchor for a SQL-injection flaw, because the vendor published one. Metabase identified a recurring two-request pattern associated with exploitation — a POST to `/api/session/reset_password` returning HTTP 400, immediately followed by a GET to `/api/user/current` returning HTTP 200 — and "Metabase states that this pattern in application or ingress logs indicates that the instance was likely compromised" ([VenariX, 2026-08-17](https://venarix.com/blog/metabase-security-incident-downstream-impact-across-customer-environments)). Beyond that, the investigative surface is Metabase's own query history, database and warehouse audit logs, administrator accounts, API keys, and any unexpected use of the stored connection credentials — the last being where a compromise that started in the BI tier becomes visible in the warehouse tier.

**Triage:** a failed password reset followed by a session check is not by itself unusual in a web application's logs, which is exactly why the ordered pair matters rather than either request alone — a genuine failed reset does not produce an authenticated `/api/user/current` success on the same session immediately afterwards. Downstream, the discriminator for warehouse activity is whether queries arriving under the Metabase service credential match the dashboards and questions that credential is actually used for: bulk selects against tables no saved question references, or access at hours the reporting schedule does not run, are the signal, while high query volume under that identity is normal by design.

## Update — 2026-09-27T04:38:00Z

The downstream count grows again, and through a further intermediary this entry had not yet named. Shipup, a French platform used by more than 700 e-commerce brands to send delivery-tracking notifications and post-purchase communications, ran a Metabase instance that was compromised through the same CVE-2026-72898 unauthenticated SQL injection, with unauthorized access to the Shipup instance confirmed between 31 July and 17 August 2026, a window that starts earlier than the "since at least 3 August" this entry's own earlier coverage had established for the campaign ([Cyberattaque.org, 2026-09-26](https://www.cyberattaque.org/carrefour-des-donnees-clients-exposees-apres-la-cyberattaque-de-son-prestataire/)). At least six of Shipup's retail clients have since notified their own customers of exposure: Carrefour notified some customers in early September, and Cyberattaque.org had already separately documented Printemps, Citadium, Aroma-Zone, Micromania and Easypara as affected through the same Shipup compromise ([Cyberattaque.org, 2026-09-26](https://www.cyberattaque.org/carrefour-des-donnees-clients-exposees-apres-la-cyberattaque-de-son-prestataire/); [French Breaches, 2026-09-27](https://frenchbreaches.com/alertes/carrefour-shipup-muixw7rd535cstgrh65)). The exposed categories match the pattern this campaign has shown throughout: names, email addresses and phone numbers; Carrefour states no banking data or passwords were affected, and neither its own site, customer accounts nor internal systems were compromised, consistent with the exposure being limited to data it had shared with Shipup for delivery notifications. Carrefour has not disclosed the exact number of customers affected or confirmed whether the exposure window matches Shipup's own 31 July-17 August dates.

Shipup is a new entry in this campaign's chain of intermediary vendors, distinct from the data warehouses and analytics platforms this entry's earlier coverage described (n8n, Kilo Code and the others connected directly to a compromised Metabase instance): here, the retail brands are themselves downstream of a vendor that was downstream of the Metabase flaw, a second hop the credential-rotation and log-review guidance in this entry's original analysis already covers, since it applies to any instance that was reachable and unpatched during the exploitation window regardless of how many contractual layers separate the ultimate data subject from the compromised application.

## Correction — 2026-09-27T13:28:04Z

The Shipup paragraph above stated that the 31 July to 17 August 2026 access window matched the exposure window this entry had already established for the campaign. It does not. This entry's earlier coverage places exploitation "since at least 3 August", so the Shipup window opens three days earlier and widens the campaign's known exposure period rather than corroborating it. For a defender scoping a log review against a Metabase instance or a downstream vendor relationship, the earlier start date is the operative one, and the sentence now says so.

## Update — 2026-09-29T22:50:37Z

VenariX's tracker has grown from nine confirmed downstream incidents to fifteen. The additions since the 2026-08-17 count are Privy, Paradigm Connect Asia, Statista, Dodo Payments, Marsello and LEGO Certified Stores South Africa ([VenariX, 2026-08-10, revised since](https://venarix.com/blog/metabase-security-incident-downstream-impact-across-customer-environments)). The Shipup compromise and its retail clients, covered in the update of 2026-09-27, are not on that list, so the real total is higher still.

The larger change is who is using the flaw. VenariX says it has confirmed that Dire Wolf, a ransomware and data-extortion group, exploited CVE-2026-72898 in at least two incidents against self-hosted Metabase deployments, at Statista and Dodo Payments, and suspects the group targeted fourteen more companies the same way. It is explicit that it has no evidence Dire Wolf discovered the zero-day or is behind the other confirmed incidents ([VenariX, 2026-08-10, revised since](https://venarix.com/blog/metabase-security-incident-downstream-impact-across-customer-environments)). Dodo Payments, a payments company, confirms the vector without naming an actor: an unauthorised party exploited CVE-2026-72898 in a self-hosted Metabase instance used for internal reporting, viewed and queried the reporting datasets that system could reach, and the company contained it within hours of learning of it on 16 August ([Dodo Payments, 2026-08-17](https://dodopayments.com/blogs/security-incident-internal-analytics-system)). A dark-web listing dated 16 August, reviewed but not verified by MediaNama, claims about 60.8 GB and 39.3 million rows from four ClickHouse analytics databases, including tables it labels API keys, one-time passcodes and identity-provider credentials, where Dodo says API keys and credentials were not in the affected system ([MediaNama, 2026-09-01](https://www.medianama.com/2026/09/223-dark-web-dodo-data-breach/)).

For a defender this moves the self-hosted exposure from opportunistic data theft to an extortion operator's target list. The dispute over what left Dodo's warehouses is the point this entry has made since August: the reach of a compromised Metabase instance is whatever its stored connections reach, and the vendor's statement of what the BI tool itself held does not bound it. An instance that was internet-reachable on a vulnerable build between late July and its upgrade should be scoped as a warehouse compromise, not an application one.
