Why a Known Vulnerability With a Ready Fix Still Got Into the FBI

#How a known bug survived until September

The timeline, as reported by Krebs on Security, The Hacker News and Mandiant:

• June. ShinyHunters start exploiting CVE-2026-35273 in PeopleSoft as a zero-day. Google warns about the campaign, Oracle issues a security alert and ships a fix. Mandiant publishes web application firewall rules for organizations that can’t apply the update right away.
• September. ShinyHunters get around the Mandiant rule with a URL-encoding trick and go back to mass exploitation. On September 25, Mandiant and Google Threat Intelligence Group report compromised systems across higher education, technology, healthcare, agriculture, transportation and government.
• September. The group claims the breach of apply.fbijobs.gov.
• October 6. The FBI names the missed patch as the cause and removes the contractor.

Roughly three months passed between Oracle’s alert and the breach of one of the most security-conscious organizations in the US.

#The temporary fix that became permanent

The WAF rule deserves its own section, because it shows how these gaps form. A compensating control is meant to buy time until the real fix lands. In practice, it sometimes just closes the ticket. The rule is deployed, the dashboard turns green, the urgency drops, and the vulnerable version keeps running behind it.

That works until someone finds a way around the rule. ShinyHunters needed a URL-encoding trick. After that, the only thing between the attackers and the data was a patch that had been available for months.

A mitigation without its own deadline turns into the permanent state of the system. If the WAF rule had carried an expiry date and an owner responsible for the actual update, that “temporary” would never have become final.

#The missing piece was an owner

In an opinion column for Dark Reading published the same week, vulnerability management practitioner Nishant Sharma argues that most organizations drowning in vulnerabilities have an ownership problem, and that buying better scanning only gives them better visibility into a growing backlog. He describes four states where a finding gets stuck:

• No owner. The asset isn’t mapped to anyone, so there’s nobody to escalate to.
• Owner without authority. One team is accountable, but another one controls the change: a vendor, a platform team, a contractor.
• Owner without capacity. The fix competes with feature work in the same backlog.
• Owner without consequence. Missing the remediation deadline costs nobody anything.

We don’t know what happened inside the contractor’s team, and the FBI hasn’t said. But a platform run by a third party on behalf of a government agency is where ownership tends to blur. The agency owns the risk, the contractor owns the change, and the deadline sits between them.

Sharma also shares results from a program he worked on. Once findings started routing automatically to named owning teams and SLA breaches were reported to engineering leadership, mean time to remediate dropped from 45 days to 10 and SLA compliance went from 30% to 95% within six months.

#Metrics that show the gap before an attacker does

The number of open findings says very little about whether anyone fixes them. It grows when scanning coverage improves and shrinks when someone closes easy tickets. Three metrics tell you more:

• Mean time to remediate per owning team. It turns a security number into a management one.
• SLA compliance. The share of findings closed within the agreed deadline, by severity.
• Share of assets with a verified owner. If this one is low, the other two can’t be trusted.

#How Whitespots handles it

Whitespots is self-hosted. The platform runs as a single Docker container inside your own perimeter, its only outbound connection is license activation, and air-gapped deployments are supported. There’s no vendor-run portal on the internet holding your vulnerability data, so the system that maps your weak spots is hard to reach from outside.

Inside, Whitespots treats a vulnerability as a task with a lifecycle. Each finding goes through the same chain:

1. Rule-based validation.
2. Prioritization with custom CVSS rules and business criticality.
3. Assignment to an owning team.
4. An SLA timer based on severity. The defaults are 3 days for critical, 14 for high and 30 for medium, and every team can tune them.
5. A Jira ticket with two-way sync, comments in the merge request and IDE integrations.
6. A rescan that confirms the fix before the finding closes, with an audit log of every step.

Host scanning covers infrastructure along with code and dependencies. The Weighted Risk Trend gives leadership one number tracked against a risk threshold they set themselves, so a missed deadline shows up in the report long before it leads to an incident.

#The question to ask this week

If a vendor shipped a critical patch this morning for a platform a contractor runs for you, who on your side owns the deadline, and how long would it take for anyone to notice it was missed?

Sources: The Hacker News, Krebs on Security, eSecurity Planet, Dark Reading