NAIC and the PeopleSoft 0-day: when the regulator is breached

The breach of NAIC — the US National Association of Insurance Commissioners — is instructive for two reasons at once. First, it shows how a single 0-day in an ERP-class system turns into a campaign spanning more than a hundred organisations. Second, and this is the more interesting part, it is a case study in reading extortion groups’ statements — because the attackers first announced spectacular numbers and then corrected them themselves, explaining the original claim as… an AI-generated misinterpretation of the data.

For security teams that’s a rare chance to practise a skill nobody usually practises: separating facts from criminals’ marketing.

Point of entry: CVE-2026-35273 in Oracle PeopleSoft

On 11 June 2026 Oracle published an out-of-band advisory for CVE-2026-35273 in PeopleSoft. The mere fact of a fix outside the quarterly cycle is a signal — Oracle does that when waiting for the next Critical Patch Update would be too risky.

The vulnerability allows unauthenticated remote code execution. That’s the most dangerous combination there is: the attacker needs no account and no password, only network access to a vulnerable system.

To grasp the blast radius you need to know what PeopleSoft is. It’s a suite of business applications used mainly for:

HR and payroll (employee personal data, salaries, appraisals, bank details),
finance (invoices, payments, budgets, supplier data),
student administration at universities (Campus Solutions — admissions data, grades, payments),
procurement and supplier management.

In other words: it’s a system that by definition holds an organisation’s most sensitive data. Universities, government agencies and large enterprises keep a complete record of people and money in it. So a PeopleSoft 0-day isn’t “another CVE” — it’s direct access to the vault.

The campaign exploiting this flaw, attributed to the ShinyHunters group, reportedly affected more than 100 organisations, with universities heavily represented. It’s the same offender ecosystem we wrote about in help-desk vishing and SaaS extortion — except here the vector wasn’t social engineering but a technical software flaw.

Timeline of the NAIC incident

Let’s lay the facts out in order, because chronology matters for assessing credibility here.

Date (2026)	Event
11 June	Oracle publishes an out-of-cycle advisory for CVE-2026-35273
~11 June	NAIC detects unauthorised access to its systems
17–18 June	NAIC publishes public notices
18 June	ShinyHunters adds NAIC to its leak site
18 June	The group claims: over 105,000 files, 3.1 TB, including 2.1 million insurer regulatory filings
~24–25 June	Publication of the claimed 3.1 TB
later	The group corrects its own claim: not 2.1 million but 260,000 documents

Note the overlap of dates: NAIC detected the intrusion at roughly the moment Oracle shipped the fix. That’s typical of 0-days — defenders learn about the problem when the attack is already under way, and often has been for weeks.

The discrepancy that teaches the most

The most valuable part of this story is the collision between the attacker’s claims and the victim’s assessment.

The group’s version (original): 3.1 TB of data, over 105,000 files, including 2.1 million insurer regulatory filings — material implying access to the sensitive financial data of an entire sector.

The group’s version (after correction): the number of regulatory filings is 260,000, and the original statement was based on — quoting the group’s own justification — an AI-generated misinterpretation of the underlying data.

NAIC’s version: what was taken was publicly available data, outdated logs and configuration files. The organisation states that no personally identifiable information (PII) and no payment card or banking data were accessed.

That gap — from 2.1 million to 260,000 documents, alongside the victim’s assertion that this was effectively public material — is a lesson in itself. Let’s draw specific conclusions from it.

Why criminals inflate numbers

Extortion groups operate in a model where publicity is part of the pressure. The larger the claimed scale, the greater:

the pressure on the victim to negotiate,
the media interest that amplifies the message,
the group’s “reputation” with future victims and with partners in the ransomware-as-a-service model.

The volume quoted in terabytes is a particularly misleading measure. A virtual machine backup, a log directory or duplicated archives can occupy hundreds of gigabytes without containing a single sensitive record. Terabytes measure volume, not value.

The surprising thread: AI on the attacker’s side

The justification for the correction — “an AI-generated misinterpretation” — is a detail not to be missed. It implies the group used a model to analyse and catalogue the stolen data, then based a public statement on its conclusions, which nobody verified.

That closes a certain circle. On the defenders’ side we talk about models that help find vulnerabilities — provided a human verifies the result. Here we see the same technology on the other side and the same methodological error: trusting a model’s output without verification. Attackers make it as readily as anyone else — the difference being that their mistake cost credibility rather than security.

The practical consequence for defenders is direct: an extortion group’s statement may be not only deliberately inflated but simply wrong, because it came from an automated analysis nobody checked.

How to read extortion groups’ statements

This story hands you a ready set of rules. It’s worth having them written down before you need them.

1. A claim is a hypothesis, not a finding. The burden of proof lies with the claimant. Until verified against your own telemetry, treat every number as unconfirmed.

2. Verify through your own data, not by reading the leak site. The answer to “what left the organisation” is in your logs: outbound traffic volumes, file repository access, database queries, service account activity. That’s the only source with no motive to lie.

3. Distinguish “system access” from “data exfiltration” from “data sensitivity”. These are three separate questions. The attacker may have been in the system without taking data; may have taken worthless data; may have taken a small amount of highly sensitive data. The shortcut “they were inside, so we have a huge breach” can be as wrong as its denial.

4. Don’t build your communications on someone else’s numbers. If you base a customer statement on criminals’ claims and those turn out inflated, you damage yourself. If you dismiss them and they turn out true, you lose credibility. Say only what you’ve confirmed, and state when you’ll say more. That’s the standard in our guide to the first hours after a breach.

5. Remember numbers move in both directions. In the Conduent breach the victim count grew for months, from about 10 million to over 62 million. Here the claim was reduced. Both directions are normal — first statements are almost never final.

A regulator as a target — why that’s a special case

NAIC coordinates insurance supervision across the US. Even if — per its own assessment — what was taken was mostly public material, the fact of a regulator being breached matters beyond one institution.

Supervisory and industry bodies aggregate data from many entities. That makes them high-leverage targets: one breach potentially touches an entire sector without needing to attack each firm separately. The same logic drives attacks on service providers, clearing houses and processing centres — we described it in third-party risk management.

There’s an additional dimension: seemingly harmless data. Outdated logs and configuration files — precisely what NAIC says was taken — aren’t headline material, but they’re valuable to an attacker: they reveal hostnames, software versions, account naming schemes, integration paths and internal addresses. That’s material for preparing the next attack, this time precisely targeted. So “it was only logs” shouldn’t end the analysis; it should trigger a review of what those logs reveal.

What to do if you run PeopleSoft

Establish exposure. Check which PeopleSoft instances are reachable from the internet. ERP and HR systems very often have no reason to be publicly accessible — yet they are, because “it was easier during rollout” or to support remote work years ago. An employee self-service or recruitment portal is a typical reason for exposure, but it should be separated from the full application.

Verify patches, including out-of-cycle ones. Oracle ships quarterly Critical Patch Updates, but for CVE-2026-35273 it published an out-of-band advisory. If your patching process is synchronised solely with quarters, you will miss exactly the fixes that are most urgent. Monitor vendor advisories independently of the calendar — part of a mature vulnerability management process.

Look for traces retrospectively. With a 0-day used in a campaign, the question isn’t “are we vulnerable” but “were we already among those hundred organisations”. Review application server logs for unusual requests, look for new files in application directories (web shells), check for unexpected child processes of the application server and unusual database queries — especially bulk reads of HR tables.

Rotate secrets if you were in the exposure window. Integration accounts, API keys, database credentials. A patch closes the entrance but doesn’t invalidate what the attacker already took.

Limit the system’s reach. An ERP shouldn’t be able to initiate arbitrary outbound connections or talk to the entire internal network. Segmentation and egress control are the cheapest way to turn “they took the ERP” into “they took the ERP and got stuck”.

Strengthen data monitoring, not just system monitoring. An alert on bulk reads of HR data or the export of a large number of records is more effective than any single indicator of compromise. That’s a practical application of the threat intelligence lifecycle and of detection aimed at impact rather than tooling.

Where exactly to look for traces

With a 0-day in an ERP web application the set of places to check is fairly repeatable. Work through them methodically rather than relying on a single indicator.

Application and web server logs. Look for requests to unusual paths, bursts of 500 errors followed by a sudden “quietening” of traffic (a typical trace of an exploit being tuned), and POST requests of atypical size to endpoints that normally accept short forms.

New files in application directories. The classic result of successful RCE in a web application is a web shell — a file placed in a directory served by the web server. Compare the directory tree against a deployment baseline or a backup; you’re interested in files whose modification dates fall outside deployment windows.

Child processes of the application server. An application server spawning a shell, a scripting interpreter or network utilities is behaviour that doesn’t occur in normal operation. It’s one of the most effective and simplest detection rules for this class of attack.

Database queries. The most valuable signal for an ERP: bulk reads of HR, payroll or supplier tables performed by the application account outside batch-processing hours. If you log queries, look for SELECTs covering unusually wide record ranges.

Accounts and privileges. New administrative accounts, role changes, added integration keys. With ERPs, service accounts matter especially — they get skipped in reviews because they “belong to the system”.

Outbound traffic. Exfiltrating HR data from an ERP usually means a transfer of noticeable volume. Compare the outbound traffic profile of the application server against the pre-incident period; you’re looking for new destinations and atypical volumes in a short window.

Frequently asked questions (FAQ)

If NAIC says public data leaked, was this even a serious incident? Yes. Unauthorised access to an organisation’s systems is serious regardless of how the stolen data is classified. An assessment of “public data, outdated logs and configuration” limits third-party impact, but doesn’t change the fact that an attacker was inside — and configuration and logs make subsequent attacks easier.

Whom should we believe: the group or the victim? Neither at face value. The group has an incentive to exaggerate (negotiating pressure), the victim to minimise (reputation, legal liability). What’s credible is evidence-backed findings: forensic analysis, telemetry, regulatory filings. In this case the group corrected its own numbers, which says a lot about their original evidentiary value.

We don’t use PeopleSoft. Does this apply to us? The vector — no. The pattern — yes. A 0-day in an ERP/HR-class system can affect any vendor. The universal questions are: is our ERP internet-facing, how quickly do we apply out-of-cycle fixes, would we detect a bulk export of HR data, and can we reconstruct what happened a month ago.

What should we do first, concretely? Three things: check ERP exposure to the internet, confirm the version and full patch set (including out-of-band fixes), and review logs retrospectively for the exposure period. If any of these lacks a clear answer, you have your priority for the week.

How do we prepare for our name appearing on a leak site? In advance: decide who assesses the credibility of claims, who approves the statement, what data you need to confirm or deny, and within what timeframe. That’s a scenario to rehearse as part of your incident response plan — during a real incident there’s no time to work out roles.

Summary

The NAIC case combines two lessons that rarely appear together. The technical one is familiar: a 0-day in an ERP-class system gives an attacker immediate access to an organisation’s most sensitive data, and fixes released outside the quarterly cycle are easy to miss if your patching process is tied to the vendor’s calendar.

The second lesson is rarer and more valuable: extortion groups’ statements are material for verification, not a source of facts. Here the attackers themselves reduced their numbers from 2.1 million to 260,000 documents, attributing the original claim to an unverified AI analysis. An organisation that had built its communications on the first version would have found itself in an awkward position.

If you want to check whether your ERP systems are visible from the internet, how quickly you close windows after out-of-cycle fixes, and whether you’d detect a bulk export of HR data — let’s verify it with a controlled test.

Sources and further reading: SecurityWeek, BleepingComputer, Oracle Security Alerts, CISA KEV.