PeopleSoft administrators running PeopleTools 8.61 or 8.62 should apply Oracle’s June 10, 2026 Security Alert for CVE-2026-35273 immediately, isolate exposed PeopleSoft services if patching cannot happen today, and treat any internet-reachable instance active since May 27 as a potential incident response case. This is not a normal quarterly maintenance decision. Google Threat Intelligence Group and Mandiant observed exploitation before Oracle’s advisory, and that changes the burden of proof: exposed systems now have to be cleared, not merely updated.
The practical verdict is blunt. If your PeopleSoft environment is vulnerable and reachable from untrusted networks, patch now; if you cannot patch now, remove exposure and apply Oracle’s high-priority mitigations; if the system was exposed between May 27 and June 9, assume compromise is plausible until logs, endpoints, accounts, and downstream data paths say otherwise.
Oracle published its Security Alert for CVE-2026-35273 on June 10, 2026, describing a PeopleSoft PeopleTools vulnerability that is remotely exploitable without authentication and can lead to remote code execution. The affected versions Oracle named are PeopleTools 8.61 and 8.62. Oracle’s language matters because “remotely exploitable without authentication” is the phrase defenders use when they stop asking whether a user clicked something and start asking whether a server was reachable.
The more important date is not June 10. Google Threat Intelligence Group and Mandiant said they observed active exploitation between May 27 and June 9, before Oracle’s public advisory. That makes this a zero-day in the way administrators actually experience one: attackers had a head start, defenders were not knowingly choosing to delay, and the first clean maintenance window may already be too late for some organizations.
Google also said it notified more than 100 global organizations whose IP addresses correlated with potentially vulnerable endpoints. That does not prove every notified organization was breached. It does prove that this was not an academic bug sitting in a lab notebook waiting for Patch Tuesday theater.
For WindowsForum readers, the familiar comparison is not flattering. The enterprise world has recently watched similar storylines play out around Windows, SharePoint, SaaS backup platforms, and Oracle patch cycles: a high-value business system, an exploit window, public mitigations, then the slow discovery that “patched” and “clean” are different states. This PeopleSoft alert belongs in that family of events, not in the quieter pile of routine advisories.
That distinction is not an excuse to wait. It is a way to sequence the work without pretending every PeopleSoft installation has the same blast radius. A public university ERP instance, a healthcare HR portal, a contractor-accessible finance environment, and an internal-only test system do not carry identical risk even if they share the same vulnerable PeopleTools version.
The recommended path is therefore three-tiered. Patch immediately where possible. Isolate first where patching cannot happen within hours. Escalate to incident response when the system was exposed during the observed exploitation window and holds sensitive identity, HR, student, finance, payroll, or operational data.
Do not let change-control language obscure the decision. This is one of those cases where the risk of touching a production system has to be compared against the risk of leaving an unauthenticated remote-code-execution path in a live enterprise application. For affected PeopleTools 8.61 and 8.62 environments, “we need a normal CAB meeting next week” is not a security plan.
The first operational step is inventory. Confirm where PeopleTools 8.61 and 8.62 exist, which instances expose PeopleSoft services, which network zones can reach them, and which environments have copies of production data. The second step is containment. Until patching and mitigation are complete, reduce access to trusted administrative and application paths only, and remove unnecessary external reachability.
The third step is patching and mitigation. Apply Oracle’s June 10 Security Alert guidance for CVE-2026-35273 and any relevant PeopleSoft updates identified for the environment. Oracle’s June 2026 Critical Security Patch Update also lists 11 new PeopleSoft patches, with multiple vulnerabilities remotely exploitable without authentication, so this should not be treated as a single-CVE errand that ends when one package is installed.
The fourth step is validation. Confirm the patch level from the PeopleSoft side, not merely from a ticket note. Confirm that exposed endpoints changed state as intended. Confirm that monitoring is watching the right application, web, authentication, and operating-system logs after the change, because emergency patching often creates a false sense of closure.
Isolation is the correct interim move when patching cannot happen immediately. Restrict inbound access to the smallest possible set of trusted networks. Remove internet exposure. Place additional controls in front of the application if they already exist and can be safely configured. Disable or block unnecessary paths consistent with Oracle’s mitigation guidance.
The goal is not to make the vulnerable system safe forever. The goal is to shrink the attack surface while the actual fix is prepared, tested, and deployed. In a zero-day window, time bought through isolation is valuable only if it is measured in hours or very few days, not used as a substitute for remediation.
Administrators should also be careful with “internal only” as a comfort phrase. Internal networks are not magical clean rooms. If a PeopleSoft endpoint is reachable from broad corporate segments, third-party VPN access, unmanaged administrative workstations, or legacy jump hosts, then the application may still be reachable from the kinds of footholds attackers commonly obtain before moving toward high-value business systems.
If an affected PeopleTools 8.61 or 8.62 system was exposed between May 27 and June 9, the responsible question is not “Did we patch?” It is “Can we show that this system was not accessed, modified, used to execute code, or used to reach data during the exploit window?” That is a much more demanding question, and it is the one auditors, insurers, executives, and affected users will eventually ask.
The investigation should focus on evidence of abnormal access, application behavior, web requests, process activity, account use, data access, and outbound connections during and after the observed exploitation period. PeopleSoft is often wired into identity stores, databases, reporting tools, file shares, email systems, and downstream business workflows. A compromise of the application layer may therefore be a starting point rather than the whole incident.
This is where IT and security teams should resist the temptation to keep the incident too narrow. A vulnerable PeopleSoft server is the visible object. The actual risk may be stolen data, created accounts, altered configuration, exposed credentials, or lateral movement into systems that PeopleSoft can reach.
That is especially true in education, public sector, healthcare, and large enterprise environments where PeopleSoft commonly supports HR, finance, student, payroll, or administrative operations. Even when the application is not the front door to everything, it can be a map of people, roles, departments, vendors, IDs, and workflows. For extortion crews, that data has obvious value.
This is also why the phrase “data theft attacks” should change the response. A ransomware outbreak announces itself loudly. Data theft can look like a normal application doing normal application things until someone finds the wrong export, the wrong query, or the wrong outbound path.
The WindowsForum audience has seen this pattern before in the SharePoint zero-day discussions and the broader Windows zero-day coverage around state-linked exploitation. The technology changes, but the operational lesson does not: when a widely deployed enterprise platform becomes an unauthenticated remote-code-execution target, defenders should assume attackers are working faster than procurement, governance, and maintenance calendars.
Attackers do not care whether defenders organize risk by advisory title. If an exposed PeopleSoft environment has several unauthenticated remote attack surfaces available, the practical risk is cumulative. A single emergency alert may be the reason executives finally approve downtime, but the maintenance work should account for the broader PeopleSoft patch set.
This is where patch governance often fails. Security teams open a critical ticket for the famous CVE, application owners apply the minimum change to satisfy the ticket, and everyone misses the adjacent vulnerabilities because they sit in a quarterly bundle or a separate patch availability document. That is defensible only if the environment is already segmented, monitored, and under a strict remediation timeline.
The better approach is to use the emergency as leverage. If the business is already accepting risk, downtime, and validation work for CVE-2026-35273, administrators should evaluate the full June PeopleSoft patch picture at the same time. The least efficient enterprise ritual is taking repeated outages because each vulnerability was treated as if it lived alone.
Immediate patch is the correct lane for affected PeopleTools 8.61 or 8.62 systems where the patch can be applied and validated quickly. Emergency isolation is the lane for systems that cannot be patched immediately but can be removed from risky access paths now. Incident response is the lane for exposed systems active during the May 27 to June 9 exploitation window, especially those holding sensitive or regulated data.
The same system can move through all three lanes. A public-facing PeopleSoft instance may need isolation this morning, patching tonight, and forensic review tomorrow. That is not overreaction; it is a recognition that remediation and investigation answer different questions.
Executives often want a single status color. Administrators should resist giving them one unless the meaning is precise. “Patched” means the known vulnerability has been addressed. “Isolated” means access has been reduced. “No evidence of compromise” means the organization has looked in the right places and found no indicators. Those are not interchangeable.
The right Windows-side response is to identify dependencies. Which domain accounts does PeopleSoft use? Which service accounts can access databases, file shares, mail systems, or integration endpoints? Which administrators log into PeopleSoft servers or management consoles from Windows workstations? Which backup systems hold PeopleSoft data?
That dependency review is not busywork. If attackers obtained code execution in the application environment, any credential or trust path available to that environment deserves scrutiny. In practical terms, that means checking account activity, reviewing privilege, rotating secrets where warranted, and watching for unusual access from servers or accounts tied to PeopleSoft.
The related lesson from previous WindowsForum coverage of Microsoft and Oracle security events is that platform boundaries rarely match incident boundaries. The exploit may begin in an enterprise application, but the cleanup often runs through Active Directory, endpoint telemetry, backup retention, network segmentation, and executive risk decisions.
The facts available now are already enough to act. Oracle says the vulnerability can be remotely exploited without authentication and can lead to remote code execution. Google and Mandiant observed exploitation before the advisory. Google notified more than 100 organizations whose IPs correlated with potentially vulnerable endpoints. Those facts do not identify every victim, but they justify emergency handling.
The absence of public technical detail should not be misread as absence of risk. Vendors and researchers often limit exploit specifics during active exploitation to avoid making the problem worse. For defenders, that means the response must be built around exposure, patch state, and observed behavior rather than waiting for a copy-paste detection recipe.
There is also a communications lesson here. If legal, privacy, or executive teams may become involved, start documenting decisions now. Record when the environment was identified as affected or unaffected, when mitigations were applied, when patches were installed, what logs were preserved, and what evidence was reviewed. In an incident, the timeline becomes part of the control.
But the alternative is not stability. The alternative is uncontrolled discovery after a potential compromise: unexplained data access, possible extortion, forensic costs, notification questions, executive escalation, and a patch that still has to happen anyway. Emergency maintenance is painful because it is visible; compromise is worse because it can remain invisible until the attacker decides otherwise.
This is why the decision guide points so strongly toward action. Patch when you can. Isolate when you cannot. Investigate when exposure overlapped with the zero-day period. Anything softer treats the event like a bulletin when the available facts say it is a campaign.
The best-run organizations will not be the ones that pretend they avoided risk by waiting. They will be the ones that made a fast, documented decision, reduced exposure, applied Oracle’s guidance, and separated the remediation work from the compromise assessment.
Here is the short version PeopleSoft owners should be able to defend in writing:
The practical verdict is blunt. If your PeopleSoft environment is vulnerable and reachable from untrusted networks, patch now; if you cannot patch now, remove exposure and apply Oracle’s high-priority mitigations; if the system was exposed between May 27 and June 9, assume compromise is plausible until logs, endpoints, accounts, and downstream data paths say otherwise.
The Patch Window Has Already Closed for Some Victims
Oracle published its Security Alert for CVE-2026-35273 on June 10, 2026, describing a PeopleSoft PeopleTools vulnerability that is remotely exploitable without authentication and can lead to remote code execution. The affected versions Oracle named are PeopleTools 8.61 and 8.62. Oracle’s language matters because “remotely exploitable without authentication” is the phrase defenders use when they stop asking whether a user clicked something and start asking whether a server was reachable.The more important date is not June 10. Google Threat Intelligence Group and Mandiant said they observed active exploitation between May 27 and June 9, before Oracle’s public advisory. That makes this a zero-day in the way administrators actually experience one: attackers had a head start, defenders were not knowingly choosing to delay, and the first clean maintenance window may already be too late for some organizations.
Google also said it notified more than 100 global organizations whose IP addresses correlated with potentially vulnerable endpoints. That does not prove every notified organization was breached. It does prove that this was not an academic bug sitting in a lab notebook waiting for Patch Tuesday theater.
For WindowsForum readers, the familiar comparison is not flattering. The enterprise world has recently watched similar storylines play out around Windows, SharePoint, SaaS backup platforms, and Oracle patch cycles: a high-value business system, an exploit window, public mitigations, then the slow discovery that “patched” and “clean” are different states. This PeopleSoft alert belongs in that family of events, not in the quieter pile of routine advisories.
The Right First Move Depends on Exposure, Not Pride
The fastest decision framework is exposure-based. If PeopleSoft is internet-facing, reachable through a partner network, exposed through a VPN population you do not fully trust, or accessible from compromised-adjacent internal segments, treat the environment as high risk. If it is deeply segmented and reachable only from a small, monitored administrative network, the urgency is still real, but the incident assumption can be more evidence-driven.That distinction is not an excuse to wait. It is a way to sequence the work without pretending every PeopleSoft installation has the same blast radius. A public university ERP instance, a healthcare HR portal, a contractor-accessible finance environment, and an internal-only test system do not carry identical risk even if they share the same vulnerable PeopleTools version.
The recommended path is therefore three-tiered. Patch immediately where possible. Isolate first where patching cannot happen within hours. Escalate to incident response when the system was exposed during the observed exploitation window and holds sensitive identity, HR, student, finance, payroll, or operational data.
Do not let change-control language obscure the decision. This is one of those cases where the risk of touching a production system has to be compared against the risk of leaving an unauthenticated remote-code-execution path in a live enterprise application. For affected PeopleTools 8.61 and 8.62 environments, “we need a normal CAB meeting next week” is not a security plan.
Patch Now Means More Than Installing the Fix
Oracle’s alert urges immediate action with high-priority mitigations. Administrators should begin with Oracle’s official PeopleSoft security alert and the applicable PeopleSoft patch guidance for their environment, then validate the installed PeopleTools version and patch state across production, disaster recovery, staging, and forgotten development instances. The hidden danger in PeopleSoft estates is not usually the server everyone knows about; it is the old endpoint still reachable because a workflow, integration, or department portal would break if someone removed it.The first operational step is inventory. Confirm where PeopleTools 8.61 and 8.62 exist, which instances expose PeopleSoft services, which network zones can reach them, and which environments have copies of production data. The second step is containment. Until patching and mitigation are complete, reduce access to trusted administrative and application paths only, and remove unnecessary external reachability.
The third step is patching and mitigation. Apply Oracle’s June 10 Security Alert guidance for CVE-2026-35273 and any relevant PeopleSoft updates identified for the environment. Oracle’s June 2026 Critical Security Patch Update also lists 11 new PeopleSoft patches, with multiple vulnerabilities remotely exploitable without authentication, so this should not be treated as a single-CVE errand that ends when one package is installed.
The fourth step is validation. Confirm the patch level from the PeopleSoft side, not merely from a ticket note. Confirm that exposed endpoints changed state as intended. Confirm that monitoring is watching the right application, web, authentication, and operating-system logs after the change, because emergency patching often creates a false sense of closure.
Isolation Is Not Failure; It Is a Valid Emergency Control
Some PeopleSoft environments cannot be patched cleanly in an afternoon. They may support payroll, student registration, procurement, benefits, finance, or identity workflows with dependencies that have been accumulating for years. That reality does not justify leaving the application exposed while teams debate the perfect maintenance plan.Isolation is the correct interim move when patching cannot happen immediately. Restrict inbound access to the smallest possible set of trusted networks. Remove internet exposure. Place additional controls in front of the application if they already exist and can be safely configured. Disable or block unnecessary paths consistent with Oracle’s mitigation guidance.
The goal is not to make the vulnerable system safe forever. The goal is to shrink the attack surface while the actual fix is prepared, tested, and deployed. In a zero-day window, time bought through isolation is valuable only if it is measured in hours or very few days, not used as a substitute for remediation.
Administrators should also be careful with “internal only” as a comfort phrase. Internal networks are not magical clean rooms. If a PeopleSoft endpoint is reachable from broad corporate segments, third-party VPN access, unmanaged administrative workstations, or legacy jump hosts, then the application may still be reachable from the kinds of footholds attackers commonly obtain before moving toward high-value business systems.
Treat Exposure Since May 27 as a Security Event
The hardest part of this incident is psychological. Many organizations prefer to treat patching and investigation as separate tracks, with investigation triggered only by obvious evidence of compromise. CVE-2026-35273 makes that posture risky because exploitation was reportedly observed before defenders had a public advisory to act on.If an affected PeopleTools 8.61 or 8.62 system was exposed between May 27 and June 9, the responsible question is not “Did we patch?” It is “Can we show that this system was not accessed, modified, used to execute code, or used to reach data during the exploit window?” That is a much more demanding question, and it is the one auditors, insurers, executives, and affected users will eventually ask.
The investigation should focus on evidence of abnormal access, application behavior, web requests, process activity, account use, data access, and outbound connections during and after the observed exploitation period. PeopleSoft is often wired into identity stores, databases, reporting tools, file shares, email systems, and downstream business workflows. A compromise of the application layer may therefore be a starting point rather than the whole incident.
This is where IT and security teams should resist the temptation to keep the incident too narrow. A vulnerable PeopleSoft server is the visible object. The actual risk may be stolen data, created accounts, altered configuration, exposed credentials, or lateral movement into systems that PeopleSoft can reach.
PeopleSoft Is Boring Until It Becomes the Crown Jewel
PeopleSoft does not have the cultural glamour of a browser zero-day or the drama of a mass ransomware worm. It is enterprise plumbing, which is precisely why attackers care about it. Systems of record often hold the data that organizations are most embarrassed to lose and least able to rotate.That is especially true in education, public sector, healthcare, and large enterprise environments where PeopleSoft commonly supports HR, finance, student, payroll, or administrative operations. Even when the application is not the front door to everything, it can be a map of people, roles, departments, vendors, IDs, and workflows. For extortion crews, that data has obvious value.
This is also why the phrase “data theft attacks” should change the response. A ransomware outbreak announces itself loudly. Data theft can look like a normal application doing normal application things until someone finds the wrong export, the wrong query, or the wrong outbound path.
The WindowsForum audience has seen this pattern before in the SharePoint zero-day discussions and the broader Windows zero-day coverage around state-linked exploitation. The technology changes, but the operational lesson does not: when a widely deployed enterprise platform becomes an unauthenticated remote-code-execution target, defenders should assume attackers are working faster than procurement, governance, and maintenance calendars.
Oracle’s June Patch Stack Makes This Bigger Than One CVE
CVE-2026-35273 is the headline because it is the zero-day. But Oracle’s June 2026 Critical Security Patch Update also lists 11 new PeopleSoft patches, including multiple vulnerabilities remotely exploitable without authentication. That should nudge administrators away from a narrow “install the one emergency fix and go home” posture.Attackers do not care whether defenders organize risk by advisory title. If an exposed PeopleSoft environment has several unauthenticated remote attack surfaces available, the practical risk is cumulative. A single emergency alert may be the reason executives finally approve downtime, but the maintenance work should account for the broader PeopleSoft patch set.
This is where patch governance often fails. Security teams open a critical ticket for the famous CVE, application owners apply the minimum change to satisfy the ticket, and everyone misses the adjacent vulnerabilities because they sit in a quarterly bundle or a separate patch availability document. That is defensible only if the environment is already segmented, monitored, and under a strict remediation timeline.
The better approach is to use the emergency as leverage. If the business is already accepting risk, downtime, and validation work for CVE-2026-35273, administrators should evaluate the full June PeopleSoft patch picture at the same time. The least efficient enterprise ritual is taking repeated outages because each vulnerability was treated as if it lived alone.
The Decision Tree Should Be Written Before the Meeting Starts
In a live compromise window, meetings should ratify decisions rather than discover them. PeopleSoft owners can reduce confusion by classifying each environment into one of three lanes before the first executive call. The lanes are immediate patch, emergency isolation, and incident response.Immediate patch is the correct lane for affected PeopleTools 8.61 or 8.62 systems where the patch can be applied and validated quickly. Emergency isolation is the lane for systems that cannot be patched immediately but can be removed from risky access paths now. Incident response is the lane for exposed systems active during the May 27 to June 9 exploitation window, especially those holding sensitive or regulated data.
The same system can move through all three lanes. A public-facing PeopleSoft instance may need isolation this morning, patching tonight, and forensic review tomorrow. That is not overreaction; it is a recognition that remediation and investigation answer different questions.
Executives often want a single status color. Administrators should resist giving them one unless the meaning is precise. “Patched” means the known vulnerability has been addressed. “Isolated” means access has been reduced. “No evidence of compromise” means the organization has looked in the right places and found no indicators. Those are not interchangeable.
Windows Admins Should Care Even When the Server Is Not Windows
A PeopleSoft zero-day may sound like someone else’s application problem, but Windows administrators often sit close to the blast radius. Identity integration, database access, scheduled jobs, file exports, management workstations, directory groups, monitoring agents, and backup paths frequently cross the Windows estate. An attack on PeopleSoft can become a Windows problem once credentials, service accounts, or shared infrastructure enter the story.The right Windows-side response is to identify dependencies. Which domain accounts does PeopleSoft use? Which service accounts can access databases, file shares, mail systems, or integration endpoints? Which administrators log into PeopleSoft servers or management consoles from Windows workstations? Which backup systems hold PeopleSoft data?
That dependency review is not busywork. If attackers obtained code execution in the application environment, any credential or trust path available to that environment deserves scrutiny. In practical terms, that means checking account activity, reviewing privilege, rotating secrets where warranted, and watching for unusual access from servers or accounts tied to PeopleSoft.
The related lesson from previous WindowsForum coverage of Microsoft and Oracle security events is that platform boundaries rarely match incident boundaries. The exploit may begin in an enterprise application, but the cleanup often runs through Active Directory, endpoint telemetry, backup retention, network segmentation, and executive risk decisions.
Waiting for Perfect Indicators Is How Breaches Mature
One of the traps in zero-day response is the demand for certainty before action. Administrators want indicators of compromise, signatures, proof-of-concept details, screenshots, hashes, and clean yes-or-no answers. Attackers prefer that too, because it turns the defender’s need for evidence into a delay mechanism.The facts available now are already enough to act. Oracle says the vulnerability can be remotely exploited without authentication and can lead to remote code execution. Google and Mandiant observed exploitation before the advisory. Google notified more than 100 organizations whose IPs correlated with potentially vulnerable endpoints. Those facts do not identify every victim, but they justify emergency handling.
The absence of public technical detail should not be misread as absence of risk. Vendors and researchers often limit exploit specifics during active exploitation to avoid making the problem worse. For defenders, that means the response must be built around exposure, patch state, and observed behavior rather than waiting for a copy-paste detection recipe.
There is also a communications lesson here. If legal, privacy, or executive teams may become involved, start documenting decisions now. Record when the environment was identified as affected or unaffected, when mitigations were applied, when patches were installed, what logs were preserved, and what evidence was reviewed. In an incident, the timeline becomes part of the control.
The Real Choice Is Between Controlled Downtime and Uncontrolled Discovery
Every administrator knows the pain of emergency patching a business-critical ERP environment. There are brittle integrations, limited test windows, political owners, and the ever-present fear that a security fix will break payroll, admissions, procurement, reporting, or a departmental process nobody documented. Those risks are real.But the alternative is not stability. The alternative is uncontrolled discovery after a potential compromise: unexplained data access, possible extortion, forensic costs, notification questions, executive escalation, and a patch that still has to happen anyway. Emergency maintenance is painful because it is visible; compromise is worse because it can remain invisible until the attacker decides otherwise.
This is why the decision guide points so strongly toward action. Patch when you can. Isolate when you cannot. Investigate when exposure overlapped with the zero-day period. Anything softer treats the event like a bulletin when the available facts say it is a campaign.
The best-run organizations will not be the ones that pretend they avoided risk by waiting. They will be the ones that made a fast, documented decision, reduced exposure, applied Oracle’s guidance, and separated the remediation work from the compromise assessment.
The PeopleSoft Teams That Move Fastest Will Ask the Fewest Regretful Questions
Before closing the incident ticket, administrators should force the conversation down to concrete states rather than comfortable language. Affected does not mean exploited. Patched does not mean clean. Internal does not mean unreachable. Isolated does not mean remediated.Here is the short version PeopleSoft owners should be able to defend in writing:
- If PeopleTools 8.61 or 8.62 is in use, the environment should be checked against Oracle’s June 10, 2026 Security Alert for CVE-2026-35273 immediately.
- If the affected PeopleSoft system is reachable from the internet or broadly reachable from untrusted networks, it should be patched or isolated without waiting for the next routine maintenance window.
- If the system was exposed between May 27 and June 9, 2026, administrators should preserve logs and assess the environment as a potential compromise case, not merely as a missing patch.
- If patching cannot happen immediately, access should be reduced to the smallest trusted set of networks while Oracle’s mitigations and updates are prepared.
- If the organization is already performing emergency PeopleSoft maintenance, the June 2026 PeopleSoft patch set should be reviewed rather than treating CVE-2026-35273 as the only relevant risk.
- If PeopleSoft connects to Windows identity, file, database, backup, or management infrastructure, those trust paths should be included in the post-exposure review.
References
- Primary source: techcrunch.com
Oracle warns of security bug that hackers abused to breach 100+ companies | TechCrunch
The tech giant warned of a security flaw that a cybercrime gang said it's exploiting as part of a mass-hacking campaign. Google said it notified more than 100 organizations that had potentially vulnerable servers.techcrunch.com - Independent coverage: news.backbox.org
- Independent coverage: scworld.com
ShinyHunters gang targets Oracle PeopleSoft servers in data theft attacks | brief | SC Media
The ShinyHunters gang is exploiting a combination of old and zero-day vulnerabilities, referred to as a "gadget chain," to target both cloud and on-premises Oracle PeopleSoft instances.www.scworld.com - Independent coverage: csoonline.com
Oracle PeopleSoft zero‑day fuels ShinyHunters extortion spree | CSO Online
Attackers leveraged a critical unauthenticated RCE bug to breach higher‑ed institutions, deploy stealth remote access tools, and publish stolen data.www.csoonline.com
- Independent coverage: oracle.com
Oracle Security Alert Advisory - CVE-2026-35273
Oracle Security Alert Advisory - CVE-2026-35273
www.oracle.com
- Independent coverage: intecracy.com
Oracle PeopleSoft vulnerability exploited in university data breach — Intecracy Group
A critical zero-day vulnerability, CVE-2026-35273, in Oracle PeopleSoft has been exploited by the ShinyHunters group to compromise educational institutions, highlig…intecracy.com
- Independent coverage: itwire.com
Google warns of active Oracle PeopleSoft exploitation campaign linked to ShinyHunters | iTWire
Google's cybersecurity teams have uncovered an active compromise and extortion campaign targeting Oracle PeopleSoft environments, with the activity attributed to the...
itwire.com
- Independent coverage: incibe.es
Toma de control de PeopleSoft de Oracle | INCIBE-CERT | INCIBE
Bobby Gould, Lucas Miller y Minh Giang de TrendAI Zero Day Initiative y TrendAI Research han descubierwww.incibe.es
- Independent coverage: techradar.com
Oracle forced to rush out patch for zero-day exploited in attacks | TechRadar
Zero-day in Oracle E-Business Suite is being exploited in the wildwww.techradar.com - Independent coverage: reddit.com
Reddit - Please wait for verification
www.reddit.com
