A firewall rule is not a patch because it tries to recognize an attack from the outside, while a patch removes the flaw itself, and the ShinyHunters breach of the FBI’s jobs portal showed exactly where that difference bites. Oracle patched a critical PeopleSoft flaw on June 10, 2026 and told customers who could not install it right away to block the vulnerable component with a perimeter rule instead. By September, the attackers had found that changing a single character in their web request let it slip past the rule while the PeopleSoft server still processed it normally. Organizations that installed the patch were protected; those relying on the rule alone were not. For any business, the lesson is to treat a workaround as a temporary bridge with an end date, and to track every one until the real fix is in place.
Why Workarounds Quietly Become Permanent
Workarounds quietly become permanent because they solve the urgent problem, the alert goes quiet, and the patch drops off the list of things anyone is chasing. Applying a patch to a system like PeopleSoft, an ERP or a line-of-business application often needs testing, a maintenance window and a vendor or contractor, while a firewall rule can go in during a lunch break.
Our team sees this constantly in client environments. A vendor issues an urgent advisory with a fix and a mitigation. The mitigation goes in the same day. The fix is scheduled for “the next maintenance window”, which slips once, then again, and by the time anyone looks the rule has been in place for months and nobody remembers it was meant to be temporary, one of the patterns in 7 IT infrastructure mistakes SMBs make.
Here are the five principles behind the steps in this article:
- A mitigation is a bridge, not a destination. Every workaround needs a written end date when the real fix goes in.
- Attackers test the rule, not the flaw. Once a workaround is public, attackers study how to get around it.
- Track mitigations like debts. Keep a list of every open workaround, its owner and its deadline.
- Contractors must report patch status. If someone else maintains the system, their contract should require proof.
- Verify by testing, not by trust. Confirm the patch is installed on the actual server, not just approved.
This guide is written for owners, IT managers and operations leads at organizations of 50 to 500 people that run business applications such as ERP, HR, finance or customer portals, whether maintained in house or by an outside provider.
What Happened in the PeopleSoft Case
Security researchers reported in June 2026 that ShinyHunters had exploited a critical Oracle PeopleSoft flaw. Oracle shipped a patch on June 10 and suggested blocking access to the vulnerable component at the perimeter where patching had to wait. In September the group claimed to have taken names, home addresses and phone numbers tied to the FBI’s jobs portal, and researchers traced the route to a request altered just enough to evade the blocking rule.
The defenders did nothing unusual. They followed the vendor’s own interim advice. That is what makes the case useful: the failure was not ignorance but treating interim advice as final.
Why One Character Was Enough
Perimeter rules usually look for a pattern in a web request, such as a path, a parameter or a string. Web servers and applications, by contrast, interpret requests flexibly: they decode characters, accept alternate encodings and ignore differences in case or separators. Any gap between what the rule checks and what the application accepts is room for an attacker.
A reasonable objection is that a well-written rule can account for these variations. Sometimes it can, but the attacker only needs to find one variation the rule missed, while the defender needs to anticipate all of them. That asymmetry is why a rule can buy time and cannot replace the fix, and why layered controls like zero trust security for a small business matter.
Treating Every Mitigation as a Deadline
Treating every mitigation as a deadline means that when your team or provider applies a workaround for a vendor flaw, they also record when the actual patch will be installed and who is responsible. The rule goes in today; the date on the calendar is what keeps it from becoming permanent.
Building a Mitigation Register
A mitigation register is a short list, kept in a ticketing system or a shared sheet, of every open workaround: the system, the flaw, the mitigation applied, the date, the owner and the patch deadline. It should be reviewed in every regular IT meeting until each line is closed.
Some teams feel this is paperwork for its own sake. In practice it is the only way to answer the question an executive will ask after a breach: did we know, and what did we do about it? A register turns that answer from guesswork into a record, and it is one of the first things a cyber security audit looks for.
Setting Sensible Deadlines
For flaws listed in CISA’s Known Exploited Vulnerabilities catalog, a mitigation should rarely stay in place longer than a few weeks. For lower-risk flaws, the next scheduled maintenance window is often reasonable, provided it actually happens.
The counterpoint is that some applications cannot be patched quickly because of customization or vendor certification. That is real, and in those cases the right response is extra layers, such as restricting access to known users, adding monitoring and planning the upgrade, not quietly accepting the rule as the end state. Network security monitoring is the layer that notices when a rule has been bypassed.
Holding Contractors and Providers Accountable
Holding contractors and providers accountable means your agreements require them to report patch status for the systems they maintain, apply critical fixes within a defined time, and tell you when they are relying on a workaround instead. Many breaches trace back to a system someone else was responsible for keeping current, a theme in defense supply chain security risks for small firms.
What to Put in the Contract
Ask for a monthly report listing the version and patch level of each system they maintain, a committed response time for critical and actively exploited flaws, and immediate notice whenever they apply a mitigation in place of a patch, with the planned patch date.
Providers sometimes push back that reporting adds cost. A short monthly export from tools they already use takes minutes. If a provider cannot produce one, that tells you something about how well they know your environment.
Reviewing What They Report
Reports are only useful if someone reads them. Assign a person on your side, even part time, to review the monthly report, compare it with vendor advisories and ask about anything that looks stale. An independent check once or twice a year adds a second set of eyes, a natural part of managed security services.
Verifying Patches Instead of Trusting Approvals
Verifying patches means confirming the fix is actually installed and effective on the production system, rather than relying on a change ticket marked complete or an approval email. The gap between approved and installed is where many organizations get caught.
How to Confirm a Fix
Ask for the application’s version and patch level read directly from the production server, with a date. For high-risk flaws, a vulnerability scan or a vendor-provided check script can confirm the fix from outside. For web applications, a test request that previously triggered the vulnerable behavior should now fail.
The objection that production checks risk disruption is fair for some systems. Most version checks are read-only and harmless, and scanners can be scheduled outside business hours.
When You Find a Gap
If verification shows a system still relying on a workaround past its deadline, escalate it the same day. Restrict access further if you can, increase monitoring, and set a firm date for the patch with a named person accountable. Consider whether the data on that system needs a breach review in case the workaround was already bypassed, and confirm your business disaster recovery plan covers it.
Building the Habit Across the Business
Building the habit across the business means every team that owns an application, not only IT, understands that vendor advisories have two parts: what to do now and what to do next. Finance, HR and operations often own systems IT barely touches, and the people in those teams benefit from security awareness training that covers vendor advisories.
Questions to Ask This Week
- Which business applications are maintained by outside contractors or vendors?
- Are any of them currently protected by a workaround instead of a patch?
- When will each of those workarounds be replaced, and who owns it?
- Who reads vendor security advisories for each application?
Keeping the List Short
The goal is not a long register; it is a short one. Each line that closes reduces risk across your cybersecurity program. A register that grows month after month is a signal that patching capacity, not awareness, is the real constraint, and that is a resourcing decision leaders can act on.
Frequently Asked Questions
Is a web application firewall rule enough to protect an unpatched system?
A rule can reduce risk while you patch, but attackers can often find request variations it misses. Treat it as temporary and install the vendor’s fix as soon as possible.
How did ShinyHunters get past the PeopleSoft mitigation?
Researchers found that changing a single character in the attack request let it evade the perimeter rule while the PeopleSoft server still processed it. Organizations that applied Oracle’s June 10 patch were not affected by that bypass.
How long should a security workaround stay in place?
For actively exploited flaws, a few weeks at most, with a written deadline for the real fix. Longer delays need added safeguards and leadership sign-off.
What should contractors report about patching?
Ask for monthly version and patch levels for each system they maintain, response times for critical flaws, and notice whenever a workaround replaces a patch.
How can we confirm a patch is really installed?
Read the version from the production system, run a vulnerability scan, or test that the previously vulnerable behavior now fails. An approved ticket alone is not proof.
Who Stands Behind This Guidance
Mindcore Technologies manages security and infrastructure for small and midsize organizations, many of which depend on business applications maintained by a mix of internal staff and outside vendors. Our team follows CISA’s exploited vulnerability list and vendor advisories daily and helps clients turn each one into a fix with an owner and a date. That focus on accountability reflects the priorities of Matt Rosenthal, Mindcore’s CEO, who has built the company around giving leaders a clear record of what protects them and what still needs work.
Close the Gap Between Mitigation and Patch
The ShinyHunters breach of the FBI’s jobs portal shows that a firewall rule bought time and then failed, while the patch released months earlier would have held. Keep a register of every workaround in place, give each one a patch deadline and an owner, require contractors to report patch status, and verify fixes on the production system instead of trusting approvals. That habit costs little and closes the gap attackers look for first. If you want help building a mitigation register or reviewing your providers’ patch reporting, book a free strategy call and we will set it up with you.
