8 October 2026

 

On 6 October, Reuters reported that the FBI had removed an Accenture contractor following a breach exposing sensitive employee information. The FBI attributed the incident to a contractor’s failure to implement an explicitly issued patch. Reuters’ sources identified Oracle PeopleSoft as the platform; the bureau did not name it publicly. 

So what went wrong in patch management? To understand where it can break down, we follow a patch through a hypothetical organisation running an outsourced human resources system. 

 

Who owns the security update?

 

On 10 June, Oracle issued an alert for CVE-2026-35273, a vulnerability in PeopleSoft PeopleTools, the technology supporting PeopleSoft enterprise applications. It could allow attackers to execute code remotely without logging in. Oracle urged immediate action. 

The alert illustrates the urgency such warnings can carry, although it does not establish the route into the FBI. In our hypothetical organisation, the warning reaches the security team. It identifies the affected software and forwards an urgent request to the company operating the personnel application.

Receiving the warning is the easy part. Acting on it requires a map of the application and its dependencies. It may run across several servers, depend on a database and exchange information with payroll and identity systems. The organisation may also have customised it.

Those dependencies also divide the work between people with different responsibilities. The service provider manages the application. An infrastructure team controls the servers. The personnel department owns the business process. Each has a role; somebody must also own the outcome.

Without that responsibility, an alert can become a succession of forwarded messages, each reasonable in isolation, with no clearly accountable person able to move the work forward.

 

Why patch testing can delay deployment

 

Once responsibility is established, the provider proposes an update. The personnel department asks whether it will interrupt payroll processing. The infrastructure team wants an approved maintenance window. Testing must establish that essential functions still work.

These are legitimate concerns. The US National Institute of Standards and Technology’s National Cybersecurity Center of Excellence identifies resource demands, reduced availability and difficulties with testing and prioritisation among the obstacles to patching. 

Our hypothetical team therefore tries the update in a separate test environment. It checks whether users can log in, records remain accessible and integrations still behave as expected.

Testing becomes a bottleneck if it reveals a problem with no agreed resolution, or if nobody can decide what results are sufficient to proceed.

Operations staff are responsible for keeping services available. Security staff want the exposure closed. Business owners need their workflows to continue. All three objectives are valid, but they can pull the decision in different directions.

An update that breaks payroll generates immediate complaints. Leaving a vulnerability open may produce no visible disruption, even while an intrusion goes undetected.

That imbalance can favour postponement. Another meeting, another test, another maintenance window: the service stays available, while the risk remains.

A workable process therefore needs both an agreed testing threshold and someone authorised to settle the trade-off. Otherwise, a technical concern can become an indefinite business delay.

 

Why a firewall cannot replace a security patch

 

While testing continues, the security team introduces a protective filter. A web application firewall can inspect incoming requests and block those matching specified rules.

If correctly configured and effective against the relevant attack, the filter can reduce exposure while the update is prepared. It leaves the underlying flaw in place, however, so its protection depends on recognising and stopping the dangerous requests.

The PeopleSoft campaign shows how that arrangement can unravel. On 25 September, Mandiant and Google Threat Intelligence Group reported renewed exploitation of the June vulnerability across several sectors. Attackers had adapted their requests to bypass some firewall rules. 

They encoded a character in the requested path. Certain filters failed to recognise the altered form, while the application decoded it and directed the request to the vulnerable component.

It is rather like a guard told to block mail addressed to a particular room. An unfamiliar spelling slips past, but the receptionist recognises it and delivers the envelope anyway.

The researchers warned that firewall rules were no substitute for the patch. The attackers had adapted to the defence while the vulnerable component remained unchanged.

For the organisation awaiting its maintenance window, that technical limitation has an administrative consequence. If the filter makes the security ticket appear resolved, the permanent update can slip down the queue. “Temporarily protected” needs to remain visibly unfinished.

 

Verifying that the patch works everywhere

 

Eventually, testing is complete and the maintenance window arrives. The provider installs the update, brings the application back online and confirms that users can log in. It is tempting to close the change ticket and move on.

There is still one question: did the fix take effect on every affected system?

NIST’s patch management guidance includes verification as part of the process. Deployment should be checked to establish that the patch was successfully installed and became effective. 

Suppose our hypothetical application runs on several servers to share demand. If the update reaches only some of them, the remaining machines may still expose the vulnerable component. A successful test through the public login page may not reveal which server answered it.

The provider’s completion report therefore needs to show what was updated and what remains outstanding. The customer needs evidence that corresponds to the actual service, rather than reassurance that an installation command ran successfully.

That distinction turns verification from paperwork into a technical check: what is now running, where, and with which exceptions?

 

Patching does not remove an earlier compromise

 

Even a verified update leaves another possibility: an attacker entered before it was installed.

Google’s PeopleSoft guidance calls for investigation of suspicious activity and measures to remove attacker access, alongside patching.

Our organisation must therefore check more than the updated software state. Suspicious logs, unexpected files or exposed credentials may demand a separate incident response. Repairing the entry point cannot establish what happened while it was open.

Seen across the whole process, patching is a sequence of technical changes and business decisions. Each hand-off needs an owner, and each delay needs to remain visible. The relevant measure is how long affected systems remain exposed, rather than how many requests have been processed.

The supplier’s release starts that work. Evidence that the fix is active across the affected systems completes it. Between those points, an organisation can be busy handling a patch while an attacker still has an opportunity to get in.

 

Further reading on MoveTheNeedle.news: 

• Aikido Security becomes a unicorn by putting developers at the centre of application security — A profile exploring the developer’s role in application security.
• Cybersecurity made in Europe: how aDvens is positioning digital sovereignty as a strategic business choice — How security operations, endpoint protection and network detection connect with questions of control and supplier dependence.
• “We’re Building the AI-Native SOC”: SentinelOne’s Jackie Lehmann on the Observo AI Acquisition — An interview on security monitoring, fragmented data and the blind spots that can hamper threat detection.