Oracle PeopleSoft Security: Architecture, Threats & Patch History (2015-2026)

Oracle PeopleSoft is a widely used enterprise resource planning (ERP) suite that manages critical business functions, including human resources, finance, supply chain, and campus administration. Developed in the late 1980s and acquired by Oracle in 2005, with roughly half of Fortune 100 companies using it in 2015, PeopleSoft remains popular among large organizations and public sector institutions. 

Why PeopleSoft Is Still the Backbone of Enterprise IT

PeopleSoft’s reach extends well beyond HR. In many organizations, it’s where “everything” lives. Deployments are typically on-premises or in private clouds, given the sensitivity of the data it handles (employee records, financials, student information, and more), although Oracle does offer cloud-hosted options as well. Highly customizable, PeopleSoft is built for complex enterprise environments that demand integrated process management. While it’s widely used in higher education, it’s just as common across sectors like manufacturing, retail, government, and healthcare.

PeopleSoft plays a critical role in managing core business data, which means a breach of its systems can represent a worst-case scenario for any organization. Over the years, attackers have increasingly targeted PeopleSoft applications, leading to incidents ranging from HR data theft to covert exploitation of server resources for cryptocurrency mining.

PeopleSoft Architecture and Components

PeopleSoft follows a classic three-tier architecture commonly referred to as the PeopleSoft Pure Internet Architecture (PIA). The tiers include:

Web Server Tier

This is the front-end that end-users interact with via a browser. Oracle PeopleSoft delivers a web interface (built on JSP/servlets), typically hosted on Oracle WebLogic (or alternatively IBM WebSphere). Users access PeopleSoft through a portal-like web application. The web server handles UI rendering and also hosts integration endpoints (servlets) for web services. It communicates with the application server tier over a proprietary protocol.

Application Server Tier

The business logic resides here, running on Oracle Tuxedo (PeopleSoft uses Tuxedo’s Jolt protocol to communicate between the web and app tiers). The application server processes user requests, executes PeopleSoft PeopleCode (the platform’s proprietary programming language), and enforces business rules. It interacts with the database for reading or updating records. In PeopleSoft’s architecture, this tier includes various server processes (for example, “PSAPPSRV” processes) and handlers for core services like the Integration Broker. The app server tier is the heart of PeopleSoft’s processing and also handles security enforcement, such as authentication verification and role-based authorization.

Database Tier

All PeopleSoft data is stored in a relational database (often Oracle Database, but SQL Server and others are supported). The database houses not only transactional data (e.g., employee records, financial entries) but also PeopleSoft metadata and configuration (PeopleTools tables). The application server connects to the DB using a defined Access ID (a high-privileged DB account for the app). Direct end-user connections to the database are not typical; all access goes through the app server (except for certain admin or developer utilities). Because PeopleSoft’s database holds extremely sensitive information, it is a prime target in any attack on PeopleSoft.

Each Tier Matters: Communication Flow and Security Risks

Communication flows through these tiers whenever a user performs an action. For example, when a user submits an HR form on the web UI, the request goes to the WebLogic server, which invokes PeopleSoft servlets that package the request for the application server. The application server (Tuxedo) processes the request, running any required PeopleCode and SQL, then returns the results to be rendered on the web page. This multi-tier design allows scaling and segregation of duties, but it also means each layer (web, app, DB) can be a point of attack if not properly secured.

Mitigate ERP hacking. Sign up for a Free 30-Day Rublon Trial →

Authentication and SSO Flow in PeopleSoft

PeopleSoft has its own authentication mechanism and also supports single sign-on (SSO) across multiple PeopleSoft modules or other Oracle applications. Users typically authenticate via the web tier. By default, PeopleSoft can handle login credentials internally (validating against its user directory stored in the database), or it can delegate to external identity providers (LDAP, SAML, etc.).

The Role of PS_TOKEN in SSO

After a user is authenticated, PeopleSoft issues a session cookie called PS_TOKEN. This cookie is crucial for SSO. It allows the user to navigate across different PeopleSoft applications without re-login, as long as those systems trust each other.

PS_TOKEN contains the user’s identity and some metadata, and is cryptographically signed with a secret “Node Password” known only to the PeopleSoft systems. In short, each PeopleSoft instance (or each logical node, like HR system, Financials system, Campus system) shares a secret key used to sign and verify SSO tokens. The token is not encrypted (the data inside can be base64-decoded to reveal user ID, timestamp, etc.), but the signature (often a SHA-1 HMAC) prevents tampering. When a user attempts to access another trusted PeopleSoft application, that app will accept the PS_TOKEN if it can validate the signature with its copy of the Node secret. This trust is configured in a table (PSTRUSTNODES) and by sharing the Node Password among systems.

Typical Oracle PeopleSoft Login Flow

1. User Sign-In: The user hits the PeopleSoft sign-in page on the web server and enters credentials.
2. Credential Validation & Token Issuance: The web/application server validates the credentials (against the DB or an external directory) and then issues a PS_TOKEN cookie to the browser.
3. Session Continuity: On subsequent requests, the browser presents PS_TOKEN, and the web/application servers accept it as proof of authentication (until it expires).

Security Considerations for PS_TOKEN

For security, the PeopleSoft web domain often uses HTTPS and marks PS_TOKEN as secure. However, misconfiguration or weak Node secrets can undermine this scheme (as we’ll see in the attack vectors).

Internal Authentication Between Web and App Tiers

PeopleSoft also requires an internal authentication between the web and application server. The WebLogic web tier uses a Jolt client to talk to Tuxedo services on the app tier – this is authenticated by an internal token and passwords configured in PeopleSoft configuration files. If an attacker can intercept or replicate those, they could potentially impersonate a legitimate web server to the application server.

Public and Guest Access Risks

PeopleSoft supports public or guest user access for certain pages (for example, job listings or a “forgot password” page). These features are implemented by using a low-privilege user account that the system automatically logs in to generate a PS_TOKEN (without the end-user providing creds). This public-user token is supposed to have very limited privileges, but if misconfigured, it could inadvertently grant broader access (a fact that attackers have leveraged).

Back-End Attack Vectors and Research Findings

In 2015, security researchers presented “Oracle PeopleSoft Applications are Under Attack” at a conference, highlighting several vulnerabilities in PeopleSoft’s back-end components (database and application logic). Many of these were attack vectors that an internal or already-authenticated attacker could use, but some also applied to external threat actors. We’ll first summarize those back-end issues from the 2015 perspective, then discuss how the threat landscape evolved from 2020 onward.

Database Credential Extraction (Access ID attacks)

The PeopleSoft application server uses a special high-privilege DB account (the Access ID) to run all SQL on behalf of the application. The credentials for this account are stored in PeopleSoft’s own database (table PSACCESSPRFL) but encrypted using an older algorithm. The 2015 research noted that if an attacker has minimal access (e.g., the ability to query or read certain tables), they might retrieve the encrypted Access ID password and crack it due to weaknesses in the encryption scheme.

Furthermore, PeopleSoft uses a Connect ID (often a low-privilege database account with default username/password like people/peop1e) to initially connect to the DB and fetch the real Access ID. Many deployments had left this Connect ID at the default credentials, meaning an attacker who gains network access to the DB could simply log in with the default account. Once the Access ID password is obtained (or if the attacker already knows it due to poor practices like using the same password as the Connect ID), the attacker essentially has DBA-level control over the PeopleSoft database. This enables stealing sensitive data (personal info, salaries, etc.) or even creating a new PeopleSoft admin user directly in the database.

PeopleTools and Application Logic Weaknesses

The 2015 research pointed out that certain developer and admin utilities in PeopleSoft could be abused if an attacker gained a foothold. For instance, PeopleSoft’s Windows client tools (App Designer, Data Mover) store configurations in the registry that include encrypted passwords. An attacker with access to a developer’s machine could extract those and potentially decrypt them (at the time, encryption was thought to be a simple XOR, though Oracle later clarified it uses stronger 3DES encryption). Another vector was the Tuxedo Jolt protocol: PeopleSoft’s app server listens for Jolt connections (from the web tier or 3-tier fat clients). Some versions of this protocol did not enforce strong encryption, meaning an attacker on the network could sniff credentials or even hijack a session if they had network visibility. This is more of an internal risk (inside the corporate network), but it’s important for organizations that have multiple network segments.

Additionally, the research highlighted that default passwords and keys were a recurring problem: not only the database Connect ID, as mentioned, but also default WebLogic admin passwords, default PeopleSoft accounts (there are delivered accounts like VP1, PS, etc., which, if not disabled/changed, could be used by attackers), and default cryptographic keys. A striking example: prior to PeopleTools 8.53, the encryption key used for various PeopleSoft passwords was a static key shared by all installations. Oracle improved this in newer versions, but older environments might still use the weaker scheme.

Privilege Escalation via PeopleSoft Tools

If an attacker had a low-level PeopleSoft user account (even a self-service user), certain misconfigurations could allow escalation. For instance, the 2015 presentation noted that some organizations inadvertently gave too many privileges to the “public” user, used for things like the password reset page. If that public user could access internal components via a direct URL, an attacker could get an authenticated session without credentials.

Another example is the Report Repository feature. PeopleSoft generates reports that are accessible via a URL if you have the right token. An attacker who guesses or brute-forces report URLs (or who has a low-level account and can access a report link) might access sensitive reports they shouldn’t. While not highlighted in the 2015 talk, this type of logic flaw is a known issue if permissions are not configured carefully.

Back-End Attack Vectors Summary

In summary, the back-end attack vectors circa 2015 often assumed the attacker had some level of access (network or a basic user account) and then leveraged weak encryption, default credentials, or poor access control to deepen their penetration. The fix recommendations were straightforward: change all default passwords, use strong, unique passwords (even though PeopleSoft historically limited some passwords to 8 characters, which was another complaint in 2015), apply encryption to config files, and segment the PeopleSoft environment so that internal protocols aren’t exposed.

External Attack Vectors: From Token-Chaining to SSRF and Beyond

While the back-end issues require some initial access, PeopleSoft has also been subject to external, unauthenticated attack vectors. The 2015 research and subsequent findings show a range of ways that attackers could break into PeopleSoft from the outside, some of which are quite creative. We will discuss older methods like token chaining and SSRF, then move to more recent exploits (2020–2025), including real-world vulnerabilities and attack techniques observed.

PS_TOKEN Hijacking and Token Chaining

One of the most infamous PeopleSoft attacks is the “TokenChpoken” attack (a portmanteau of “token” and perhaps a play on chicken). This refers to cracking the PeopleSoft Node secret to forge valid PS_TOKEN cookies. As described earlier, the PS_TOKEN’s signature is essentially a SHA-1 hash of known fields plus the Node password. Researchers found that PeopleSoft’s default Node names are predictable (e.g., PSFT_HR for HR module, PSFT_FIN for Finance) and organizations often don’t change them. That means an attacker knows all parts of the token except the Node password. If the Node password is weak, they can brute-force it by computing hashes offline and comparing them to a captured PS_TOKEN value.

In 2015, it was demonstrated that 42% of internet-exposed PeopleSoft systems were vulnerable to this token attack, and even found about 10% still using the default Node password (reportedly the word “password”). With GPU acceleration, cracking a weak Node password could take less than a day.

Once the attacker obtains the Node password, they can generate a valid PS_TOKEN for any user, including the highly-privileged PS account (PeopleSoft’s default superuser). This effectively gives full application access remotely, without ever knowing a single user’s actual credentials.

Token Chaining

“Token chaining” also refers to abusing the trust between systems: If an organization has multiple PeopleSoft apps (HR, Finance, Campus, etc.), trusting each other’s tokens, a breach of one can pivot to others. For example, an attacker who cracks the token for a less sensitive system (say a PeopleSoft Campus Solutions test environment) might reuse that token to access the HR production system if they share the same Node secret – a scenario the 2015 researchers explicitly warned about.

Therefore, an external attacker might not need to directly attack the most sensitive server; compromising any PeopleSoft instance in the SSO trust circle could cascade access. Oracle’s guidance to mitigate this includes using long, random Node passwords and even using certificate-based node authentication instead of shared passwords. In practice, the TokenChpoken attack was a wake-up call, and many organizations updated their node secrets. 

However, even recent vulnerability scanners like Acunetix still flag PeopleSoft installations for “SSO weak secret key” if the Node password is guessable, indicating this remains a problem in some environments.

---

Subscribe Newsletter

Stay ahead with the latest in Rublon and top security practices. Subscribe to the Rublon Newsletter for monthly updates on product enhancements and valuable cybersecurity insights, delivered directly to your inbox.

---

PeopleSoft Integration Broker SSRF/XXE

The PeopleSoft Integration Broker (IB) is a web services framework that allows PeopleSoft to communicate with other systems (and also to let administrators configure integrations). In 2013, multiple critical vulnerabilities were found in the Integration Broker’s HTTP Gateway that allowed unauthenticated XML External Entity (XXE) attacks. Essentially, it was a form of server-side request forgery (SSRF) and file disclosure. The IB’s main servlet (often accessible at /PSIGW/PeopleSoftServiceListeningConnector on the web server) processes XML messages. Researchers discovered that by sending crafted XML, an attacker could cause PeopleSoft to attempt to fetch external resources or local files. This could be used to list directories or read certain files on the server (e.g., configuration files), even without a valid login. 

Oracle patched these XXE issues in 2013 (CVE-2013-3800 and others), but not all customers promptly applied patches. By 2015, the presentation demonstrated that some PeopleSoft sites were still vulnerable or misconfigured.

What can an attacker do with SSRF/XXE on PeopleSoft?

A classic attack chain was: send a malicious XML to the integration gateway to retrieve a config file, such as integrationGateway.properties (which often contains credentials). In fact, the integration gateway config file holds the User ID and Password for the IB administrator and potentially node definitions. If the password is encrypted, it is encrypted with a default 3DES key (unless changed by an admin), as indicated by the {V1.1} prefix on encrypted strings.

Using a known static key means an attacker who obtains that encrypted password can decrypt it. The attacker could then log in to the integration management console or reuse those credentials elsewhere. Even worse, some PeopleSoft Integration Broker setups allowed remote management actions via special URLs. The research noted that with a specially crafted URL, an external attacker could read or even overwrite the integration gateway configuration if default credentials (administrator/password) were in use.

Overwriting the config could let an attacker change the classes that the Integration Broker loads – potentially leading to remote code execution by pointing the system to malicious Java classes. This is a highly dangerous scenario, essentially turning an SSRF file-read into a full compromise of the application server.

SSRF as a Pivot into Internal Systems

It’s worth highlighting that SSRF vulnerabilities can also be leveraged to pivot deeper into a network. For instance, attackers demonstrated that PeopleSoft’s XML parser could be tricked into making HTTP requests to internal addresses (since the app server might have network access not open to the outside). Using XXE and even the older gopher:// trick, an attacker could target internal services or grab Windows SMB hashes by inducing PeopleSoft (if running on Windows) to connect to a UNC path. These advanced SSRF techniques show how an exposed PeopleSoft web service could act as a conduit to attack otherwise segregated internal systems.

Exposed Admin Interfaces and Default Accounts

WebLogic Console Access

Sometimes the easiest way in is through an unlocked front door. PeopleSoft systems historically have had a few of these “front doors” accidentally left open. One is the WebLogic console. PeopleSoft’s default web server (WebLogic) has an administrator console typically on the /console path. In single-server PeopleSoft installs, this console is accessible by default on the same port as the PeopleSoft site. If the deployer left the credentials at default (username system, password Passw0rd), an attacker could simply browse to http://<server>:<port>/console and log in to WebLogic.

From the WebLogic console, a malicious actor can deploy new applications (e.g., a WAR file with a webshell or malware) or manipulate the server configuration. This is a glaring external risk. Many security guides emphasize changing the WebLogic admin password and ideally restricting console access (e.g., binding it to localhost or a non-routable network)

Unified Navigation Vulnerability

Another example is the PeopleSoft Remote PORTAL. PeopleSoft has a feature called Unified Navigation, which allows one instance’s portal to pull content from another. A vulnerability (CVE-2018-2919) in the Unified Navigation component allowed an authenticated attacker to access data from other PeopleSoft instances without proper authorization (an access control issue). While not exactly an “unauthenticated external” vector, it means that if an attacker compromised a low-priv account in one instance, they might chain that to extract sensitive data from a different instance through the trust relationship.

Default Credentials and Demo Accounts

Other default credentials include the Integration Broker gateway user (often administrator/password as noted) and PeopleSoft’s demo user accounts. In older versions, PeopleSoft came with a demo account “VP1” with a known password. If a system went live without purging demo accounts, that’s an instant win for an attacker. In recent years, fewer such accounts exist by default, but it’s a reminder that hardening PeopleSoft (removing sample accounts, changing all default passwords) is crucial.

External Exploitation of PeopleSoft via Component Vulnerabilities

CVE-2017-10271: WebLogic Remote Code Execution

As PeopleSoft uses a stack of underlying technologies (WebLogic, Tuxedo, Oracle DB, etc.), it can inherit vulnerabilities from those. A notable case was CVE-2017-10271, a critical WebLogic Server remote code execution bug (involving unsafe deserialization) which was actively exploited in the wild at the end of 2017. Many PeopleSoft servers, being Java-based on WebLogic, were compromised via this vulnerability.

Cryptocurrency Mining Campaigns

In early 2018, security researchers observed a wave of attacks where criminals leveraged CVE-2017-10271 to install cryptocurrency miners on PeopleSoft servers. The attackers likely scanned for the PeopleSoft web ports and, upon finding a vulnerable server, executed OS commands to download mining software. One SANS ISC diary detailed how an attacker earned over $200,000 worth of Monero by enslaving vulnerable PeopleSoft/WebLogic servers across the globe. The diary noted “PeopleSoft…is difficult to patch and maintain”, implying many organizations were behind on Oracle’s patches. Indeed, logs from the attacker’s server showed over 700 unique PeopleSoft (WebLogic) servers connecting back as bots in just a few days.

This incident underscores that even if PeopleSoft itself had no exploitable bug, an underlying unpatched WebLogic provided a path in. Attackers do not necessarily distinguish. If a PeopleSoft system is exposed and it runs a middleware with a known flaw, it will be targeted.

JoltandBleed Vulnerabilities in Oracle Tuxedo

Another example is JoltandBleed (2017), which straddles the line between external and internal vector. JoltandBleed was a name given to a set of vulnerabilities in Oracle Tuxedo’s Jolt service (used by PeopleSoft’s app server). Disclosed in late 2017, these included memory leaks, buffer overflows, and authentication bypasses on the Tuxedo Jolt port (e.g., CVE-2017-10272 memory disclosure, CVE-2017-10266 Jolt authentication brute-force, and CVE-2017-10269, which allowed complete compromise of PeopleSoft).

Risks of Exposed Jolt Ports

Oracle rushed out patches for these. If the PeopleSoft app server’s Jolt port (usually port 9000/9001) had been accessible to an attacker (say, in a poorly segmented network or an exposed test environment), they could exploit JoltandBleed to dump memory (retrieving credentials in cleartext from RAM) and potentially achieve remote code execution. The good news is that in a well-designed deployment, the Jolt port is not open to the internet. However, surveys at the time found over 1,000 PeopleSoft instances on the public internet, and some percentage of those likely exposed internals that should have been firewalled. JoltandBleed highlights that internal services must be locked down because attackers are increasingly adept at lateral movement once they find any foothold.

Other Web Vulnerabilities (2020–2025)

XSS in PeopleTools Rich Text Editor

As with any web application, PeopleSoft has had its share of typical web flaws: cross-site scripting (XSS), cross-site request forgery (CSRF), and the like. For instance, in 2020, Oracle patched a PeopleTools Rich Text Editor XSS vulnerability (CVE-2020-14592) that could allow an unauthenticated attacker to trick a user into executing malicious scripts. While XSS usually requires social engineering (user interaction), it could be used to steal session tokens or perform actions as an authenticated admin user.

Portal Component and Input Validation Issues

Oracle also addressed issues like portal component vulnerabilities (CVE-2020-2751) that could be exploited via HTTP to gain unauthorized data access. Another example, CVE-2022-21345, was an input validation flaw in the PeopleTools Security module that could let a low-privilege user retrieve sensitive data via HTTP requests. These are more subtle than the big “unauthenticated RCE” type bugs, but in aggregate, they present a multitude of angles that attackers can try, especially if they already have some credentials (even a self-service user account). A medium-severity bug might be chained with another to escalate an attack.

Critical CVEs in 2025

Throughout 2020–2025, Oracle’s quarterly Critical Patch Updates (CPU) regularly include a handful of PeopleSoft-related CVEs. Many of these have been moderate severity, but a few stand out as critical. For example, in 2025, a deserialization vulnerability (CVE-2025-30748) in PeopleTools was patched, which had a CVSS score of 8.6 and could potentially allow remote code execution (deserialization flaws are often critical). Another, CVE-2025-30747, was a session fixation issue (CVSS ~7.2) targeting PeopleSoft CRM that could let an attacker hijack user sessions.

Ongoing Patch Imperative

The pattern is clear: even as Oracle strengthens the platform, researchers continue to find weaknesses, and administrators must stay current with quarterly patches.

To illustrate how these vulnerabilities and attacks have unfolded over time, the next section provides a timeline of major PeopleSoft security events from 2015 to 2025.

Timeline of Major PeopleSoft Security Vulnerabilities (2015–2026)

The decade from 2015 to 2025 saw PeopleSoft systems under persistent attack, from the initial shocking revelations of easily crackable SSO tokens, through mid-decade exploits of underlying middleware, to a steady drumbeat of vulnerabilities being patched each year. Some organizations learned the hard way (through breaches or near-misses) that ERP security cannot be neglected. The combination of complex architecture, extensive customizations, and sometimes lagging patch application has made securing PeopleSoft a challenge.

2015 – TokenChpoken & Internet Exposure

Researchers reveal the PS_TOKEN cracking attack at a security conference, estimating that almost half of PeopleSoft customers were at risk. Around the same time, incidents of data breaches via PeopleSoft came to light, particularly in higher education (e.g., a 2013 breach at Salem State University and others). Oracle issued patches in 2015 (e.g., CPU April 2015 with fixes for PeopleSoft), but many systems remain unpatched.

2017 – JoltandBleed and WebLogic RCE

Oracle Tuxedo (PeopleSoft) JoltandBleed vulnerabilities disclosed (five CVEs, including memory leak and buffer overflow), which “enable an attacker to compromise the whole PeopleSoft system.” Emergency patches were released in November 2017. Separately, October 2017’s WebLogic RCE (CVE-2017-10271) was weaponized by hackers in late 2017. By January 2018, PeopleSoft servers worldwide were being exploited via that flaw for crypto-mining. Over 700 victim IPs (including many in Oracle’s own cloud hosting) are identified in one campaign’s logs. Oracle responds with out-of-band advisories urging immediate patching.

2018 – Continued Exploitation & New Flaws

The crypto-mining wave continued into early 2018 (another group using the same WebLogic exploit mines a different cryptocurrency, AEON). Meanwhile, Oracle’s July 2018 CPU fixed an access control bug in PeopleSoft’s Unified Navigation (CVE-2018-2919), which could allow a user in one module to access data in another. PeopleSoft admins were advised to review trust settings and remove any unnecessary node trusts. Toward the end of 2018, Oracle also patched a PeopleSoft CSV injection issue (where exported Excel files could contain malicious formulas), reminding us that even non-web vulnerabilities can affect ERP data.

2019 – Emphasis on Secure Configuration

A notable vulnerability fixed in 2019 was in PeopleSoft Remote Call (CVE-2019-2586), which allowed a low-privileged user to read arbitrary data via a crafted request. While not a full compromise, it could help an attacker collect information for a targeted attack. Oracle also addressed some application server issues (CVE-2019-2594) related to unsafe serialization. In the news, a U.S. Department of Education alert warned universities to secure PeopleSoft after several schools were attacked (this follows earlier university breaches). Organizations began to more widely adopt web application firewalls and specialized ERP security tools to shield PeopleSoft.

2020 – Wave of Medium-Severity Bugs

PeopleTools 8.57 and 8.58 saw patches for XSS (CVE-2020-14592), a portal unauthenticated data leakage issue (CVE-2020-2751), and a critical Denial-of-Service vulnerability (CVE-2020-2776) that could let an unauthenticated attacker crash the PeopleSoft application via a single HTTP request. Though a DoS is not as devastating as data theft, a forced outage of an HR or financial system can still be costly. Oracle’s April and July 2020 CPUs addressed these. Security researchers noted that the PeopleSoft Campus Solutions module in particular had an XSS and a DoS issue patched in 2020.

2021 – Exploits in the Wild and CISA Alerts

In 2021, at least one U.S. university’s PeopleSoft system was breached via SQL injection, exposing a trove of student or HR data. Oracle’s CPUs in 2021 included fixes for injection flaws and further XSS issues. CISA (Cybersecurity & Infrastructure Security Agency) included an Oracle PeopleSoft vulnerability in its list of regularly exploited CVEs (though PeopleSoft was not as commonly mentioned as Exchange or VPN devices, the inclusion underscored that nation-state actors pay attention to ERP systems too). Oracle’s October 2021 advisory specifically warned that certain PeopleSoft web service APIs could be exploited if exposed, urging admins to restrict network access to integration endpoints.

2022 – Data Leak and DoS Incidents

Oracle PeopleSoft Financials received an update in 2022 to fix an input validation bug that could lead to SQL injection and data leaks. In the wild, a major U.S. bank’s PeopleSoft Financials system reportedly suffered a DoS attack in 2022. Possibly, it was an attacker exploiting a known flaw to crash the service as an extortion tactic. Oracle also patched some PeopleSoft XML Parser vulnerabilities that year, improving the platform’s resilience against XML bombs and XXE once again. CVE-2022-21344 and 21345 (addressing PeopleTools Security) were released, which prevented unauthorized access to data. Towards late 2022, an interesting bug (CVE-2022-38645) was fixed where PeopleSoft could allow malicious upload of files via its WebDAV component, reminding everyone that even lesser-used features need attention.

2023 – Privilege Escalation Flaw

In 2023, Oracle disclosed a PeopleSoft Human Capital Management (HCM) vulnerability that could allow privilege escalation within the application. While details are limited, it likely involved some access control weakness where a self-service HR user could perform an admin-only action by manipulating parameters.

2024–2025 – Latest Threats

By 2024, PeopleTools 8.60+ was in use, and Oracle introduced more security enhancements (support for TLS 1.3, stronger hashing for tokens, etc.). A session fixation issue in PeopleSoft CRM referenced in CPU Jan 2024 was patched, closing a hole where an attacker could plant a session identifier and trick a user to log in, then hijack that session.

In 2025, the critical deserialization RCE (CVE-2025-30748) in the PeopleSoft PeopleTools framework was fixed. Oracle’s July 2025 CPU release included a dozen PeopleSoft fixes, prompting French CERT (CERT-FR) to issue an advisory emphasizing the need to patch, as these could lead to data compromise, service disruption, and other risks. The continued discovery of new CVEs, despite PeopleSoft being a mature product, shows that attackers remain interested. ERP systems contain highly sensitive data, so they will always be appealing targets, and even niche vulnerabilities can be entry points for determined adversaries.

2026 – Prognoses and Emerging Risks

Looking ahead to 2026, PeopleSoft will likely face continued scrutiny from both researchers and attackers. As more organizations migrate to cloud-hosted ERP environments or hybrid setups, misconfigured integrations (especially with SAML, LDAP, and third-party APIs) may become prime targets.

We expect Oracle to strengthen token handling, session management, and audit logging in upcoming PeopleTools releases. However, legacy deployments still running older versions will remain vulnerable, especially if patching lags or default credentials persist. With attackers increasingly chaining medium-severity bugs for lateral movement, even “minor” flaws could become major entry points.

Securing Oracle PeopleSoft: Best Practices

Oracle PeopleSoft continues to be a mission-critical system for many enterprises, and its security has improved over the years thanks to proactive research and Oracle’s updates. The architecture’s layered nature means defense in depth is essential. A weakness in one layer (web server, app server, or database) can be mitigated if the other layers are properly locked down.

Based on the trends discussed, here are the best practices for safeguarding Oracle PeopleSoft:

Keep PeopleSoft Updated

• Many of the exploits (TokenChpoken, JoltandBleed, WebLogic RCE) were effective largely on unpatched systems. Oracle’s quarterly patches frequently address PeopleSoft issues, and skipping them leaves known holes open.
• Apply patches rapidly and maintain strict security hygiene. These practices are essential to defending against persistent threats.

Eliminate Default Credentials and Secrets

• Change all delivered passwords (database connect IDs, WebLogic console, Integration Broker admin, Node passwords, etc.) to strong, unique values.
• Generate new cryptographic keys for encryption using tools like pskeymanager or pscipher (so that your instance is not using the default key for config encryption).
• Regularly review accounts to ensure no unnecessary ones exist.

Restrict Access and Segment Networks

• The web-facing portion of PeopleSoft should be the only component accessible from the internet. All other communication (to app server, to DB) should be internal.
• Use firewalls to block access to Tuxedo Jolt ports, Integration Broker ports, and administrative consoles from untrusted networks.
• If possible, put PeopleSoft behind a VPN or at least a reverse proxy with multi-factor authentication. Many breaches (like the university SQLi and bank DoS) could have been blunted if the systems weren’t directly internet-facing.

Monitor and Audit

• Monitor PeopleSoft user activity and system logs for anomalies. For example, unexpected Integration Broker calls or high volumes of failed logins could indicate an attack (someone trying to brute-force a token or password).
• Watch system performance metrics for unexplained spikes.
• Configure PeopleSoft to forward authentication and portal usage logs to your SIEM platform. This enables centralized monitoring, anomaly detection, and faster incident response.

Apply Secure Configurations

• Disable or secure features not in use (e.g., if you’re not using the Integration Broker, consider turning it off or at least changing the default password and limiting its network access).
• Implement TLS for all PeopleSoft traffic. Enable PeopleSoft’s account lockout and password complexity features to deter brute force attempts.
• Integrate PeopleSoft logins with multi-factor authentication to reduce the risk from stolen credentials.

Conclusion

The evolving threat landscape from 2015 to 2025 has shown both old techniques revived (like SSRF and token forging) and new exploits emerging. By understanding how PeopleSoft components communicate and where the weak points can be, defenders can better protect these invaluable systems. PeopleSoft may not always make headlines like some other technologies, but despite its age, PeopleSoft remains massively deployed and thus remains a target. For any organization using PeopleSoft, staying vigilant on ERP security is as important as ever.