Tag: Security

Attackers are probing a critical Oracle E-Business Suite vulnerability that can lead to remote code execution (RCE), despite Oracle issuing a patch earlier this month. Meanwhile, new analysis indicates that an Oracle PeopleSoft zero-day exploited by ShinyHunters as early as May involves three distinct vulnerabilities that can be combined to achieve RCE. Patching alone may not remove attackers from already compromised systems, particularly if they’ve installed web shells. First up: CVE-2026-101767, a critical, unauthenticated SQL injection bug in Oracle EBS that can lead to RCE. “Our Oracle E-Business Suite decoys recorded exploratory exploits against CVE-2026-101767, an unauthenticated SQL injection in EBS’s Thin Client Framework servlet that chains to remote code execution, this morning, Oct 27,” Defused Cyber said in an X post. Horizon3 researchers found and disclosed the bug to Oracle, and the vendor patched the issue in its October release. “An attacker can send a crafted request to the vulnerable servlet to execute SQL with the privileges of the APPS database user,” Horizon3 explained at the time. “The attack chain also enables operating system command execution with the privileges of the EBS application account.” This means an unauthorized user can modify application data accessible to APPS, and execute commands. “Depending on the deployment, affected data may include financial, payroll, HR, and procurement records,” the bug hunters said. The Register reached out to Oracle with multiple questions for this story – including whether it has documented any successful exploitation of CVE-2026-101767 – and did not receive an immediate response. Moving on to the PeopleSoft-ShinyHunters fiasco: TrendAI’s Zero Day Initiative (ZDI) found and reported the PeopleSoft issues on June 10, and Oracle issued a patch under one vulnerability identifier: CVE-2026-35273. In early June, ShinyHunters told The Reg that the group hacked more than 100 organizations via an Oracle PeopleSoft zero-day, CVE-2026-35273. Google’s consulting and incident response biz, Mandiant, later confirmed the data theft and extortion crew exploited CVE-2026-35273 as a zero-day, mostly against schools and the education sector. By late September, however, Mandiant said ShinyHunters massively expanded its targeting, “deploying web shells on dozens of systems globally, spanning higher education, technology, IT services, healthcare, agriculture, transportation, and government.” According to ZDI bug hunter Bobby Gould, there are actually three distinct vulnerabilities across multiple PeopleSoft components, and each should receive its own CVE identifier rather than being grouped under CVE-2026-35273. Gould, along with TrendAI researchers Minh Giang and Lucas Miller, originally found and reported three distinct bugs to Oracle in June. “We are coordinating with Oracle to assign separate CVEs for each issue,” he said in a Tuesday blog. The first issue is a Server-Side Request Forgery (SSRF) vulnerability in the PeopleSoft Integration Gateway (PSIGW), which gives attackers a foothold in the PeopleSoft application. In June, Oracle introduced a “validateClient” method to allow PeopleSoft system administrators to restrict access to certain functionality. The SSRF bug, however, allows crims to make requests that satisfy the validation requirement to access endpoints vulnerable to RCE, Gould wrote. “While this solution does restrict access, an attacker on any trusted host can still reach PSEMHUB,” he said, referring to PeopleSoft Environment Management Hub (PSEMHUB). “Because Oracle allows localhost by default, the PSIGW SSRF provides exactly that access.” The second bug is an external control of file path vulnerability in PSEMHUB’s ExecuteProcessActivityCommand handler. This message handler is designed to allow remote clients to write log entries to the PeopleSoft server’s filesystem – but it doesn’t properly validate requests, which allows an attacker to write a web shell into a file path and achieve RCE. The third vulnerability, also in PSEMHUB, is a deserialization of untrusted data flaw. An attacker can use a file-write vulnerability to plant a malicious XML file inside a PeopleSoft directory that stores environment configuration data, then wait for PSEMHUB to initialize, such as after a service or system restart. This triggers deserialization of the malicious XML file, potentially allowing the attacker to achieve RCE. “Attackers can combine these vulnerabilities to compromise affected instances of PeopleSoft,” Gould warned.®

Source: The Register — Security · 2026-10-28

Attackers are probing a critical Oracle E-Business Suite vulnerability that can lead to remote code execution (RCE), despite Oracle issuing a patch earlier this month. Meanwhile, new analysis indicates that an Oracle PeopleSoft zero-day exploited by ShinyHunters as early as May involves three distinct vulnerabilities that can be combined to achieve RCE. Patching alone may not remove attackers from already compromised systems, particularly if they’ve installed web shells. First up: CVE-2026-101767, a critical, unauthenticated SQL injection bug in Oracle EBS that can lead to RCE. “Our Oracle E-Business Suite decoys recorded exploratory exploits against CVE-2026-101767, an unauthenticated SQL injection in EBS’s Thin Client Framework servlet that chains to remote code execution, this morning, Oct 27,” Defused Cyber said in an X post. Horizon3 researchers found and disclosed the bug to Oracle, and the vendor patched the issue in its October release. “An attacker can send a crafted request to the vulnerable servlet to execute SQL with the privileges of the APPS database user,” Horizon3 explained at the time. “The attack chain also enables operating system command execution with the privileges of the EBS application account.” This means an unauthorized user can modify application data accessible to APPS, and execute commands. “Depending on the deployment, affected data may include financial, payroll, HR, and procurement records,” the bug hunters said. The Register reached out to Oracle with multiple questions for this story – including whether it has documented any successful exploitation of CVE-2026-101767 – and did not receive an immediate response. Moving on to the PeopleSoft-ShinyHunters fiasco: TrendAI’s Zero Day Initiative (ZDI) found and reported the PeopleSoft issues on June 10, and Oracle issued a patch under one vulnerability identifier: CVE-2026-35273. In early June, ShinyHunters told The Reg that the group hacked more than 100 organizations via an Oracle PeopleSoft zero-day, CVE-2026-35273. Google’s consulting and incident response biz, Mandiant, later confirmed the data theft and extortion crew exploited CVE-2026-35273 as a zero-day, mostly against schools and the education sector. By late September, however, Mandiant said ShinyHunters massively expanded its targeting, “deploying web shells on dozens of systems globally, spanning higher education, technology, IT services, healthcare, agriculture, transportation, and government.” According to ZDI bug hunter Bobby Gould, there are actually three distinct vulnerabilities across multiple PeopleSoft components, and each should receive its own CVE identifier rather than being grouped under CVE-2026-35273. Gould, along with TrendAI researchers Minh Giang and Lucas Miller, originally found and reported three distinct bugs to Oracle in June. “We are coordinating with Oracle to assign separate CVEs for each issue,” he said in a Tuesday blog. The first issue is a Server-Side Request Forgery (SSRF) vulnerability in the PeopleSoft Integration Gateway (PSIGW), which gives attackers a foothold in the PeopleSoft application. In June, Oracle introduced a “validateClient” method to allow PeopleSoft system administrators to restrict access to certain functionality. The SSRF bug, however, allows crims to make requests that satisfy the validation requirement to access endpoints vulnerable to RCE, Gould wrote. “While this solution does restrict access, an attacker on any trusted host can still reach PSEMHUB,” he said, referring to PeopleSoft Environment Management Hub (PSEMHUB). “Because Oracle allows localhost by default, the PSIGW SSRF provides exactly that access.” The second bug is an external control of file path vulnerability in PSEMHUB’s ExecuteProcessActivityCommand handler. This message handler is designed to allow remote clients to write log entries to the PeopleSoft server’s filesystem – but it doesn’t properly validate requests, which allows an attacker to write a web shell into a file path and achieve RCE. The third vulnerability, also in PSEMHUB, is a deserialization of untrusted data flaw. An attacker can use a file-write vulnerability to plant a malicious XML file inside a PeopleSoft directory that stores environment configuration data, then wait for PSEMHUB to initialize, such as after a service or system restart. This triggers deserialization of the malicious XML file, potentially allowing the attacker to achieve RCE. “Attackers can combine these vulnerabilities to compromise affected instances of PeopleSoft,” Gould warned.®

Source: The Register Security · 2026-10-28

Cisco has open sourced a behavior detection engine that watches AI agents, to help security teams prevent rogue agents from going off the rails like they did with the Hugging Face hack – or worse. It’s called Project Quarry, and it aims to provide a “shared language” for evaluating agent behavior, along the lines of what Snort, which Cisco also maintains, did for detecting malicious network traffic and what YARA did for rule-based malware identification. Most detection tools rely on specific interactions with an AI model or agent. Did it attempt prompt injection? Or did the agent call an attack tool? “But what is missing is the entire context under which something may occur,” Amy Chang, head of AI threat and security research at Cisco, said in an exclusive interview with The Register. She likened this to credit card fraud detection. Without context, individual transactions such as a small test charge or a single purchase in a location far away from a card-holder’s usual location may not raise any flags. “And then you try again,” making another fraudulent purchase, “and that went through, too. So now I’m gonna buy the PS5,” Chang said. “Those are the things that Quarry addresses by taking into consideration the entire agent session,” she explained. “One tool call may seem in-scope until you realize that that next step is taking that information and sending it to an attacker-controlled inbox or server.” Even data theft is a sequence and not a single agentic action. Agentic AI security firm Invariant Labs demonstrated this with a proof-of-concept attack against GitHub’s MCP server that hijacked a user’s agent via a malicious GitHub Issue, and coerced it into leaking data from private repositories. Simply reading a configuration file, or sending a request to an external endpoint may be legitimate agentic actions. However, combining the two can lead to data exfiltration – and shows “why action relationships matter,” wrote Chang and fellow Cisco researchers Adam Swanda, Ravikumar Balakrishnan, and Konstantin Berlin in a blog post about Quarry shared with The Register ahead of publication “A policy can produce a finding when the trace shows a sensitive file read followed within a defined window by an external send,” they wrote. “The risk comes from the relationship between the two actions, so the finding should preserve evidence from both.” Quarry covers single- and multi-turn large language model conversations, agents, tool use, Model Context Protocol (MCP) interactions, and multimodal inputs. In addition to the open source code itself, the project’s GitHub repository includes installation instructions, supported Python versions, plugins for Claude Code, Codex and other MCP-compatible agents, configuration examples, rule-writing guidance, and a rule starter pack. For instance, with the rule pack, “If a base-64 encoded malware is somewhere in the tool call, that would result in a block,” Chang said. The rule format looks similar to a YARA or Snort rule, with a header that details the traffic to examine, content to match, and metadata for tracking the rule. Here’s a Quarry rule that flags an agent that reads a credentials file: While the Cisco Ai researchers have not run Quarry against data describing the OpenAI-Hugging Face incident, they suggest that if the intrusion had been read as a complete, step-by-step record of a single session, there were several points where the AI agents’ steps would have given a Quarry rule something to act on and flag for humans. For example, Quarry would probably have flagged internet access from a sandbox. “The rule can flag specific tool calls that reach an external server asset that wasn’t in the task’s allow list,” Chang said. “Another one would be credentials found and used somewhere else.” According to OpenAI’s technical report about the Hugging Face intrusion, this is exactly what happened on July 10, when an agent validated 14 exposed Hugging Face tokens with write access and shared them. “The rule would flag that there was a credential in the tool result that then called an outside service, which is likely not within the parameters of what you would want to do in this case,” Chang said. “We don’t want you to go and search for credentials that may have been leaked or inadvertently exposed and then utilize them to conduct a task.” The Cisco team is quick to say that rules along are not a substitute for chain-of-thought monitors, or other forms of human oversight – but they do help record a pattern that other teams can then “review, test, and apply to their own agents,” they wrote. Herein also lies the benefit of open source, and a collective approach to defending against adversarial use of AI, Chang said. “Do we have all the answers? No,” Chang said. “We all see slices of the problem, and it’s important for us to share what we see.”®

Source: The Register Security · 2026-10-28

Cisco has open sourced a behavior detection engine that watches AI agents, to help security teams prevent rogue agents from going off the rails like they did with the Hugging Face hack – or worse. It’s called Project Quarry, and it aims to provide a “shared language” for evaluating agent behavior, along the lines of what Snort, which Cisco also maintains, did for detecting malicious network traffic and what YARA did for rule-based malware identification. Most detection tools rely on specific interactions with an AI model or agent. Did it attempt prompt injection? Or did the agent call an attack tool? “But what is missing is the entire context under which something may occur,” Amy Chang, head of AI threat and security research at Cisco, said in an exclusive interview with The Register. She likened this to credit card fraud detection. Without context, individual transactions such as a small test charge or a single purchase in a location far away from a card-holder’s usual location may not raise any flags. “And then you try again,” making another fraudulent purchase, “and that went through, too. So now I’m gonna buy the PS5,” Chang said. “Those are the things that Quarry addresses by taking into consideration the entire agent session,” she explained. “One tool call may seem in-scope until you realize that that next step is taking that information and sending it to an attacker-controlled inbox or server.” Even data theft is a sequence and not a single agentic action. Agentic AI security firm Invariant Labs demonstrated this with a proof-of-concept attack against GitHub’s MCP server that hijacked a user’s agent via a malicious GitHub Issue, and coerced it into leaking data from private repositories. Simply reading a configuration file, or sending a request to an external endpoint may be legitimate agentic actions. However, combining the two can lead to data exfiltration – and shows “why action relationships matter,” wrote Chang and fellow Cisco researchers Adam Swanda, Ravikumar Balakrishnan, and Konstantin Berlin in a blog post about Quarry shared with The Register ahead of publication “A policy can produce a finding when the trace shows a sensitive file read followed within a defined window by an external send,” they wrote. “The risk comes from the relationship between the two actions, so the finding should preserve evidence from both.” Quarry covers single- and multi-turn large language model conversations, agents, tool use, Model Context Protocol (MCP) interactions, and multimodal inputs. In addition to the open source code itself, the project’s GitHub repository includes installation instructions, supported Python versions, plugins for Claude Code, Codex and other MCP-compatible agents, configuration examples, rule-writing guidance, and a rule starter pack. For instance, with the rule pack, “If a base-64 encoded malware is somewhere in the tool call, that would result in a block,” Chang said. The rule format looks similar to a YARA or Snort rule, with a header that details the traffic to examine, content to match, and metadata for tracking the rule. Here’s a Quarry rule that flags an agent that reads a credentials file: While the Cisco Ai researchers have not run Quarry against data describing the OpenAI-Hugging Face incident, they suggest that if the intrusion had been read as a complete, step-by-step record of a single session, there were several points where the AI agents’ steps would have given a Quarry rule something to act on and flag for humans. For example, Quarry would probably have flagged internet access from a sandbox. “The rule can flag specific tool calls that reach an external server asset that wasn’t in the task’s allow list,” Chang said. “Another one would be credentials found and used somewhere else.” According to OpenAI’s technical report about the Hugging Face intrusion, this is exactly what happened on July 10, when an agent validated 14 exposed Hugging Face tokens with write access and shared them. “The rule would flag that there was a credential in the tool result that then called an outside service, which is likely not within the parameters of what you would want to do in this case,” Chang said. “We don’t want you to go and search for credentials that may have been leaked or inadvertently exposed and then utilize them to conduct a task.” The Cisco team is quick to say that rules along are not a substitute for chain-of-thought monitors, or other forms of human oversight – but they do help record a pattern that other teams can then “review, test, and apply to their own agents,” they wrote. Herein also lies the benefit of open source, and a collective approach to defending against adversarial use of AI, Chang said. “Do we have all the answers? No,” Chang said. “We all see slices of the problem, and it’s important for us to share what we see.”®

Source: The Register — Security · 2026-10-28

An autonomous AI agent discovered four vulnerabilities in the decades-old, widely used EPICS (Experimental Physics and Industrial Control System) open source software toolkit, including a critical flaw that could allow remote attackers to execute code on systems used to control particle accelerators and fusion experiments. The bugs include a critical, 9.8-rated under CVSS v3.1 integer overflow vulnerability (CVE-2026-114595), leading to an attacker-controlled out-of-bounds heap write and potentially remote code execution; an 8.2-rated, high-severity, improper message-length validation flaw (CVE-2026-114596), causing an out-of-bounds memory write and controller-process crash; a 7.5-rated, high-severity insufficient bounds checking bug (CVE-2026-114597) that allows out-of-bounds memory reads and process crashes; and a 7.5-rated, high-severity type confusion flaw (CVE-2026-114598) that can lead to denial of service and could expose adjacent memory contents. All four affect EPICS Base, which is used to operate some of the world’s largest scientific research projects and facilities, and organizations should update to version 7.0.11, which includes the fixes. “Successful exploitation of these vulnerabilities could allow an attacker to cause a denial-of-service condition, corrupt memory, disclose sensitive information, or potentially execute arbitrary code,” the US Cybersecurity and Infrastructure Security Agency (CISA) warned in a Tuesday advisory. An AI agent called Cipher independently found all four previously unknown security holes – investigating and testing the unfamiliar EPICS system, and validating the four exploits – in three hours and 49 minutes, Causal Security co-founder Shubham Raj told The Register. “The initial investigation required no human intervention, followed by one instruction authorizing deeper exploitability testing in a secure environment,” Raj said. Earlier this year, Causal Security’s Cipher, which Raj described as “a fully autonomous super hacker that can reason across the technology stack,” found multiple critical attack paths in power-grid systems used across North America and Europe, prompting an October 8 security advisory from CISA. EPICS, originally developed by Los Alamos National Laboratory and Argonne National Laboratory, is used to build and remotely control distributed Supervisory Control and Data Acquisition (SCADA) systems, connecting operators to physical devices. It’s used in around 90 major scientific, university, and industrial projects and facilities globally including Argonne National Laboratory’s Advanced Photon Source and ITER’s fusion reactor control system. All four of these flaws illustrate how AI agents are really good at finding vulnerabilities in industrial and operational technologies – systems and equipment that used to be able to rely on obscurity to protect them from hackers – and add to defenders’ concerns that it’s only a matter of time until an autonomous cyberattack shuts down critical services, like power grids or water systems. These are the types of digital intrusions that can cause physical harm. Raj points to CVE-2026-114595, the critical integer-overflow vulnerability, as an example. “It allows attacker-controlled network data to cause an out-of-bounds heap memory write, with potential for remote code execution,” he told us. “EPICS controllers sit between operators and physical equipment, handling measurements, commands, and control functions,” he continued. “Operationally: Imagine a particle accelerator in the middle of an expensive experiment. An attacker could potentially crash a controller, interrupt critical measurements or control functions, and force operators to halt the experiment. That could mean lost experimental work, significant downtime, and expensive recovery.” Plus, if an attacker was able to develop an RCE exploit, this could allow them to “take control of the affected process, manipulate readings, interfere with control functions, or disrupt the equipment connected to it,” Raj said. The prerequisite for exploiting these vulns in a real scientific facility is being able to reach the vulnerable EPICS services on a facility’s control network. But this could occur if the networks weren’t sufficiently segmented, or another system had access to the vulnerable EPICS network. “Once an attacker is able to find a network, which is either misconfigured or they are able to reach, it’s pretty easy to carry out the attacks,” Raj said, adding that exploitation wouldn’t require deep OT knowledge, or understanding of how particle accelerators or fusion reactors work. “Someone with conventional exploitation skills could investigate them, and increasingly capable AI systems could help develop exploits without requiring specialized OT expertise.” Manipulating specific physical processes does require additional knowledge, he added. “But an attacker doesn’t need to understand the physics of a particle accelerator to disrupt the software controlling it. Crashing critical processes or interrupting monitoring and control can already have serious operational consequences. What’s changing is that attackers may no longer need years of specialized expertise just to discover these weaknesses.” ®

Source: The Register — Security · 2026-10-27