ShinyHunters claimed last week to have exfiltrated 297 GB of data from the Council of Europe by exploiting a zero-day vulnerability in Oracle PeopleSoft.
On June 14, the extortion group posted online that it had breached three Council of Europe entities: the Secretariat, the European Directorate for the Quality of Medicines, and the Parliamentary Assembly. The group says the dataset contains 429,000 files spanning records from 2011 to 2026. According to BleepingComputer's reporting, the files include more than 409,000 payslips, 3,700 personnel files, and 14,000 CVs, plus records containing names, dates of birth, home addresses, phone numbers, employee IDs, salaries, bank account details, and medical records for over 10,000 current and former employees, contractors, and job applicants.
ShinyHunters set a deadline of June 16 for the Council to make contact before releasing the data publicly. SecurityWeek reported that the Council said it was "investigating the matter and assessing the situation." No ransom figure was disclosed.
The group claims the entry point was CVE-2026-35273, a zero-day in Oracle PeopleSoft, the HR and workforce platform the Secretariat runs. PeopleSoft self-service portals are routinely internet-facing so staff can reach payroll and personal records from outside the office. That exposure is standard. What matters is what the authentication layer looked like from an external probe. Two things stand out in the technical reporting.
What scanners would have missed
Standard scanners address three attack surfaces:
- Custom application code (SAST)
- Open source dependencies (SCA)
- Web endpoint behaviors (DAST)
PeopleSoft's session initialisation logic does not fit any of them.
SAST tools run against code your team writes. PeopleSoft's authentication layer is vendor code; you do not have the source. SCA tools flag the libraries you imported; PeopleSoft is not a package in your dependency tree. DAST tools probe HTTP endpoints for known-bad inputs. A DAST tool aimed at a PeopleSoft login page will confirm that TLS is present and the form submits over HTTPS. It will not understand the state machine inside the session handshake, which is where CVE-2026-35273 reportedly lives.
Before the CVE was assigned, no scanner had a signature for it. After publication, the CVSS base score joins a triage queue. A team carrying a hundred open scanner alerts, many on code paths that external attackers cannot reach, will weigh a PeopleSoft advisory against the backlog and schedule a patch window. The score is identical whether the vulnerable endpoint is internal-only or internet-facing with payroll and medical records for ten thousand people behind it. Reachability does not appear in the base score.
That is the gap. The score does not know what is reachable. The scanners do not cover the platform at all.
What Sekura would have shown
Sekura's Phase 3 (dynamic probing) would have produced a finding on this attack surface without a CVE signature in the database.
Phase 2 (recon) would fingerprint the externally reachable PeopleSoft portal first. The portal's HTTP response headers, URL path structure, and session token format identify it as PeopleSoft to a trained probe. We flag it as a high-interest target: internet-facing, authentication-gated, HR data store behind it.
Phase 3 then tests the authentication boundary directly. It does not reference a CVE list. It issues sequences of crafted requests against the session initialisation flow, varying token structure, request ordering, and parameter encoding, then records how the application responds to each variant. An authentication bypass of the type described in CVE-2026-35273 produces a characteristic signal: session tokens issued before credential verification completes, or diverging response codes depending on which step in the handshake is dropped.
The finding names the endpoint, includes the crafted request sequence, and attaches the data returned. It does not say "patch CVE-2026-35273." It says: Sekura retrieved a payroll record using an unauthenticated session token. Here is the HTTP exchange.
That is a proof, not a probability.
The bigger pattern
Enterprise HR platforms are internet-facing by design. Self-service payroll access requires it. Organisations accept that exposure and then rely entirely on the vendor's authentication to hold the line. When the vendor has an unpatched zero-day, there is no secondary control to fall back on.
ShinyHunters targets this category because data density is high. Payslips, bank account details, medical records, and CVs sit together in one structured system. A single authentication bypass produces everything needed for identity fraud at scale across thousands of individuals.
I think 2026 is the year when HR platform security gets the same continuous scrutiny that network perimeters started getting a decade ago. Vendor patch cadences and annual scan passes are not enough for systems this exposed and this dense. The attacks are pointing at the assumption.
If you want to see what proof-first dynamic probing looks like against your own internet-facing applications, see how we compare to scanners.