A PeopleSoft server can hold the credentials that connect payroll, databases and other business systems. If that server is compromised, restoring its availability is only part of recovery. Someone must establish which credentials it could read, retire exposed access and deliver replacements into a trusted environment.
In research published on September 25, Mandiant and Google Threat Intelligence Group report renewed exploitation of CVE-2026-35273. They observed web shells on dozens of systems across several sectors and describe attackers bypassing some path-based web application firewall rules. Their guidance explicitly includes rotating credentials accessible to the PeopleSoft application account.
The confirmed vulnerability and the limits of the campaign report
Oracle's June 10 advisory identifies an unauthenticated remote code execution vulnerability in PeopleTools, with a CVSS 3.1 score of 9.8. It lists supported affected versions 8.61 and 8.62. Operators should use the advisory's patch-availability instructions for their installation; the public table is not a list of fixed point releases. Older unsupported versions are not established safe by their absence from that table.
The September development is renewed exploitation of an already disclosed flaw. Reuters reports that the campaign reached organizations which had added firewall rules without applying Oracle's patch. Its reporting also makes a separate limit clear: Reuters had not corroborated the attackers' claim that a PeopleSoft vulnerability provided access to FBI data. This campaign report should not be used to turn the earlier FBIJobs allegation into a confirmed exploit path.
The public sources do not establish what was copied from any particular organization. A vulnerable server, a suspicious request and a confirmed intrusion are different findings. Use your own investigation to set the recovery scope, and record uncertainty instead of declaring every connected system breached.
Build a credential inventory without copying the secrets
Give the application owner and incident lead a shared inventory of references: credential names, issuers, consumers and owners. Keep actual values in the approved secret store. A useful starting point is the access available to the application's operating-system identity, rather than a list of passwords that administrators happen to remember.
- Database access: identify each connection identity, the databases it reaches and every node or scheduled job that uses it.
- System integrations: list credentials used to exchange data with other applications, including batch jobs and transfer services.
- Cloud and storage access: map reachable keys or identities to their permissions, including exports and backups.
- Operator access: ask whether administrators used privileged accounts or stored recovery material on the affected host.
These are investigation categories, not a claim that all four were stolen. For each entry, record what makes exposure plausible, which logs can narrow the time window, and who can revoke it. If the investigation finds unexpected identities or grants, track their removal separately from replacement of known credentials.
Use a recovery sequence that does not expose the replacement
- Establish a trusted destination. Contain the affected environment, preserve relevant evidence and follow the incident team's recovery decision. Entering a fresh secret on a host that still has attacker access can expose it immediately. Patching alone does not demonstrate that persistence is gone.
- Coordinate revocation with the service owner. Confirm which production consumers depend on the credential. Choose immediate revocation or a tightly controlled replacement window based on the incident and availability requirements. Give that window an owner and an end time.
- Reduce the replacement's authority. Avoid restoring a shared administrator credential merely because it is convenient. Use a distinct identity for the application and remove privileges that the documented integration does not need.
- Verify the receiving operator. Use a contact route established before the incident. Record the intended system and recipient, then deliver the value through an approved restricted channel. Keep the incident ticket useful by recording the credential reference and completion time, not the value.
- Prove the old access has ended. Confirm revocation at the issuer, check the intended consumers work, and review subsequent authentication failures and unexpected activity. Removing a value from a configuration file does not revoke a copy someone already holds.
A small handoff with a clear end
Suppose the database owner creates a replacement credential and a separate operator must configure the recovered application. Share only the value required for that task, confirm receipt and store it in the organization's managed secret system. Avoid bundling a database export, recovery codes and administrator passwords into the same transfer. The receiving operator should be able to complete the task with narrowly scoped access.
Where organizational policy permits it, a one-time encrypted Secretus link can support that temporary human handoff. Its expiry or consumption does not revoke the credential at the database or cloud provider. Secretus also cannot clean a compromised endpoint or establish that a PeopleSoft environment is ready for recovery. Those decisions remain with the incident team and the credential issuer.