PeopleSoft exploitation shows access controls fail after low-level entry

At a glance

What this is: This is Pathlock’s report on active PeopleSoft exploitation, highlighting that low-level access can be turned into privilege escalation across hundreds of compromised instances.

Why it matters: It matters because IAM, PAM, and application governance teams need to treat business application access paths as an attack surface, not just the underlying infrastructure.

By the numbers:

• Attackers are exploiting PeopleSoft, with 300+ instances compromised as of June 10, 2026.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Pathlock's article on the PeopleSoft exploitation pattern and patching priorities

Context

PeopleSoft exploitation matters because low-level application access can become a path to privilege escalation when controls around roles, entitlements, and monitoring are too loose. In identity terms, this is not just a software vulnerability story. It is an access governance problem that can turn ordinary application credentials into business process compromise.

Pathlock’s warning points to a recurring enterprise weakness: organisations often secure the perimeter and patch the platform, but leave the application’s internal authorisation model under-governed. For teams running ERP, HCM, and other mission-critical systems, that gap can be enough for attackers to move from entry to sensitive process abuse.

Key questions

Q: What breaks when low-level ERP access can be escalated into sensitive business actions?

A: The control boundary breaks. When a low-privilege account can reach high-value PeopleSoft functions through role inheritance or weak transaction design, the organisation no longer knows which identities can affect payroll, finance, or HR processes. That makes the application itself part of the attack path, not just the target.

Q: Why do ERP vulnerabilities create identity governance problems as well as security problems?

A: Because attackers rarely need full admin access to cause damage. In ERP systems, weak segregation of duties, over-broad roles, and standing entitlements can let a modest foothold turn into meaningful business process control. Identity governance is what limits that blast radius when software flaws are exploited.

Q: How do security teams know whether application access is too broad?

A: Look for identities that can perform multiple sensitive steps in one workflow, especially request, approve, and execute combinations. If the same account can move from ordinary access to materially changing records or approvals, the role model is too permissive and should be reworked.

Q: Who should own remediation when ERP abuse crosses patching and access control?

A: Ownership should be shared, but the response must be coordinated. Application owners need to fix the vulnerability, IAM and PAM teams need to remove excess privilege, and audit or GRC teams need to verify that sensitive business actions are being monitored and recertified.

Technical breakdown

How low-level access becomes privilege escalation in PeopleSoft

PeopleSoft and similar ERP platforms rely on layered application permissions, roles, and transaction controls. If an attacker obtains a low-privilege account, they may be able to chain application functions, abuse over-broad roles, or reach administrative workflows that were never meant to be exposed to that account class. The flaw is rarely just one permission. It is usually the combination of weak role design, missing segregation of duties, and poor anomaly detection that allows the escalation path to remain visible only after damage begins.

Practical implication: review application roles and transaction paths for escalation chains, not just for direct admin access.

Why patching alone does not stop business process compromise

Patching removes the specific software defect, but it does not correct access design, standing privilege, or weak activity oversight. In ERP environments, an attacker who already has low-level access may still exploit excessive entitlements or hidden workflows before remediation closes the vulnerability. That is why vulnerability management and identity governance need to operate together. One reduces exploitability, the other reduces the blast radius when exploitation succeeds.

Practical implication: pair patching with entitlement review and activity monitoring so exploitability and blast radius are addressed together.

Access controls for mission-critical applications need runtime visibility

Mission-critical applications often have complex transaction logic that standard infrastructure monitoring does not see. Runtime visibility means tracking who executed which business action, from which role, and whether that action fits the account’s normal operating pattern. Without that layer, attackers can abuse legitimate application pathways while remaining inside expected technical behaviour. For security teams, the governance question is whether the application can detect and constrain suspicious privilege use before sensitive records or business processes are altered.

Practical implication: instrument business actions, not just logins, so suspicious privilege use is observable in context.

Threat narrative

Attacker objective: The attacker aims to turn ordinary application access into control over sensitive business processes and enterprise data.

1. Entry occurs through vulnerable PeopleSoft exposure or another low-level application access path that gives the attacker a foothold inside the environment.
2. Escalation follows when the attacker exploits weak role design, excessive entitlements, or a software flaw to move from low privilege into higher-value application functions.
3. Impact lands as sensitive business process compromise, where finance, HR, or operational workflows can be altered, abused, or exposed at scale.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Business application access is now part of the identity perimeter. ERP compromise is not only a patch-management issue because the attacker’s real leverage comes from application entitlements, role design, and transaction authority. When low-level access can be converted into privileged business actions, identity governance has failed before infrastructure controls can react. Practitioners should treat ERP authorisation paths as first-class identity assets.

Excessive application privilege is the failure mode this pattern exposes. The problem is not simply that a flaw exists in the software. The problem is that many organisations allow low-level users to inherit pathways that can reach sensitive functions with too little segregation of duties. That creates a governance gap where exploitation and privilege design reinforce each other. Teams need to identify where business-role sprawl gives attackers room to escalate.

Runtime business-process monitoring is the missing control plane. Traditional security monitoring often sees a login and then stops at technical events, but ERP abuse happens inside approved sessions and approved applications. The control failure is lack of contextual oversight over business transactions, not just authentication. That means identity, audit, and application control teams need to share a common view of activity if they want to detect abuse early.

Mission-critical application security and IAM can no longer be separated. When attackers exploit application flaws to reach sensitive workflows, the distinction between vulnerability management and access governance breaks down. That separation leaves security teams patching one layer while leaving privilege abuse untouched in another. The practical conclusion is that ERP security programmes need to be designed around business-authorisation risk, not only around technical hardening.

Pathlock’s warning reflects a broader enterprise pattern: application privilege is where compromise becomes consequential. The industry often measures success by whether a system was patched, but the operational question is whether an attacker could still act meaningfully before the patch landed. That is the real test for access control maturity in ERP environments.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most identity programmes still cannot see their non-human attack surface clearly.
• For a broader view of how identity governance breaks down across machine identities, read the 52 NHI Breaches Analysis for recurring failure patterns and control gaps.

What this signals

Business process compromise will keep surfacing as an identity problem, not just an application flaw. Teams that only track infrastructure vulnerabilities will miss the real risk if ERP entitlements remain too broad. The practical shift is to connect patch management, access governance, and transaction monitoring into one operating model.

Identity teams should expect greater scrutiny of application roles and SoD controls. In mission-critical systems, auditors will increasingly ask whether a low-level account can pivot into sensitive business action without human review. That means access review evidence needs to show not just who has access, but what the account can actually do.

Pathlock’s warning reinforces a broader programme lesson: business systems need the same discipline for identity visibility that infrastructure teams already apply to privileged credentials. When the attack path runs through application logic, the control gap is in role design, not just exposure management.

For practitioners

• Map escalation paths inside ERP roles Identify where low-level PeopleSoft or ERP accounts can chain into high-value functions through inherited roles, nested permissions, or workflow access. Prioritise the transactions that can change pay, vendor data, financial postings, or approval states.
• Review segregation of duties at the transaction level Test whether the same identity can request, approve, and execute sensitive actions in the application. Focus on combinations that create business-process abuse even when no technical admin privilege is present.
• Pair patching with entitlement cleanup Treat the vulnerability as a trigger for access review, not just remediation. Remove excessive roles, limit standing access, and confirm that old test or contractor accounts cannot still reach production workflows.
• Log and alert on sensitive business actions Instrument the application so changes to master data, approvals, and financial processes trigger alerts when they occur outside normal patterns. A login event alone is not enough to detect abuse in mission-critical systems.
• Use access reviews to validate real business need Re-certify who can touch high-risk ERP functions and require the business owner to confirm each entitlement. If the account’s purpose is unclear, remove the access before attackers can use it.

Key takeaways

• PeopleSoft exploitation shows that low-level access can become business-process compromise when application roles are too permissive.
• The reported scale, with 300+ compromised instances, indicates that ERP abuse is not a one-off edge case but an enterprise pattern.
• Patching matters, but only entitlement cleanup, segregation of duties, and runtime transaction monitoring can limit the damage once attackers are inside.

Key terms

• Application access governance: Application access governance is the discipline of deciding who can do what inside business applications and proving those decisions are still correct over time. It goes beyond login control by managing roles, entitlements, segregation of duties, and the business impact of each permission.
• Segregation of duties: Segregation of duties is the practice of preventing one identity from completing all parts of a sensitive business process. In ERP systems, it reduces fraud and misuse by separating request, approval, execution, and reconciliation into different roles or controls.
• Privilege escalation path: A privilege escalation path is the sequence of permissions, workflows, or flaws that lets a low-privilege identity gain higher authority than intended. In mission-critical applications, the path may be hidden in role inheritance, transaction chaining, or weak workflow controls.
• Runtime transaction monitoring: Runtime transaction monitoring tracks what an identity actually does inside an application while the session is active. It focuses on high-risk business actions, such as approvals or master-data changes, so security teams can detect abuse that normal login logs would miss.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Pathlock: May Patch Tuesday roundup, including PeopleSoft exploitation and SAP S/4HANA risk. Read the original.