Oracle shipped 1,449 security patches in late July, but The Register reports that none of them would have stopped a credential-theft incident later described by Huntress. The distinction matters: this was not presented as an attack that depended on an unpatched Oracle vulnerability, but one that used existing application and database behavior after initial access. According to The Register, Huntress was alerted in July to credential-theft activity at an unnamed organization. The initial entry point was described as a “simple” SQL injection against a public-facing web application — a long-known class of flaw that security teams typically try to prevent through basic secure-coding and application-security controls. The more unusual part came after access was obtained. The Register, citing Huntress, says the attacker dropped a post-exploitation toolkit called khunt through a Java Source inside an Oracle database. That let the attacker place code directly into the database environment rather than relying only on a conventional file drop on the host. The mechanism described is specific to how Oracle databases can run Java. Oracle’s database includes an embedded Java Virtual Machine, and Java source code can be stored as a database object. In this incident, The Register says the attacker sent CREATE JAVA SOURCE commands from Tomcat through the database connection, and the Java source was compiled inside the database as a stored schema object. Huntress characterized the technique as novel in this incident, while also noting that the underlying idea has been discussed before, including through a technique known as oraexec. The difference, according to the report, is that use of this method in the wild has rarely been documented. Craig Savage, cybersecurity lead at Oracle third-party support vendor Spinnaker Support, told The Register that a fully patched environment would still have been vulnerable to the described path. That does not make patching irrelevant; it means the control failure described here sat outside the July Oracle patch set and closer to application exposure, database permissions, and the ability to create and execute code objects inside the database. For operators, the narrow lesson is that patch completeness is not the same thing as attack-path closure. If a public-facing application can pass unsafe input into a database, and if the connected database account has enough rights to create Java source objects, a patched server may still give an attacker useful post-exploitation options. Who benefits: Security teams get a concrete detection and hardening lead: review public-facing app inputs, database account privileges, and the use of Java objects inside Oracle databases. Attackers benefit when database connections have more capabilities than the application actually needs. Who's exposed: Organizations running Oracle databases behind public-facing web applications are exposed if SQL injection remains possible and database users can create Java source objects. The provided reporting does not identify the victim or quantify how widespread the activity is.