Nobody Put the Reporting Tool on the Register
[Navigation Links: not applicable, standalone article, no series book project intermediary]
On 10 September 2026, Thankyou Payroll, a New Zealand payroll provider used by a number of charities, told its customers that names, IRD numbers, physical and email addresses, bank account details and payment histories had been accessed through a piece of software running inside its own environment. The company's own statement was careful about what it did and did not claim: "We understand that Thankyou Payroll is one of a number of businesses impacted" by what it called a global incident touching companies right across the world. That was not an exaggeration written to soften the news. The software was Metabase, an open-source business intelligence platform, and by the time Thankyou Payroll spoke, at least five other organisations on three continents had already disclosed the identical breach, through the identical flaw, in the identical piece of software, entirely independently of one another.
This is not a bigger version of the Mathspace story this series covered a fortnight ago. That case was a known-asset failure: Mathspace had Metabase, received the vendor's advisory, and its own admission was that nobody routed it to a person with authority to act. This case sits one step further back. A reporting tool that a technical team installs to solve a Friday-afternoon problem does not usually pass through a vendor-onboarding process, so it never enters the artefact, a vendor register, a third-party risk list, an IT asset inventory, that would have caused an advisory to reach anyone at all. You cannot fail to escalate a warning about software your own governance process does not know you are running.
Same flaw, six companies, no coordination
The flaw is CVE-2026-72898, an unauthenticated SQL injection reachable through Metabase's own password-reset endpoint, scored a maximum 10.0 on the CVSS scale. Metabase disclosed it on 6 August 2026 with an admission most vendors never have to make: it found the flaw only after its own cloud platform had already been attacked with it, as a zero day, before any patch existed. Over the following six weeks, organisations kept finding the same flaw in their own environments, each on its own timeline, none coordinating with the others. Framework, a laptop manufacturer in the United States, and Tally, a forms platform in Belgium, disclosed within days of the advisory; so did Kilo Code, an AI coding platform owned by Anaconda, whose exposed Slack access tokens were invalidated immediately. Scalingo, a cloud hosting provider in France, found the intrusion four days after Metabase's own disclosure and notified France's data protection regulator inside twenty-four hours; roughly 90,000 people had names, account identifiers and technical metadata exposed, though Scalingo's own account is explicit that passwords, banking details and source code were not among them. Then came Mathspace in Australia, already covered here, and finally Thankyou Payroll. The flaw affected every Metabase release from version 1.58 through to 1.63, and the company shipped a fix across all six branches within days of its own disclosure. That detail is worth holding onto, because it means every organisation still exposed by the time an outside scan went looking had a patch available and had simply not applied it, or had applied it without knowing the instance existed at all.
None of this reflects badly on Metabase itself. The company published a same-day advisory once it found in-the-wild exploitation, which is what responsible disclosure looks like, and every account gathered for this article shows the affected organisations disclosing promptly and taking systems offline once they understood what had happened. The pattern here is not one vendor's negligence. It is a property of how a certain kind of software gets deployed everywhere at once, and an internet-wide scan makes the scale of that property visible in a way no single breach notice can. Dataminr's threat research team scanned the public internet for exposed Metabase installations and found roughly 11,000 probable self-hosted instances, more than 4,300 of them still on vulnerable versions, over 97 per cent of the affected branch unpatched. The scanning team's own qualification matters as much as the number: shared cloud hosting means several organisations often sit behind the same block of internet addresses, so "real exposure among major organizations is almost certainly undercounted." A security researcher, working from the outside with nothing more than a public internet connection, can currently enumerate this exposure faster than most of the organisations running it can find it in their own environment.
A gap the book's own framework did not anticipate, extended
In the Cyber Guide, I describe a pattern I called Shadow OOP: informal data-sharing arrangements that grow up around a formal Once-Only process because the formal channel is too slow, leaving "designated registries with defined governance" on one side and something altogether less accountable on the other. The book's own description of how that gap opens reads, almost word for word, as a description of how a self-hosted reporting tool arrives inside an organisation: a team facing a slow approval process reaches for a pragmatic workaround, the workaround improves things immediately, and nobody documents the dependency. I want to be precise about what I am doing with that framework here, because the book wrote it about government data-sharing arrangements, not commercial analytics software. I am extending it, not claiming Thankyou Payroll or Mathspace ran anything resembling a government Once-Only arrangement. But the four consequences the book names for an undocumented dependency, no visibility to a security assessment, no oversight mechanism because the arrangement exists precisely to avoid one, an unresolved question of who is accountable when it fails, and an impossible forensic reconstruction afterwards, map onto this case without needing to be forced. Dataminr's own admission that shared infrastructure defeats even an outside attacker's attempt at attribution is that fourth consequence, stated from the opposite direction.
Elsewhere in the book I set out the Architectural Debt Register and the Fiduciary Risk Exposure formula. That register is meant to hold five things for every system a board is tracking: what the system is, what capability it lacks, a calculated Fiduciary Risk Exposure figure, its remediation status, and a named owner. I wrote plainly what keeping it is actually for: "It prevents the 'we didn't know' defence, providing the 'we exercised appropriate oversight' evidence." Every worked example I gave for that register assumed a first step that this case shows cannot be assumed at all: that the system exists on somebody's list before a board can ask what its risk exposure is. A register that only tracks what an organisation remembers procuring is not a smaller version of a complete register. It is answering a different, narrower question than the one a board actually needs answered, and every case in this article is one where that narrower question was the only one anyone thought to ask.
What New Zealand's own cyber agency has already written down
New Zealand's National Cyber Security Centre received Thankyou Payroll's notification alongside the Office of the Privacy Commissioner, which is the regulator the company's own statement names. No NCSC New Zealand notification is stated either way in the sources available for this article, which is not evidence that one did or did not happen, only that it is not confirmed. What is confirmed, and predates this incident by months, is that NCSC New Zealand has already written down the exact governance principle this case is about. Its Minimum Cyber Security Standards state that an organisation below a basic maturity level "does not have a clear understanding of which assets they have," while a working maturity level requires that "all assets have an owner" that complies with organisational policy, specifically so that shadow IT can be managed. A separate NCSC New Zealand report dedicated to unsanctioned technology defines shadow IT plainly, as equipment and software people use for work "without an organisation's IT or security staff knowing about them," and it recommends tool catalogues and ongoing monitoring rather than promising that shadow IT can simply be eliminated. That same report is explicit that eliminating shadow IT altogether is not a realistic goal, and recommends organisations instead close the specific capability gaps, an approval process too slow, a tool too hard to request through proper channels, that push staff toward an unsanctioned option in the first place. That is a more useful frame for a board than a ban, because Thankyou Payroll's own reporting tool almost certainly existed to solve a real, unmet need, not to evade one. Neither document depends on this breach to be true. Both were written before it happened, and both describe exactly what went missing at Thankyou Payroll's own reporting layer.
One naming note is worth carrying forward past this article. The CERT NZ brand, as a separate identity, has not existed since 23 July 2025, when its integration into the National Cyber Security Centre completed and its website and phone line were formally retired. Any reference to "CERT NZ" describing anything from that date onward should now read "NCSC New Zealand."
A parallel worth naming, without overstating it, arrived the same week as this article's own research. The Reserve Bank's own Future of Banking study, published 17 September 2026, sets out three scenarios for how New Zealand banking could look by 2035 and names a risk that sits at the far end of the same spectrum from Thankyou Payroll's problem: growing reliance on technology providers and third-party services may create "new dependencies and concentrations of risk," and in its more platform-driven scenario, "many providers fell outside the Reserve Bank's current prudential perimeter" altogether. Where this article's cases are tools nobody ever registered as a vendor relationship at all, the Reserve Bank's concern is vendor relationships regulators can already see becoming too concentrated to fail safely. Both are the same underlying question, whether anyone can actually see where the operational dependency sits, approached from opposite ends of visibility. One is not evidence for the other; they are two readings of the same blind spot.
What a board should actually ask
None of this requires a board to understand SQL injection. It requires a board to ask a narrower, more answerable question: does our organisation have a single list of every piece of software touching our data, regardless of who bought it, and does every entry on that list have a named owner? A vendor register that only asks "who did we buy this from" will never catch a tool a technical team installed to solve its own problem, because nobody's process ever asked whether that installation should be on the register in the first place.
A short list of questions, deliberately short enough to raise in a single board meeting: ask what proportion of the software actually running in the organisation's environment appears on the formal vendor or asset register today, and treat a low answer as the finding, not a technicality. Ask who owns the discovery process, the actual technical work of finding what is running, separate from who owns the register itself. Ask whether that discovery happens continuously or only after an incident forces it, since an internet scanner already checks continuously and an organisation's own visibility should not lag behind an outsider's. And ask, specifically, whether the answer changes for software the organisation runs itself rather than software it accesses through a vendor's cloud service, because this entire incident class lives in exactly that gap.
None of these four questions requires new technology to answer honestly, though tools exist that make the ongoing answer cheaper to maintain than a point-in-time audit ever is. A network scan, a cloud-configuration review, or a software composition tool can each surface what is actually running in an environment. The harder part, and the part no tool can do on a board's behalf, is deciding who owns the result once it is found and what happens to an entry the moment somebody stops using it.
None of the six organisations named in this article set out to build an ungoverned environment. A technical team solving a real problem on a Friday afternoon is not making a reckless decision; it is making the only decision available to it inside a process too slow to help. That is precisely why the fix has to be structural rather than a lecture about discipline. It needs a register that is built to be found by, not just filled in by, and a discovery process that runs whether or not anyone remembers to ask it to.
The open-source dimension of this case sits downstream of the advisory, in what an organisation can do once it accepts that self-installed tools are the norm, not the exception. OWASP's Dependency-Track, an open-source software composition analysis platform used by tens of thousands of organisations, exists for exactly this problem: it ingests a software bill of materials and continuously checks every component it finds, self-hosted analytics platforms included, against the same public vulnerability feeds that carried Metabase's own advisory. It does not care who procured the software or who installed it on a Friday afternoon; it only reports on what is actually running. That is the same distinction Dataminr's own scan drew from outside the organisation entirely, applied instead from within it. The tooling to close this gap already exists, and it costs nothing to run.
The same distinction sits underneath a harder requirement on the other side of the Pacific. The United States Department of Defense's Cybersecurity Maturity Model Certification programme requires contractors handling controlled unclassified information to produce a System Security Plan naming every in-scope asset before a third-party assessor will certify them at all; an asset a contractor cannot name is treated as a compliance failure, not an oversight to note. New Zealand and allied companies bidding into the US, UK or Australian defence industrial base increasingly meet an equivalent expectation as a condition of the contract, regardless of whichever domestic patching standard also applies to them. The programme does not reach a payroll provider or an education platform. What it demonstrates, plainly, is that at least one government has already decided an unlisted asset is not a governance gap to manage; it is a certification an organisation simply does not receive.
Every organisation reading this has at least one piece of software running today that nobody bought, nobody approved and nobody entered on any register, quietly waiting to generate its own advisory that nobody will be positioned to escalate. Could you name it, right now, without asking your IT team first?
If your board wants an independent AI and cyber risk briefing, or a review of what your vendor's assurance actually verified, message me and I will send the scope and the fixed fee.
The views expressed in this article are entirely my own, informed by morethan 30 years of professional experience in architecture, security, andtechnology leadership in New Zealand. I write as director of Te PonoLimited; the views are personal and do not represent the position of anyclient, any government agency, or the New Zealand government. My commentaryon legislation and policy is analytical, drawing on publicly availablesources and my professional expertise in architecture, security, and AIgovernance, and it is politically neutral.
Andreas Hamberger is a New Zealand leader in Architecture and Security and Associate Member of the Institute of Directors. The Hamberger Report: Cyber Guide for New Zealand Boards is the third book in The Hamberger Report series, providing board members and senior leaders with practical cyber resilience governance guidance. Through Te Pono he provides independent AI and cyber risk briefings and vendor assurance reviews to boards; contact andreas@thehambergerreport.com for the scope and fixed fee.
This article was produced with AI assistance under my direction. Research,drafting and images pass through a pipeline I built and govern: automatedgates for source verification, forbidden language and political neutrality,and my own review before anything is published. The tools include Claude,Gemini and Openart. The frameworks, arguments and editorial judgements aremine and are the same discipline I apply to the AI systems I audit forclients. AI accelerated the work; the thinking, and the responsibility forit, are mine.
[1] RNZ. "Kiwi Payroll Firm Caught Up in Global Data Breach." 2026. https://www.rnz.co.nz/news/business/1327439/kiwi-payroll-firm-caught-up-in-global-data-breach
[2] NZ Herald. "New Zealand Payroll Firm Apologises After Being Caught Up in Data Breach." 2026. https://www.nzherald.co.nz/business/new-zealand-payroll-firm-apologises-after-being-caught-up-in-data-breach/CGL7VRXHCNBCZKVDKE4JE67BI4/
[3] The Hacker News. "Metabase Zero-Day Exploited in Wild." August 2026. https://thehackernews.com/2026/08/metabase-zero-day-exploited-in-wild.html
[4] Scalingo. "Security Bulletin SSB-2026-004." 2026. https://doc.scalingo.com/security/bulletins/ssb-2026-004
[5] Help Net Security. "Metabase Zero-Day: Framework, Tally, Kilo Code." 10 August 2026. https://www.helpnetsecurity.com/2026/08/10/metabase-zero-day-framework-tally-kilo-code/
[6] Dataminr. "CVE-2026-72898 Exposes Thousands of Self-Hosted Instances." 8 August 2026. https://www.dataminr.com/resources/intel-brief/cve-2026-72898-exposes-thousands-of-self-hosted-instances/
[7] National Cyber Security Centre (New Zealand). "Assets and Their Importance." 30 October 2025. https://www.ncsc.govt.nz/protect-your-organisation/assets-and-their-importance/
[8] National Cyber Security Centre (New Zealand). "Chasing Shadows: Managing Unsanctioned IT." Quarter Four Cyber Security Insights 2025. https://www.ncsc.govt.nz/insights-and-research/insights-reports/quarter-four-cyber-security-insights-2025/managing-unsanctioned-it/
[9] National Cyber Security Centre (New Zealand). "NCSC and CERT NZ Integration Now Complete." 23 July 2025. https://www.ncsc.govt.nz/news/ncsc-and-cert-nz-integration-now-complete/
[10] Reseller News. "CERT NZ Now Fully Merged Into NCSC, Changing Cyber Incident Reporting Lines." 2025. https://www.reseller.co.nz/article/4027567/cert-nz-now-fully-merged-into-ncsc-changing-cyber-incident-reporting-lines.html
[11] interest.co.nz. "RBNZ Assistant Governor Angus McGregor Says Banking Environment in NZ Changing Quickly." 17 September 2026. https://www.interest.co.nz/banking/140299/rbnz-assistant-governor-angus-mcgregor-says-banking-environment-nz-changing-quickly
[12] OWASP Dependency-Track. "Software Bill of Materials (SBOM) Analysis." 2026. https://dependencytrack.org/
[13] United States Department of Defense, Office of the Chief Information Officer. "Cybersecurity Maturity Model Certification (CMMC) Program." 2026. https://dodcio.defense.gov/CMMC/