TL;DR: More than 300 PeopleSoft instances were compromised by June 10, 2026 as ShinyHunter exploited the platform, underscoring how application-layer access weaknesses can turn into broad identity exposure in higher education environments, according to Pathlock. Persistent access controls, entitlement review, and application governance now matter as much as perimeter defence.
At a glance
What this is: This is a Pathlock event page that states ShinyHunter is exploiting PeopleSoft and that 300+ instances were compromised as of June 10, 2026.
Why it matters: It matters because higher education IAM and application security teams must treat ERP access, privileged entitlements, and account lifecycle controls as active attack surfaces, not administrative back-office tasks.
By the numbers:
- ShinyHunter is exploiting PeopleSoft, 300+ instances compromised as of June 10, 2026
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
👉 Read Pathlock's event page for EDUCAUSE conference details and team presence
Context
PeopleSoft exploitation is a governance problem as much as a security one. When application access is reused, over-permissioned, or insufficiently reviewed, a compromise can spread beyond a single account or module and become a larger identity exposure across an enterprise application stack.
Higher education environments make this worse because they often combine long-lived application accounts, distributed administration, and mixed ownership between IT and business teams. The fact pattern here is a warning for any programme that still treats ERP access as routine administration rather than a controlled identity lifecycle.
Key questions
Q: What breaks when PeopleSoft access is not tightly governed?
A: When PeopleSoft access is not tightly governed, attackers can abuse valid accounts, integration users, or administrative roles to move from one compromised instance into broader application exposure. The core failure is persistent entitlement, where access outlives the business need and remains available for reuse after the original context has changed.
Q: Why do ERP environments increase identity risk for security teams?
A: ERP environments increase identity risk because they concentrate sensitive workflows, privileged access, and delegated administration in one place. If account ownership is unclear or access review is weak, a single compromised entitlement can affect many users, functions, or instances, which makes revocation speed and visibility critical.
Q: How do you know if application access reviews are actually working?
A: Access reviews are working only when they result in measurable removal of stale accounts, roles, and integrations. If the same privileged entitlements keep reappearing, or if reviewers cannot identify an owner or business purpose, the programme is documenting risk rather than reducing it.
Q: Who is accountable when a shared application identity is abused?
A: Accountability should sit with the business owner of the entitlement, the application owner who granted it, and the IAM or governance team that certified it. Shared application identities fail when everyone assumes someone else will revoke them, so clear ownership and removal responsibility are essential.
Technical breakdown
How ERP application access becomes an exploitation path
Enterprise resource planning platforms concentrate business-critical workflows, so attackers do not need a kernel exploit to cause damage. They look for exposed authentication paths, weakly governed service accounts, stale integrations, and overly broad administrative roles. In a PeopleSoft environment, that can translate into account takeover, unauthorised data access, or abuse of trusted application sessions. The problem is not just the platform itself. It is the identity layer wrapped around it, including who can create access, who can approve it, and who ever reviews it again.
Practical implication: review ERP access as a governed identity surface, not a generic application-admin task.
Why standing privilege turns application compromise into broad reach
Standing privilege gives an attacker a durable path once they obtain a valid credential or account context. In application environments, this often includes service accounts, integration users, or admin roles that persist long after the original operational need has changed. That persistence shortens the attacker’s work and lengthens the defender’s exposure. The critical failure is not only access existence, but access longevity without lifecycle control, especially where application owners assume technical teams will handle revocation.
Practical implication: tie high-risk application entitlements to explicit ownership, expiry, and revocation workflows.
Why access reviews alone do not close the gap
Access reviews are effective only when they are tied to accurate entitlement data and timely remediation. In many organisations, reviews become a reporting exercise that confirms the presence of access without forcing removal. For application ecosystems with many inherited roles and delegated administrators, that is not enough. The control must connect discovery, certification, and revocation so that stale access is actually removed, not merely documented. Otherwise, compromised or unnecessary entitlements continue to exist after the review cycle ends.
Practical implication: pair certification with enforced removal for application accounts, roles, and integrations.
Threat narrative
Attacker objective: The attacker aims to turn a single exploited application surface into repeatable access across many PeopleSoft instances and the data they protect.
- Entry appears to occur through PeopleSoft exploitation, giving the attacker a path into the application environment and its associated identities.
- Credential access or abuse likely follows through valid application accounts, privileged roles, or trusted integrations that can be reused once inside.
- Impact is achieved by extending access across multiple instances, exposing business data and operational systems at scale.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
PeopleSoft exploitation is really an identity governance failure disguised as an application incident. Once a business platform becomes a repeated entry point, the programme has lost control of who can still act, not just who should. Higher education teams should read this as a sign that application ownership, entitlement review, and revocation discipline are still too fragmented to contain lateral access.
Standing application privilege is the failure mode this case represents. The issue is not simply that a vulnerable platform exists. It is that long-lived administrative and integration access can survive business changes, giving an attacker a durable foothold after the original need has passed. The implication is that lifecycle control for ERP access must be treated as a continuous governance process, not a periodic audit.
Access reviews do not protect a system that cannot reliably map real entitlements to real owners. When instance sprawl, delegated administration, and inherited roles obscure accountability, recertification becomes a paper exercise. NHI and IAM teams should treat this as a visibility problem first, because without authoritative entitlement inventory, review outcomes do not translate into removal.
Identity blast radius: In multi-instance enterprise application estates, one abused account can expose far more than the original login path suggests. That blast radius grows when the same credentials, roles, or integrations are reused across environments. Practitioners should use this case to re-evaluate how much trust they still place in shared application identities.
Higher education ERP governance now sits on the same boundary as NHI security. Application users, service accounts, and delegated administrators all create machine-readable access paths that can outlive the business reason for their existence. The field should stop treating these controls as separate disciplines, because the attacker does not make that distinction.
From our research:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which leaves stale access in place far longer than most teams expect.
- For deeper context: 52 NHI Breaches Analysis shows how over-privileged access and weak offboarding repeatedly turn valid credentials into repeatable breach paths, not one-off incidents.
What this signals
Standing access is the core lesson here: when application identities are reused across instances and no one owns revocation, compromise scales faster than remediation can keep up. Teams responsible for ERP governance should expect attackers to target the longest-lived, least visible access paths first.
If your PeopleSoft estate relies on shared admins, inherited roles, or manual recertification, the operating model is already signalling risk. The next step is not another review cycle alone, but a tighter link between entitlement inventory, approval history, and enforced removal.
The practical signal for programme owners is simple: if an account or role can survive business change without a fresh legitimacy check, it is an exposure path. That is especially true in mixed human and machine access models where NHI governance and IAM controls overlap.
For practitioners
- Map all PeopleSoft identities to business ownership Build an authoritative inventory of human, service, and integration accounts tied to each PeopleSoft instance, then require a named business owner for every privileged entitlement and delegated admin role.
- Enforce lifecycle revocation for stale application access Set explicit expiry and revocation triggers for accounts, roles, and integrations when staff change function, vendors change scope, or instances are decommissioned.
- Prioritise high-risk entitlement review over broad recertification Focus certification cycles on administrative roles, integration users, and cross-instance accounts first, because those are the access paths most likely to turn a compromise into broad exposure.
- Separate evidence of access from evidence of legitimacy Require review workflows to prove not only that access exists, but that the access still has an active business purpose and a valid technical dependency.
Key takeaways
- PeopleSoft exploitation becomes an identity problem when long-lived access, delegated administration, and weak ownership let attackers reuse valid entitlements at scale.
- The scale indicator here is not only the number of compromised instances, but the fact that broad application estates can turn one foothold into repeated exposure.
- Practitioners should focus on ownership, revocation, and entitlement visibility, because those controls reduce the blast radius that exploit-driven access depends on.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Persistent privileged access is central to this PeopleSoft exposure pattern. |
| NIST CSF 2.0 | PR.AC-1 | Access control and identity management are directly implicated by reused application identities. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust requires continuous verification of application access, not inherited trust. |
Review privileged PeopleSoft and integration accounts for unnecessary standing access and enforce revocation.
Key terms
- PeopleSoft instance: A deployed environment of Oracle PeopleSoft that supports a specific organisation, business unit, or workload. In identity terms, each instance can carry its own users, roles, integrations, and administrative boundaries, which means compromise or misconfiguration in one instance may not stay isolated.
- Standing privilege: Access that remains continuously available rather than being granted only when needed. In application estates, standing privilege often sits in administrative, integration, or service accounts, and it becomes dangerous when no lifecycle process removes it after the original business need has ended.
- Entitlement visibility: The ability to see who has access to which system, role, or function and why that access exists. In practice, entitlement visibility is the foundation for review and revocation, because teams cannot remove risky access they cannot reliably identify or explain.
- Identity blast radius: The amount of downstream access, systems, or data exposed when one identity is compromised. In environments with shared accounts, inherited roles, or cross-instance reuse, the blast radius expands quickly because one valid credential can unlock many trusted paths.
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: ShinyHunter is exploiting PeopleSoft, 300+ instances compromised as of June 10, 2026. Read the original.
Published by the NHIMG editorial team on 2026-01-06.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org