Your company may never have purchased PeopleSoft. That does not answer whether a recruitment, payroll or other service provider uses it with your information. Following the FBI jobs portal reporting, that is a useful place to start: where does the technology touch our business, and who is responsible for checking it?

You do not need to know the final explanation for the FBI incident to start that review. You do need to separate three things: software present, exposure to a particular vulnerability, and evidence of compromise. Finding one does not establish the others.

This guide walks through identifying the relevant systems, reducing unnecessary exposure, checking for suspicious activity and recording what has actually been verified.

What is established—and what remains unknown

On September 23, the FBI acknowledged claims concerning its recruitment portal and alleged exposure of employee information. Its statement leaves the entry point undetermined, including whether it was within the FBI or a third party. It does not identify the vulnerability. FBI statement.

There is also an established, earlier PeopleSoft issue. Oracle's June advisory for CVE-2026-35273 lists PeopleTools 8.61 and 8.62; older unsupported releases may also be affected. Do not treat that advisory as confirmation of what happened at the FBI. Oracle advisory.

For the alleged new vulnerability, the primary sources reviewed do not establish a reliable version-based exposure test or a confirmed fix. An accurate result may therefore be “PeopleSoft identified; current applicability under review.” That still gives you a clear owner and next action.

Choose your starting point:

  • You operate PeopleSoft: ask the application owner to review versions, administrative exposure and relevant activity now.
  • A provider may operate it: send the supplier request in section 5 and track the response against the service it covers.
  • You do not know: begin with the inventory questions below. Keep the platform unknown until an accountable owner can confirm it.

1. Find the software—and the service behind it

Start with the people responsible for HR, recruitment, payroll, finance and the applications supporting them. Ask your IT provider and procurement owner about outsourced services. Include production, test, disaster-recovery and older environments still connected to business systems.

For each relevant service, record:

  • The service name and the business information it handles.
  • The underlying application and exact PeopleTools version, if known.
  • Who operates the environment, including any hosting or subcontracted provider.
  • The accountable technical owner and the date of the supporting evidence.
  • Whether external access exists, and how that answer was established.

Ask the administrator for installation records or an inventory export. Keep the PeopleSoft application release separate from the PeopleTools release; a label such as “HCM 9.2” is not enough to compare against a PeopleTools advisory. A supplier's brand, an Oracle logo or a familiar-looking login page is also insufficient evidence of the installed product and patch level.

A concrete version check: in supported PeopleTools environments, Oracle documents the Help → About dialog as showing the PeopleTools version. Have the administrator capture that value for the relevant environment, then reconcile it with the installed patch records. A screenshot of a version is a starting artifact, not proof that every applicable fix is installed. Oracle documentation.

If you are a small business using an outsourced service, the most useful first step may be a provider question rather than a technical scan: “Does this service, including its subcontractors, use PeopleSoft or PeopleTools with our information?”

2. Use an SBOM within its actual scope

A software bill of materials describes components and relationships within the software it covers. It can help identify PeopleSoft-related entries, versions and dependencies. CycloneDX SBOM overview.

Our recommendation is to use an SBOM alongside the application and supplier-service inventory. First establish what produced the document, which application or deployment it describes, and when it was generated. A build-time document may not represent everything currently deployed. A document for your own application may say nothing about the technology inside your payroll provider.

Treat a match as a lead to confirm. Treat no match as a result limited to that document—not proof that your company has no PeopleSoft exposure. Neither result proves whether data has been stolen.

3. Check administrative exposure and applicable mitigations

Have the application owner review current Oracle guidance, using the installed components, patch history and deployment configuration. Oracle's advisory index links the current and earlier updates; a single CVE search is not a complete patch review. Oracle security advisories.

For the documented June campaign, Mandiant and Google recommend disabling EMHub in multi-server deployments or removing the PSEMHUB application in single-server deployments, following Oracle guidance. Where that cannot be done, their guidance calls for restricting external access to /PSEMHUB/* and /PSIGW/HttpListeningConnector. It warns that WAF body-inspection rules alone are insufficient. These measures address the documented campaign; they are not a verified fix for the alleged September flaw. Original defensive guidance.

Translate that guidance into a controlled task. Identify legitimate administrative and system-to-system users, review dependencies with the application owner, prepare the change and rollback, and verify the intended restriction afterward. Avoid blindly blocking every integration URL or assuming that a successful homepage login proves a security change is correct.

Also ask what the application can reach: databases, file shares, other environments and outbound destinations. Our recommendation is to document required connections and review unnecessary permissions or network access. A public applicant login and an exposed administrative endpoint are different findings; record them separately.

For verification, record the endpoint, the network position used for the authorized check, the expected result and the observed result. A timeout or a single denied request does not by itself establish that every access path is restricted. Pair observations with configuration evidence, and separately confirm that required business workflows still function.

4. Check for suspicious activity, even after an update

Patching addresses a vulnerability; it does not establish whether an earlier intrusion occurred or persisted.

The June investigation provides defensive leads: unusual external requests to the management/integration endpoints, unexpected JSP files in the PSEMHUB application, unauthorized staging content and suspicious outbound SMB traffic. These are historical campaign leads. They are neither confirmed September indicators nor, individually, conclusive proof of compromise. Review them in context against your deployment and authorized activity. Mandiant / Google investigation.

If suspicious activity warrants an incident response, involve the responsible team promptly, coordinate containment and preserve relevant logs and volatile evidence. Do not erase potentially useful artifacts while trying to clean up. CISA's response guidance provides a starting framework for containment and evidence preservation. CISA response checklist.

Record which systems and time period were reviewed, which evidence was available, and which gaps remain. “No suspicious activity found in the logs we retained” is more precise than “we were not breached.”

5. Get a supplier response you can use

Send this request to the provider's technical or security contact. It asks for a scoped answer without presuming the provider has been compromised.

We are reviewing PeopleSoft-related exposure following recent reporting. Please confirm whether services handling our information, including relevant subcontractors, use PeopleSoft or PeopleTools. For any relevant environment, please provide:

  1. The service scope, hosting/operator responsibility and installed PeopleTools release.
  2. The relevant Oracle advisories reviewed and the status of applicable mitigations or updates.
  3. Evidence of the actions taken, their completion dates and how effectiveness was checked.
  4. Whether administrative or integration endpoints are externally reachable, and how this was verified.
  5. Whether suspicious activity has been reviewed, including the systems, period and evidence covered.
  6. Any unresolved questions, the accountable owner and the next update time.

Please distinguish verified findings from work still in progress. A scoped written summary is sufficient initially; sensitive supporting details can use an agreed secure channel.

Ask for a response date that reflects the importance of the service and information involved. If the provider does not yet know the underlying platform or exposure, retain that as an open item. A general security certification or assurance does not answer these incident-specific questions.

6. Close actions with evidence

Use one row per system or service. A compact record should contain service, operator, evidence reference/date, open question, action, owner, target date and verification result.

For example, consider a fictional outsourced recruitment service. The business knows the provider's name but not the platform. Its first status is “platform unconfirmed.” The next action is to obtain a scoped provider response, with the HR service owner accountable for follow-up. It is not “unaffected” merely because an internal inventory contains no PeopleSoft entries.

If the provider later confirms PeopleSoft and reports an access-control change, record the claim and supporting evidence separately. Close the specific action when its agreed verification is complete. Other questions—such as historical activity review or applicability of a newly disclosed vulnerability—may remain open.

Our suggested first-session outcome is modest and useful: identify the relevant services, assign owners, escalate urgent findings and agree when the missing answers will arrive. Keep that record current as vendor guidance changes.

The review is useful when it changes the next decision: a service owner is identified, an unnecessary access path is restricted, suspicious activity is escalated, or a supplier's unanswered question gets a deadline. Those are concrete improvements you can make while the incident investigation continues.

ViKeLaAi helps teams define their environments, review security evidence and support remediation workflows. This community guide is intended to be useful on its own; the supplier request and review structure can be reused with your existing IT team or provider.