You could’ve applied all 1,449 Oracle patches and still been hit by this attack
Oracle's July 2026 security update included 1,449 patches, yet none would have stopped a credential-theft attack on an Oracle database server documented by security firm Huntress. The incident began with a straightforward SQL injection against a public-facing web application, but attackers then used a legitimate Oracle database feature to plant a post-exploitation toolkit, highlighting a shift towards abusing built-in functionality rather than exploiting software flaws.
The attackers fed CREATE JAVA SOURCE commands through a Tomcat connection to Oracle's embedded Java Virtual Machine, allowing malicious Java code to be compiled and stored directly as a database object, a technique known as oraexec that has rarely been seen exploited in the wild before. Craig Savage of Oracle support vendor Spinnaker Support said the ability to compile and run Java code should never be enabled on a production web server and should be restricted to database administrators, noting the breach resulted from poor configuration rather than an Oracle vulnerability. He warned that criminal groups increasingly understand and exploit legitimate product functionality, not just bugs, urging organisations to focus on basic security hygiene alongside patching.
- Oracle DB attack bypassed all 1,449 July patches via legitimate functionality
- Attackers used CREATE JAVA SOURCE to run code inside the database
- Expert says misconfiguration, not an Oracle flaw, caused the breach
New here? Start with this
Oracle databases can be used by websites to store and manage information. Some include a feature that lets Java code run inside the database, which can help with certain tasks but also gives users with the right access powerful capabilities.
In this incident, attackers first used a weakness in a public-facing web application to reach an Oracle database. They then abused its built-in Java feature to install tools that stole login details, rather than exploiting a flaw that a software patch would fix.
The case highlights the role of secure configuration and access controls alongside software updates. It also shows why organisations need to consider how legitimate features could be misused if attackers gain access.
Both sides, in good faith
The strongest fair case each way — we don't pick a winner.
The case for
This incident reflects a failure of user responsibility and security hygiene rather than a vendor problem. Oracle provides legitimate features that organisations need; responsibility lies with users to implement security best practices such as the principle of least privilege, disabling unnecessary features, and proper access controls. The shift towards exploiting legitimate functionality rather than vulnerabilities makes proper configuration discipline even more critical. No vendor can protect users from misconfiguring their own systems.
The case against
This incident reveals a systemic architectural problem. When a single SQL injection allows attackers to compile and execute arbitrary Java code within a database, the issue transcends mere misconfiguration and reflects Oracle's design allowing such dangerous capabilities to be exposed through a single vector. Vendors have responsibility to build security into product architecture by making secure configurations the default and making dangerous capabilities difficult to accidentally enable. Relying entirely on user responsibility for preventing misconfigurations has repeatedly proven insufficient in practice.