“Even if it had been fully patched, everything working, it still would have happened,” Craig Savage told The Register — a blunt assessment that underlines how a recent Oracle database intrusion bypassed the massive July patch cycle.
Craig Savage and Spinnaker Support: configuration over patch count
Craig Savage, cybersecurity lead at Oracle third‑party support vendor Spinnaker Support, told The Register that the incident was not an Oracle breach but rather the consequence of poor configuration and insecure defaults. Savage argued the ability to run Java inside the database “should be limited to only the DBA user” and that organisations “should disable the ability to compile code on a production server.” He said that, if compilation had been disabled, the malicious Java code “would not have been configured to compile.”
Huntress: SQL injection led to credential theft and in‑database toolkit
Security vendor Huntress reported that, in July, it was alerted to credential‑theft activity tied to an unnamed organisation's public‑facing web application. The initial vector was a “simple” SQL injection, a long‑standing class of flaw that Huntress noted can be avoided with “good info‑sec housekeeping.” After gaining access, Huntress said, the threat actor dropped a post‑exploitation toolkit called khunt by inserting Java source into the Oracle database.

This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildOracle's embedded JVM and the CREATE JAVA SOURCE technique
Huntress described a novel operational detail: because Oracle's database includes an embedded Java Virtual Machine, an attacker can submit Java source to the database and have it compiled and stored as a schema object. In this incident, the attackers “fed CREATE JAVA SOURCE commands to the Oracle database from [Java implementation] Tomcat, through the [database] connection,” Huntress said, and the Java source was compiled directly inside the database. Huntress also noted that similar functionality has been discussed historically — including a technique called oraexec — but “the use of the technique in the wild has rarely been documented.”
The 1,449 Oracle patches and what they did not stop
Oracle issued a large patch collection in late July comprising 1,449 fixes. Savage and Huntress both emphasised that applying those patches would not have prevented this particular attack. “Even if it had been fully patched, everything working, it still would have happened,” Savage said. His point: attackers are exploiting legitimate functionality that has been enabled or misconfigured, not necessarily exploiting a patched vulnerability in the database engine itself.
What this means for technologists, enterprise DBAs, and security teams
- Technologists and application teams: the incident underscores Huntress’s observation that SQL injection remains an avoidable initial vector — “simple” injection into a public‑facing web app enabled the chain that followed. Good information‑security housekeeping for web applications remains essential.
- Enterprise DBAs and system administrators: Savage recommended limiting Java execution in the database to the DBA user and disabling in‑database compilation on production servers, enabling it only during maintenance windows if necessary.
- Security teams and defenders: because the attackers used CREATE JAVA SOURCE commands via an application connection, defenders should consider monitoring for unexpected Java source creation inside databases and for post‑exploitation tool deployment patterns like the khunt toolkit documentied by Huntress.
The episode is a reminder that a long list of vendor patches — even a rollup of 1,449 fixes — does not remove the need to harden configuration and to control legitimate functionality that can be repurposed by attackers. Operators who treat patching as the full answer risk overlooking the kind of misconfiguration this incident exposed; as Huntress and Savage both point out, the threat is as often in how products are set up as in the bugs they contain.




