On July 27, 2026, Huntress discovered an attack that should change how you think about database security. Hackers didn't just steal data from an Oracle database, they turned the database itself into a command-and-control platform, executing system commands and harvesting credentials from inside the SQL layer.
The attack started with a SQL injection flaw in a public-facing Java application running on Apache Tomcat. Once inside, the attackers installed khunt, a post-exploitation toolkit written in Java and PL/SQL. The toolkit included components that could execute operating system commands, steal credentials, and manage files, all from within the database.
This wasn't a vulnerability in Oracle's code. It was a deliberate exploitation of Oracle's embedded Java Virtual Machine, a feature that exists in most enterprise database installations and rarely gets scrutiny during security reviews.
Attack Timeline
Initial access: SQL injection in a Java web application provided the entry point. The application connected to an Oracle database with elevated privileges.
Toolkit deployment: The attackers uploaded Java class files and PL/SQL wrapper procedures directly into the database schema. Oracle's embedded JVM executed the Java code without requiring file system access.
Post-exploitation: The khunt toolkit ran system-level commands through the database process, bypassing host-based security controls that monitor file creation or process execution. The database became a persistent foothold.
Discovery: Huntress identified the attack through anomalous database behavior, specifically, unusual Java class loading and PL/SQL procedure calls that didn't match normal application patterns.
Failed Security Controls
Input validation: The web application accepted unsanitized user input in SQL queries. The application didn't validate or parameterize queries before sending them to the database, resulting in a SQL injection vulnerability.
Least privilege: The application's database account had permissions to create Java objects and execute system commands. Application accounts shouldn't have DDL privileges or access to Oracle's Java subsystem.
Database hardening: Oracle's embedded JVM was enabled with default settings. Most teams don't disable this feature because they don't know it exists or assume it's required for normal operations. In this case, it became the attack surface.
Monitoring gaps: Traditional endpoint detection tools monitor file systems and process trees. They don't inspect what's happening inside database sessions. The attackers exploited this blind spot by keeping all malicious activity within the database process.
Network segmentation: The database accepted connections from a web application server that was directly exposed to the internet. If the database had been isolated behind additional network boundaries, the attackers would've needed to pivot through multiple systems.
Compliance Requirements
PCI DSS v4.0.1 Requirement 6.2.4 states: "Bespoke and custom software are developed securely." The requirement specifies that development processes must prevent common coding vulnerabilities, including injection flaws. If this environment processed cardholder data, the SQL injection alone is a compliance failure.
Requirement 6.4.3 adds: "For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks." A SQL injection vulnerability in a public-facing application is a direct violation.
OWASP ASVS v4.0.3 Requirement 5.3.4 requires parameterized queries or prepared statements for all database access. The application clearly didn't meet this baseline control.
NIST 800-53 Rev 5 Control AC-6 (Least Privilege) requires that users and processes operate with the minimum privileges necessary. The database account used by the web application had far more permissions than needed for normal operations.
ISO 27001 Annex A.8.3 (Configuration Management) covers secure system configuration. Leaving Oracle's JVM enabled without a business requirement represents a configuration management failure.
Lessons and Action Items
Audit database permissions now: Review every application database account. If an account can create Java objects, load classes, or execute DBMS_JAVA procedures, ask why. In most cases, the answer is "we didn't know that was there." Remove those permissions unless you have a documented business need.
Disable unused database features: Oracle's embedded JVM is one example. Your database probably has dozens of features enabled by default that you don't use: external procedure calls, XML processing, file system access through UTL_FILE. Create a whitelist of required features and disable everything else. Document your decisions.
Implement parameterized queries everywhere: This isn't new advice, but it's non-negotiable. Use prepared statements or ORM frameworks that handle parameterization automatically. If you're concatenating strings to build SQL, you have a vulnerability.
Monitor database activity differently: Your SIEM probably collects database login events and failed authentication attempts. That's not enough. You need to monitor DDL operations (CREATE, ALTER, DROP), privilege escalations, and calls to sensitive built-in packages. Set up alerts for Java class loading in production databases.
Segment your database network: Web application servers shouldn't have direct network access to production databases. Use a database proxy or application gateway that enforces query patterns and blocks administrative commands. If an application account tries to CREATE a stored procedure, the proxy should reject it before it reaches the database.
Test for SQL injection in CI/CD: Static analysis tools can catch many SQL injection patterns during code review. Dynamic testing tools should attempt injection attacks against staging environments before code reaches production. Make this part of your automated testing pipeline, not an annual penetration test finding.
The khunt attack demonstrates that databases aren't just data stores, they're execution environments with their own attack surfaces. Your database hardening checklist probably focuses on patch management and password policies. Add JVM configuration, stored procedure auditing, and privilege minimization to that list. The next attack might already be running inside your Oracle instance, waiting for you to notice.
