PeopleSoft breach exposure shows ERP identity controls still lag

At a glance

What this is: This is an analysis of a large-scale PeopleSoft breach in which ShinyHunters used vulnerabilities and weak ERP identity controls to compromise more than 300 instances.

Why it matters: It matters because ERP platforms often sit outside modern identity controls, leaving admin access, logging, and masking gaps that IAM and PAM teams still need to close.

By the numbers:

• ShinyHunters exploited Oracle PeopleSoft vulnerabilities across more than 300 instances at over 100 organisations worldwide.

Context

PeopleSoft environments often sit in a governance gap between identity controls, application security, and ERP administration. When privileged access can bypass the identity provider, and when logging stops at the login event instead of the transaction, defenders lose visibility into who actually viewed or extracted sensitive records.

In this case, the security problem was not only the vulnerability chain itself. It was the combination of weak admin credential control, limited application-layer monitoring, and insufficient data masking, which allowed the attackers to operate as if they were legitimate users inside the ERP application.

The education sector was hit hardest, which is consistent with the concentration of sensitive student, payroll, and financial records in higher education ERP deployments. That makes this a governance issue as much as a breach story: access design, not just patching, determined the blast radius.

Key questions

Q: What breaks when PeopleSoft admin accounts bypass the identity provider?

A: When administrative access can authenticate directly to the application, the IdP no longer governs the highest-risk session. That breaks central MFA, conditional access, and audit consistency at the exact point where privileged ERP actions occur. Security teams should assume any direct-login path creates a separate trust boundary that must be closed or independently controlled.

Q: Why do ERP vulnerabilities create outsized risk in higher education?

A: Higher education ERP environments concentrate student, payroll, financial aid, and research-related records in one system, which makes successful abuse unusually high impact. The problem is not only record volume. It is that broad but complex role structures often leave privileged access, logging, and masking uneven across departments and campuses, increasing the blast radius of one compromise.

Q: What are the signs that ERP access controls are failing?

A: Common warning signs include role structures that have become too complex to manage, inconsistent access policies across business units, and users retaining access after their job changes. Unusual activity flagged by monitoring tools is another signal. When these appear together, access governance is no longer keeping pace with business change and the ERP environment becomes harder to audit.

Q: Should teams enforce masking or transaction logging first in ERP systems?

A: If the environment already has privileged access gaps, transaction logging usually comes first because it creates the forensic record needed to understand abuse. Masking then reduces what a valid user can see and extract. In practice, the two controls are complementary, but logging gives faster incident insight when an ERP compromise is already underway.

Technical breakdown

How the PeopleSoft gadget chain reached application-layer access

The reported attack path used a gadget chain, meaning a sequence of vulnerabilities that together bypassed normal access assumptions. Oracle’s out-of-band alert for CVE-2026-35273 mattered because it described remote exploitation without authentication, which is a direct route into application-layer execution. Once inside, the attacker could authenticate as a privileged user or bypass authentication entirely, then act through PeopleSoft’s own application logic. That distinction matters: the compromise did not rely on a classic database breach, so database-only monitoring would miss the abuse pattern.

Practical implication: monitor and patch the application layer, not just the database tier.

Why legitimate user behaviour is dangerous in ERP abuse

The article says attackers accessed and extracted records via legitimate application APIs, which means the application saw the activity as normal user behaviour. In ERP systems, that creates a detection blind spot if controls only validate session entry and not the sensitivity of the transaction itself. This is where policy enforcement has to move inside the application path, because privilege, page access, query activity, and download behaviour all become security-relevant events. Without that layer, the system cannot distinguish a normal finance or student-services workflow from exfiltration.

Practical implication: log page, field, and component-level actions, not just sign-ins.

How weak admin credential hygiene extends the breach

The post-breach script described in the article shows how attackers pivoted after initial compromise by using common administrative accounts such as psoft, oracle, and linuxadm, then falling back to SSH key-based authentication when passwords failed. That pattern turns default or weak admin accounts into a lateral-movement bridge across internal PeopleSoft systems. The issue is not only exposure of credentials, but the persistence of accounts that retain broad access after deployment decisions, upgrades, or staff changes. ERP environments often keep these accounts alive far longer than their operational justification.

Practical implication: remove default admin accounts and audit SSH fallback paths immediately.

Threat narrative

Attacker objective: The attackers aimed to steal high-value ERP data at scale, maintain access where possible, and use extortion after exfiltration.

1. Entry occurred through a PeopleSoft gadget chain, including a remotely exploitable vulnerability that allowed unauthenticated access in some cases.
2. Credential and privilege abuse followed when the attackers authenticated as privileged users or bypassed authentication and then operated through legitimate application APIs.
3. Escalation and lateral movement were enabled by common administrative accounts and SSH key fallback, allowing the script to reach internal PeopleSoft systems.
4. Impact was achieved through data extraction, persistence, and ransom note deployment after compromise.

Breaches seen in the wild

• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.
• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ERP identity failure is no longer an edge-case problem: When privileged access can bypass the identity provider and application activity is not logged at field level, ERP systems become invisible to the controls that security teams assume are already in place. That is especially true in higher education, where high-value records are concentrated behind complex role structures. The practitioner conclusion is straightforward: ERP governance must be treated as an identity problem, not only an application-hardening problem.

Application-layer authorization has become the decisive control plane: ShinyHunters did not need to break every downstream system when the application itself would process requests as legitimate. That means traditional perimeter and database controls are too late in the chain to matter. Organisations need to reframe access governance so that page, field, and component-level decisions are enforced where the transaction occurs, because the breach surface now lives inside the ERP workflow.

Standing admin access remains the easiest path to blast-radius expansion: The article’s mention of default administrative accounts and SSH key fallback shows a governance pattern that survives far too long after go-live. This is not merely poor hygiene. It is an access model that assumes the environment will never be adversarial enough to justify strict account retirement and alternative-authentication control. The practitioner conclusion is to stop treating admin identities as durable fixtures.

Dynamic data masking is a governance control, not a cosmetic layer: If authenticated users can still read sensitive student, payroll, or compensation fields in full, then access review alone has already failed. Masking changes what a valid user can actually see and therefore changes the breach outcome even after login succeeds. In ERP environments, that makes masking part of identity blast-radius reduction rather than a convenience feature.

Assumption collapse: access can be reviewed after it exists: Access review and recertification were designed for privileges that persist long enough to be observed and certified. That assumption fails when attackers authenticate, query, extract, and move laterally inside a short-lived ERP session before review cycles begin. The implication is that governance has to shift from retrospective review to transaction-time enforcement.

What this signals

Identity review is too late when ERP sessions are already live: Access review assumes a user or account remains in place long enough to be certified. In this breach pattern, attackers used valid-looking application activity to move faster than governance cadences, which means transaction-time enforcement now matters more than periodic recertification.

Higher education should treat ERP admin controls as part of core identity architecture, not as a specialist application problem. The combination of direct admin access, weak logging, and full-value data exposure creates a breach path that traditional IAM reporting often misses until after exfiltration.

PeopleSoft breach exposure: The practical lesson is that blast-radius reduction has to happen at the application and data layer, because controlling sign-in alone does not control what an authenticated actor can query, view, or export.

For practitioners

• Audit PeopleSoft admin account inheritance Identify every default, shared, and emergency administrative account such as psoft, oracle, and linuxadm, then map where each one still has direct login or SSH access.
• Enforce application-layer MFA and SSO for ERP admins Require strong authentication inside the application path itself so administrative users cannot bypass the identity provider through direct PeopleSoft sign-in routes.
• Turn on transaction-level logging Capture field, page, component, record-view, query, and download events with full session metadata so investigators can see what was accessed after login.
• Apply dynamic masking to sensitive ERP fields Mask SSNs, bank account numbers, compensation, and student records by default, and log every request that reveals unmasked data.
• Search for known attacker indicators and ransom files Review PeopleSoft logs for the listed IP ranges and look for README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT in web and application server directories.

Key takeaways

• The breach shows that ERP compromise is often an identity and governance failure as much as a vulnerability problem.
• ShinyHunters’ reported campaign reached more than 300 PeopleSoft instances, with higher education especially affected.
• Application-layer MFA, transaction logging, and dynamic masking are the controls that most directly limit the damage from this pattern.

Key terms

• Application-layer monitoring: Monitoring that records what users and accounts do inside the application, not just whether they reached the host or network. In ERP systems, it captures actions such as record views, queries, exports, and privilege changes, which is often the only way to spot legitimate-looking abuse at scale.
• Merge-time enforcement: Merge-time enforcement is the point at which security policy is applied before code enters the shared branch or production path. It is most effective when the control is tied to credible detections, clear ownership, and remediation capacity inside the development workflow.
• Dynamic Data Masking: Dynamic data masking is a runtime control that hides sensitive values in query results without changing the source data. It is commonly used to restrict live access in production systems, but it does not create a portable dataset and depends on the query path for enforcement.
• Standing privileged access: Privileged access that remains continuously available rather than being issued only when needed. It creates governance risk because the access can persist beyond the task, making abuse, misuse, and audit failure more likely unless revocation and session control are tightly managed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.