You can reset a password in thirty seconds. You cannot reset a home address, a Social Security number, or a psychiatric evaluation. That is the real lesson of the September 2026 ShinyHunters breach at the FBI. It is why zero-day data protection must start with the data itself, not the door in front of it.
Every organization runs software with flaws nobody has found yet. Patches run late. Workarounds get bypassed. The question for every CISO is not whether an attacker eventually gets in; it is what they find when they do.
What Happened at the FBI
On September 22, 2026, ShinyHunters claimed it had breached the FBI through FBIJobs.gov, the bureau’s job application portal. The group self-reported that it entered through a vulnerability in Oracle PeopleSoft, the bureau’s human resources system behind the portal, which holds records on current employees as well as applicants. From there, it says it reached several FBI HR services, including one identified as Medlink, and moved into FBI data stored in Amazon Web Services GovCloud. It further claims it took between two and three terabytes of HR data from the FBI.
Days later, the FBI reportedly told its own employees that their names, home addresses, job titles, and Social Security numbers were exposed. Several media outlets report the stolen files also include medical records, including drug test results and psychiatric reports. A sample the group sent to Nextgov/FCW covered nearly 5,000 employees, with details on their spouses and siblings.
The group says this is not about money. It wants the FBI to retract a May 2026 public service announcement describing its tactics, and it set a deadline of September 30. For a security agency, this is the worst kind of data to lose. It maps the people who do the work, where they live, and what might be used against them.
The Patch Existed. The Firewall Workaround Did Not Hold.
By the time this campaign reached the FBI, the flaw was no longer a zero-day. That is what makes it instructive. The zero-day window did not close when the patch shipped.
ShinyHunters first exploited the PeopleSoft flaw (CVE-2026-35273) as a zero-day against universities between May 27 and June 9, 2026. Oracle released a patch on June 10. Where teams could not patch right away, guidance suggested blocking the vulnerable endpoint at the perimeter instead.
Many teams chose the firewall rule. It was faster. It looked like protection.
Then the attackers changed one character. According to Mandiant’s September 25 analysis, they URL-encoded the letter P in the request path. The firewall rule no longer matched; the PeopleSoft server decoded the request and processed it normally. Mandiant has since found web shells on dozens of systems across higher education, healthcare, technology, transportation, and government.
Whether the FBI had patched, relied on a firewall rule, or done neither has not been reported. For every organization that chose the workaround, the zero-day window quietly reopened.
This is perimeter thinking in miniature. A control that inspects the front door can be fooled at the front door. We made the broader case in Perimeter Security Is Not Enough; the FBI breach is that argument playing out in production.
Why Zero-Day Data Protection Has to Live at the Data Layer
Look at what happened after entry. The attackers did not stop at a web server. They reportedly reached data in a government cloud environment built for the most sensitive federal workloads.
Mandiant’s report explains how that kind of pivot works. Once inside PeopleSoft, the application’s service account can read configuration files, database connection strings, and application data. Mandiant tells victims to rotate every credential readable from that tier, including cloud credentials. In plain terms, the server held the keys to the rest of the house, and it held them in readable form.
That is the pattern behind most major breaches. Step one is entry. Step two is reading plaintext configuration and logs to find the next hop. Step three is reaching the data, which is readable because the system decrypted it to use it. Step four is walking out with data that still works.
Encryption at rest does nothing to interrupt that chain, because running systems work on decrypted data. We covered that gap in Encryption at Rest Is Not Enough. Zero-day data protection means assuming the exploit succeeds and making sure the data it reaches is unusable. That is the missing layer we described in The Zero Trust Data Layer: What Most CISOs Are Missing.
The Data You Can’t Rotate
Incident response has a playbook for credentials. Revoke. Rotate. Reissue. It works because credentials are disposable. Personal data is not.
An FBI agent cannot change the address where their children sleep every time a database leaks. An employee cannot rotate a psychiatric evaluation. Once that data leaves in readable form, the damage has no expiration date. It becomes raw material for profiling, phishing, and foreign intelligence approaches for as long as those people live and work.
This is not ShinyHunters’ first run at data that cannot be reset. Earlier this year the group took roughly nine million Medtronic records, a breach we examined in Medtronic and the Healthcare Encryption In Use Gap. Its entry methods change from campaign to campaign: stolen credentials, helpdesk social engineering, borrowed software tokens, and now an unpatched server.
The outcome never changes, because the data was readable every time they arrived. We explored the credentialed version of this problem in Insider Threat Encryption: When the Attacker Already Has a Badge. The door varies. The plaintext data behind it does not.
What Seshat Is, and Why It Prevents the Damage
So, the problem is not the door. It is what sits behind the door in plain text.
Seshat is a continuous encryption platform built by Donoma Software. It creates an encrypted operating environment in which sensitive data stays encrypted at rest, in transit, and while it is being queried and processed. Applications keep working. The data never has to be decrypted to be useful.
Seshat does not claim to stop the exploit. No one honestly can. What it changes is everything that comes after: an attacker who compromises the application tier finds encrypted records, encrypted configuration, and encrypted logs. There is nothing readable to pivot on, and nothing usable to take.
A skeptical CISO will ask the obvious question. If the attacker owns the application, why can’t they just ask it for the data?
Because under Seshat, the application tier never holds the data in readable form. Queries run against encrypted data and results come back encrypted. Decryption happens only at defined, controlled boundaries; not inside the server the attacker now controls. A web shell inherits the service account’s access, and that access returns ciphertext.
To be precise about the limit: an attacker who steals an authorized person’s own login can see what that person is allowed to see. What they cannot do is walk out with the whole system in readable form.
Now replay the FBI breach, as reported, with Seshat protecting those data stores. The PeopleSoft server still gets hit. The web shell still lands. The files still leave. But all that leaves is ciphertext. Names, addresses, Social Security numbers, and medical records that are unintelligible to the people holding them. The breach happens. The damage does not.
Seshat was built to integrate into enterprise systems and perform without major overhauls of infrastructure or applications:
- Near-native speed. With latency at milliseconds of overhead, users and workloads proceed as usual.
- Application-layer deployment. No replacing the application, the cloud environment, or the database.
- Standard CPUs. No specialized hardware to procure.
- Post-quantum ready. Aligned with the federal migration mandate we covered in Post-Quantum Encryption: What the Mandate Gets Right.
What CISOs Should Do Now
The immediate steps are specific, and none of them can wait for the FBI’s investigation to finish.
- Patch CVE-2026-35273. Mandiant is explicit that firewall rules and path blocking are not a substitute for the patch.
- Assume compromise if you relied on the rule. Hunt for web shells and rotate every credential the PeopleSoft tier could read.
- Map your un-rotatable data. Find where personnel, applicant, and medical records live across the entire data estate.
- Ask one question of every store. If an attacker exfiltrated this tonight, would it be readable?
If the answer is yes, your zero-day data protection strategy is a patch schedule. That is not a strategy. It is a race, and eventually you lose one.
Your September 22 Is Coming
Every organization running PeopleSoft, or any other system of record, will face its own version of September 22. Patches run late. Workarounds get bypassed. The one variable you control is whether your data is worth stealing when it happens.
Book a Seshat solution briefing today to see how continuous encryption makes stolen data worthless
Frequently Asked Questions
What is zero-day data protection?
Zero-day data protection is a security approach that assumes attackers will exploit vulnerabilities before a patch exists or is applied and protects the data itself, so it is unusable when stolen. Seshat delivers it by keeping data continuously encrypted at rest, in transit, and in use, so an exploited system exposes only ciphertext.
How did ShinyHunters breach the FBI?
ShinyHunters claims it exploited a vulnerability in Oracle PeopleSoft, the FBI’s human resources system behind the FBIJobs.gov portal, then moved into FBI data stored in AWS GovCloud. Reporting by 404 Media, TechCrunch, and Nextgov/FCW supports parts of that account. Mandiant reports the broader campaign bypassed firewall rules by URL-encoding a single character. The FBI has not yet publicly confirmed the full intrusion path.
Why didn’t a firewall rule stop the PeopleSoft exploit?
The rule matched the literal path of the vulnerable endpoint. Attackers encoded one character, so the rule no longer matched, while the PeopleSoft server decoded the request and processed it normally. Mandiant advises that firewall rules are not a substitute for patching.
Would encryption at rest have protected the stolen FBI data?
No. Running applications decrypt data to use it, so an attacker operating inside the application tier reads plaintext. Seshat keeps data encrypted while it is being used, so the same access returns only ciphertext.
Can Seshat stop a zero-day exploit?
No, and no honest vendor should claim to. Seshat prevents the damage. The exploit may succeed, but the data, configuration, and logs the attacker reaches stay encrypted, so there is nothing usable to pivot on or steal. Seshat deploys at the application layer, runs at near-native speed on standard CPUs, and is post-quantum ready.
