Known Exploited Means Your Mitigation Is Next

Last month, the FBI arrested a suspect in its ongoing response to an attack on its job portal, allegedly carried out by criminal hacker and extortion group ShinyHunters. The agency said a contractor failed to apply a security patch to a third-party platform involved in the breach of its job portal, while Reuters reported that the contractor worked for Accenture and that the platform was Oracle PeopleSoft.  

(Fair warning: The Reuters article is behind a paywall.) 

ShinyHunters has claimed it exploited a PeopleSoft vulnerability to get in, which checks out. In late September, Mandiant documented what ShinyHunters was doing to other unpatched PeopleSoft systems. Some organizations had put WAF rules in front of the vulnerable PSEMHUB endpoint. The attackers got past rules that looked for /PSEMHUB/ by requesting /%50SEMHUB/ instead. The WAF missed the literal string it was looking for. WebLogic decoded the character and served the vulnerable endpoint anyway. 

Stop Treating Compensating Controls as True Mitigation 

We do not know whether the FBI had a similar rule in place, or whether this bypass played any part in its breach, and I’m not going to pretend otherwise. What we do know is that the FBI says a patch was missed, and that Mandiant watched attackers get around a control other organizations had deployed without applying that patch. Both matter because compensating-control data is starting to flow into vulnerability management systems, where it will help decide what can wait. 

I want that data in the system. If an asset really is isolated, that changes its priority. If a control blocks an exploit path, the team should know about it. The mistake is turning a compensating control into a flat statement that the vulnerability is mitigated, with no record of what the control does or how recently anyone checked it. 

That word, ‘mitigated,’ affects what happens next. A finding marked mitigated can drop out of the urgent queue, miss an escalation, or show up as resolved in a report to management. Nobody has to formally decide that a WAF is as good as a patch. The ticket just stops getting the same attention, and the deadline slips. 

The PeopleSoft bypass shows why the details matter. Blocking a request to a particular URL is not the same as removing the vulnerable application or making it unreachable from the internet. The rule may have worked exactly as configured against the request it was designed to recognize. Change the request slightly, alter it just a little bit, and the behavior changes into something else entirely. 

A Practical Lesson in Known Exploited and KEV Listing 

Mandiant’s June guidance for this CVE recommended blocking external access to /PSEMHUB/* as a fallback when organizations could not immediately patch or disable the service. In September, Mandiant reported that ShinyHunters had changed its exploit to bypass string-based WAF rules and was targeting organizations that had deployed those rules without patching.  

The published mitigation gave attackers a specific defense to test. In this campaign, they found a way around it. That is what ‘known exploited’ means in practice. The attacker who got the CVE onto the list is the same one who is going to run into your control, and they have already shown they will read the mitigation and work around it. 

A KEV listing tells you that exploitation has been observed. It does not tell you whether a particular organization’s control has been tested. When attackers are actively adapting an exploit to get past a published mitigation, the presence of that mitigation should demand closer scrutiny, not less. You need more evidence that the rule works in your environment, and you need to keep working toward a fix that does not depend on the attacker sending the request you expected. 

We have seen this before. When Microsoft disclosed the ProxyNotShell Exchange vulnerabilities in 2022, it provided an IIS rewrite rule to block the Autodiscover request pattern attackers were using while organizations waited for a patch. In December, CrowdStrike found Play ransomware reaching the same vulnerable PowerShell backend through Outlook Web Access instead. The attackers used a different entry vulnerability, CVE-2022-41080, in a chain that still exploited CVE-2022-41082. The Autodiscover rule did not cover that route. The November patch did. 

Imagine the Exchange record in a vulnerability tool during that period: CVE-2022-41082 present, known exploitation, Microsoft mitigation deployed. None of those fields would be false. The conclusion, “This CVE is covered,” would still be wrong. The control covered a known route to the vulnerability, and the record did not preserve that distinction. 

Implementation adds another layer of uncertainty. A rule can be mapped correctly and still be configured differently across nodes, pick up an exception later, or stop seeing traffic after an infrastructure change. Those changes may never reopen the vulnerability ticket. Unless somebody checks the control again, the finding can keep its mitigation label long after the evidence behind it has gone stale. 

Compensating Controls Have Their Place 

Compensating controls remain useful, and not every KEV finding gets the same deadline. Deferring work on an actively exploited vulnerability requires stronger evidence than a vendor mapping or a rule that passed a test months ago. I would want to know which exploit path the control blocks, whether it was tested in our environment, who owns it, when it was last validated, and what would reopen the patching decision. 

For a known-exploited vulnerability on an internet-facing system with a patch available, I would not let a path-based WAF rule close the finding. The rule can reduce risk while the patch is tested and deployed. If patching cannot happen on time, that should be an explicit exception with an owner and a new date, not a quiet status change from open to mitigated. If the system was exposed during active exploitation, applying the patch should also come with a check for compromise. 

This applies to Nucleus, too. Our documentation shows how our platform allows a finding to be marked Mitigated when a compensating control is in place, and that status closes an existing ticket. It is also permanent. Fixed is the only status in Nucleus that flips back to Active when a rescan finds the vulnerability still there.  

Mitigated stays Mitigated until a person changes it, which is the drift problem described above, in our own product. That flexibility has legitimate uses, but it makes the decision to use the status consequential. We already have a better path for this case, an exception request with evidence that a security reviewer turns into an accepted risk with a date. I want an internet-facing KEV protected only by a path-based WAF rule to remain owned and due for remediation, and I want our guidance to say so plainly. 

The broader PeopleSoft campaign gives every vulnerability program, including ours, a standard to check against. When a platform says a known-exploited CVE is mitigated, it should show what the control covers and when that claim was last verified. Someone should still own the work of fixing the underlying vulnerability. 

Attackers aren’t treating your mitigation as the end of the story. Neither should you.