SQL Injection in Oracle Escalates to SYSTEM Execution on Windows via Embedded Java Compilation
A real-world intrusion chain observed in active attacks shows how a simple SQL injection can escalate to full command execution on Windows with SYSTEM privileges. The pivot relies on Oracle Database and its built-in capability to load, compile, and execute Java inside the database engine, a powerful feature that significantly expands the attack surface when left enabled without proper controls.
The intrusion began with a basic SQL injection in an internet-facing application and progressed to command execution on a Windows server under SYSTEM rights. The critical turning point was not a new operating-system vulnerability but a legitimate Oracle Database function that allows Java source code to be loaded, compiled, and executed as part of the database's internal logic.
After obtaining database access, the attackers inserted Java source code, turned it into schema objects, and compiled it directly on the server. This post-exploitation method is particularly challenging for defenders because it reduces dependence on classic on-disk binaries and moves tooling inside the database engine, which is often monitored less rigorously than the operating system or web server.
The activity has been associated with an artifact named khunt, linked to telemetry from Huntress. The ultimate goal is to convert an application-level entry point into a pathway for executing actions on the host. When the Oracle process runs with elevated permissions on Windows, any execution chained from the database context can inherit very high privileges, up to SYSTEM, posing severe risks to the rest of the machine and its data.
The chain reinforces a well-known but frequently ignored principle: defense must start at the application layer. Remediation requires replacing string concatenation with parameterized queries and strict input validation. Database administrators should then evaluate whether Java support in Oracle is truly necessary; if not, it should be disabled or heavily restricted.
Security teams can improve visibility by monitoring specific signals inside Oracle, including statements and events such as CREATE JAVA SOURCE, CREATE JAVA CLASS, and compilation operations. Additional hardening steps include limiting users who can execute Java-related DDL, applying least-privilege principles to the application database account, and preventing the Oracle service from running with unnecessary Windows privileges.
Related articles
How Modern API Attacks Abuse Legitimate Functionality Instead of Exploiting Vulnerabilities
Traditional API incidents once centered on authorization errors, access control issues, SQL injections, and known vulnerability exploitation. Today, many attacks on APIs no longer require finding code flaws; attackers simply use documented methods, valid authorization, and correct parameters at unexpected scale or timing. NGENIX security teams observe three main behavioral patterns: Burst attacks that overload resource-heavy endpoints, Shortwave attacks that exploit race conditions through timed parallel requests, and Carpet Bombing that distributes activity across dozens of endpoints for reconnaissance or scalping. These techniques often bypass WAF because each individual request appears fully compliant with API specifications. Protection is shifting toward behavioral analysis, sliding-window rate limiting, and monitoring of overall client behavior rather than single-request signatures. Real-world cases include sudden catalog scraping during contests and mass reservation of airline seats without purchases, leading to degraded service for legitimate users.
Critical Vulnerabilities Patched in WHMCS Billing Software for Hosting Providers
WebPros International has disclosed two serious vulnerabilities in its WHMCS billing management platform used by hosting and cloud service providers. CVE-2026-67399 allows unauthenticated remote code execution through unsafe deserialization of untrusted data under specific conditions, potentially compromising the entire server environment and associated data. CVE-2026-67398 affects the 2CheckOut payment gateway module and stems from missing authorization checks, enabling attackers to retrieve sensitive customer information including names, addresses, emails, and phone numbers without authentication. HackerOne assigned CVSS v4.0 scores of 9.3 (Critical) to the first issue and 8.2 (High) to the second. WebPros released fixed versions WHMCS 9.0.8 and 8.13.7, and recommended disabling the 2CheckOut module as a temporary mitigation for the second flaw.
Cisco Releases Critical Patches for Exploited SQL Injection Flaw in Secure Email Gateway
Cisco Systems has issued security updates for Cisco Secure Email Gateway to address a critical SQL injection vulnerability tracked as CVE-2026-76461. The flaw stems from insufficient input validation during email parsing and allows unauthenticated remote attackers to execute arbitrary SQL commands. Successful exploitation can lead to root-level access on the underlying operating system, enabling full command execution. The vulnerability carries a CVSSv3.1 base score of 9.8 and is rated Critical. Cisco confirmed active exploitation of the issue in September 2026. Recommended fixes include upgrading to versions 16.5.0-780, 16.0.4-3021, or 15.5.5-0141, with strong preference given to the newest release.
Telegram Desktop HTML Export Flaw Allowed Stealthy JavaScript Injection into Chat History
Researchers at ExPatch identified a vulnerability in Telegram Desktop that enabled attackers to embed malicious JavaScript into exported HTML chat histories without user detection. The flaw stemmed from insufficient sanitization of button captions added by bots, allowing hidden scripts to execute when the HTML file was opened in a browser. Malicious messages could be forwarded into chats and remain dormant until export, potentially exfiltrating messages, sender names, and timestamps to attacker servers. The issue affected versions 4.15.1 through 6.9.3, with fixes released in beta 6.9.4 and stable version 7.0.1 on July 14. No in-the-wild exploitation was observed, though the attack required specific conditions including an unpatched export and JavaScript-enabled browser. Users are advised to re-export chats after updating or open old files with JavaScript disabled.