Full Report
Attackers now ready to exploit how things work, rather than just break them, says Oracle support expert
Analysis Summary
# Vulnerability: Post-Exploitation via Oracle Java Source Injection (khunt)
## CVE Details
- **CVE ID**: N/A (This is an exploitation of legitimate functionality, not a specific software bug/CVE).
- **CVSS Score**: N/A (Configuration/Design exploitation).
- **CWE**: CWE-89 (SQL Injection) as the entry point; CWE-267 (Privilege Defined by Resources) regarding database JVM access.
## Affected Systems
- **Products**: Oracle Database (incorporating Oracle JVM).
- **Versions**: All versions featuring the embedded Java Virtual Machine (JVM).
- **Configurations**: Systems where the web-facing application is vulnerable to SQL Injection and the database user has permissions to `CREATE JAVA SOURCE`.
## Vulnerability Description
This attack leverages a "living-off-the-land" technique rather than a code flaw. Attackers first use a standard SQL injection to gain access. Once inside, they utilize the Oracle Database's embedded JVM to execute `CREATE JAVA SOURCE` commands. This allows the attacker to upload, compile, and execute a custom malicious Java-based toolkit (identified as "khunt") directly within the database engine. This bypasses traditional file-system-based malware detection because the malicious code resides as a stored schema object within the database.
## Exploitation
- **Status**: Exploited in the wild (Reported by Huntress, July 2026).
- **Complexity**: Medium (Requires knowledge of Oracle-specific Java integration).
- **Attack Vector**: Network (via public-facing web applications).
## Impact
- **Confidentiality**: High (Full credential theft and data exfiltration).
- **Integrity**: High (Ability to run arbitrary code and modify database objects).
- **Availability**: High (Potential for full system takeover or service disruption).
## Remediation
### Patches
- **No specific patch**: Because this exploits built-in functionality, standard security patches (including the July 1,449-patch bundle) do not disable this capability by default.
### Workarounds
- **Disable Java Compilation**: Disable the ability to compile Java code on production servers.
- **Principle of Least Privilege**: Ensure the database user account used by the web application does *not* have `CREATE JAVA SOURCE`, `CREATE PROCEDURE`, or similar development permissions.
- **Hardening**: Restrict JVM functionality to the DBA user only.
- **Environment Management**: Only enable Java development tools during specific maintenance or development windows.
## Detection
- **Indicators of Compromise**:
- Presence of unusual Java source objects in the database schema.
- Execution of `CREATE JAVA SOURCE` or `oraexec` commands from web-tier service accounts.
- Identification of the "khunt" post-exploitation toolkit within database objects.
- **Detection methods and tools**: Monitor database audit logs for DDL (Data Definition Language) changes, specifically those related to Java objects originating from application-tier connections.
## References
- **Vendor/Researcher Post**: hxxps[://]www[.]huntress[.]com/blog/khunt-malware-sql-injection-oracle
- **News Coverage**: hxxps[://]www[.]theregister[.]com/2026/08/25/oracle_database_attack_khunt/