You could've applied all 1,449 Oracle patches and still been hit by this attack
- ID
- 17741
- Status
- summarized
- Published
- 26 Aug 2026, 12:09 AM
- Fetched
- 26 Aug 2026, 1:53 AM
- Provider
- The Register
- Category
- technology
- Original URL
- https://www.theregister.com/security/2026/08/25/you-couldve-applied-all-1449-oracle-patches-and-still-been-hit-by-this-attack/5292335
- Source URL
- https://www.theregister.com/headlines.atom
Summary
- Score
- 5.5
- Created
- 26 Aug 2026, 1:56 AM
- Tags
- Audience
- developersdatabase_learners
What happened
Huntress documented an Oracle database attack where applying all 1,449 patches from Oracle's July 2026 Critical Patch Update would not have prevented credential theft. The attackers used SQL injection on a public-facing web app for initial access, then loaded a post-exploitation toolkit called 'khunt' directly into the Oracle database engine via CREATE JAVA SOURCE commands, exploiting Oracle's embedded JVM to compile and store malicious Java code as a schema object.
Why it matters
If you run Oracle databases with the embedded JVM enabled, patching alone is insufficient — you need to audit who has CREATE JAVA SOURCE privileges and whether that capability can be disabled or restricted on production systems. The attack path (SQL injection → Java source loaded into DB engine) means web-app input validation and least-privilege DB roles matter more than patch cadence for this class of threat.
Discussion angle
How many teams running Oracle actually know whether CREATE JAVA SOURCE is enabled and who holds that privilege — and does this attack pattern generalize to other databases with embedded runtimes?