Reading view

You could've applied all 1,449 Oracle patches and still been hit by this attack

In late July, Oracle released a mammoth security patch dump with 1,449 patches, in a perhaps unprecedented bad day for database admins. None of them, it turns out, would have prevented the credential theft on an Oracle database server described by security platform Huntress. “Even if it had been fully patched, everything working, it still would have happened,” said Craig Savage, cybersecurity lead at Oracle third-party support vendor Spinnaker Support, referring to the attack. In July, Huntress was alerted to credential theft activity, according to a post from the security company. The attack involved a "simple" SQL injection exploiting an unnamed organization's public-facing web app. Although SQL injections have a long history and are easy to avoid with good info-sec housekeeping, what happened next was more unusual. “After gaining initial access, the threat actor dropped a post-exploitation toolkit (called khunt) via a Java Source within an Oracle database, which is a novel aspect of this attack,” Huntress said. Because a code-object can be loaded directly in Oracle's database engine, the malicious actors were able to upload their toolkit directly into the database. “This is a technique that's previously been discussed and described over the years, including via a technique described as oraexec – however, the use of the technique in the wild has rarely been documented,” Huntress said. Oracle's database has an embedded Java Virtual Machine (JVM), and users can take Java source code and store it as a database object. “This is what attackers did during this incident: they fed CREATE JAVA SOURCE commands to the Oracle database from [Java implementation] Tomcat, through the [database] connection, and the Java source code contained within was then compiled directly inside the database as a stored schema object,” the vendor said. Speaking to The Register, Savage said: “Oracle has its own JDK. You are able to build and run Oracle Java programs within the database. It should never be something a web server can do. In fact, in a production Oracle environment, it should be locked down. It should only be re-enabled during a development or maintenance window, for example. It was poorly configured, poorly secured, but it wasn't an Oracle breach.” The ability to run Java in the database should be limited to only the DBA user, Savage argued, and users should disable the ability to compile code on a production server. “If they’d done that, it would have downloaded that Java code, and JDK would not have been configured to compile it,” he said. Savage said cybercriminals were seeking to exploit this kind of functionality more commonly, rather than simply looking to find and use vulnerabilities. “We're starting to see more and more of this: these cybercrime gangs now know about these products. They don't just know how to break them. They also know what legitimate functionality they could potentially use if it's been turned on, and that's what we saw here. That's the wake-up call. Oracle published something like 1450-ish patches. Organizations are totally focused on patch, patch, patch, but you still need to do the basics,” he said. ®

  •  

CISA slaps its tightest three-day patching deadline on perfect-10 Oracle flaw

The US Cybersecurity and Infrastructure Security Agency (CISA) just dished out another three-day deadline for patching an actively exploited vulnerability, the most urgent in its wheelhouse. The culprit: a max-severity Oracle bug affecting Windows VMs. Tracked as CVE-2026-21962 (10.0), the improper access control (CWE-284) flaw affects Oracle’s HTTP Server and WebLogic Server Proxy Plug-in. Successful attacks targeting CVE-2026-21962 can allow miscreants to create, delete, or modify access to critical data, and even gain “complete access” to all data stored on the affected systems. Oracle disclosed and provided patches for CVE-2026-21962 as part of its January 20, 2026, updates. At the time, it said versions 12.2.1.4.0, 14.1.1.0.0, and 14.1.2.0.0 were affected, and that the vulnerability could be exploited in low-complexity attacks. CISA added CVE-2026-21962 to its Known Exploited Vulnerability (KEV) catalog on August 24, giving federal civilian executive branch (FCEB) agencies three days to protect themselves against attacks – the tightest deadline it is authorized to set. Other bugs to have recently been given the three-day treatment include the critical remote code execution (RCE) flaw affecting Python scaling framework Ray. Despite being disclosed in 2025, CISA added it to the KEV catalog last week. N-able’s “god mode” vulnerability, the one that offered attackers "full administrative access to an N-central console" and was exploited as of July 31, according to the vendor, was also lumped with a three-day deadline when CISA added it to the KEV catalog on August 3. Although CISA only added Oracle’s CVE-2026-21962 to the KEV Catalog on Monday, seven months after it was first disclosed, reports from the private sector suggest attackers had the bug in their sights much earlier in the year. Vikas Kundu, cyber intelligence analyst at CloudSEK, operated a honeypot for 12 days between January 22 and February 3, shortly after CVE-2026-21962 was first disclosed and public exploit code was released. The honeypot captured attacks attempting to exploit the vulnerability, as well as other WebLogic RCE bugs dating back to 2020 and 2017. “The overall activity was characterized by high-volume, automated scanning, with tools like libredtail-http and the Nmap Scripting Engine dominating the malicious traffic,” he said. “Furthermore, the logs revealed significant background noise, including attempts to exploit non-WebLogic-specific vulnerabilities (e.g., Hikvision CVE, PHPUnit RCE, and generic command injections), indicating a broad ‘spray and pray’ approach by threat actors.” Kundu said the findings demonstrated “the critical and immediate need for organizations to prioritize patching” the vulnerability at the time. ®

  •  

Crooks push Mac malware through fake OpenAI Codex ads

Cybercrims are using fake OpenAI Codex download pages to trick Mac developers into running malware disguised as installation commands. Researchers at Cato Networks uncovered the campaign after spotting sponsored Google search results targeting people looking to download Codex for macOS. The ads direct would-be users to a convincing-looking download page hosted on Google Sites, complete with the familiar OpenAI branding. There is, however, no Codex waiting at the other end. Instead of serving up an installer, the fake site tells Mac users to open Terminal, paste in a supplied command, and run it. The instructions are dressed up as part of the installation process, but the command quietly kicks off a multi-stage malware infection. It's a variation of the increasingly popular "ClickFix" technique, in which attackers convince victims to execute malicious commands themselves rather than relying on a dodgy attachment or executable to do the dirty work. In this case, the command begins with what appears to be a legitimate npm instruction for installing Codex. Tacked onto it, however, is code that decodes a Base64-encoded URL, fetches an attacker-controlled shell script and pipes it into zsh. That script pulls down another stage, which contacts the attacker's server to report that someone has taken the bait before downloading a Mach-O executable to “/tmp/helper.” It then removes security information macOS uses to flag suspicious downloads, helping the malware dodge the usual warnings before it launches. Cato said the final binaries are universal Mach-O files, meaning they can run natively on both Intel-powered Macs and newer Apple Silicon machines. The researchers found substantial similarities between the campaign and Atomic macOS Stealer, better known as AMOS, an infostealer previously spread through fake software downloads and malicious advertising campaigns. Cato isn't quite ready to slap an AMOS label on the malware, but says plenty of fingerprints point in that direction, from how the attack is staged to how the final payload is built. The crooks have also taken steps to keep researchers from getting a good look at their handiwork. Although victims initially land on Google Sites, the malicious content itself is pulled into the page from attacker-controlled infrastructure using an iframe. That infrastructure checks details including the visitor's operating system and the path used to reach it, allowing it to show harmless-looking content when a visitor doesn't fit the profile the attackers are after. Cato said the decoy site offered both macOS and Linux download buttons, although it only observed the malware chain being delivered to Mac users. Codex isn't the only AI coding assistant getting this treatment. During its investigation, Cato found a similar ClickFix page masquerading as Anthropic's Claude Code and sharing infrastructure with the Codex campaign. The attackers don't have to work particularly hard to find their victims, either. Developers searching Google for Codex do that work for them, with sponsored ads pushing the fake download page above the legitimate results. ®

  •  
❌