When the Database Becomes the Weapon

On July 27, security researchers at Huntress noticed something odd. Credential theft alerts fired on a host running an Oracle database server. Digging deeper, they found a post-exploitation toolkit — compiled and stored not as a file on disk, but as schema objects inside the database itself.

That location matters. It’s a blind spot for most endpoint security tools, which typically scan processes, binaries, and files. Java classes and PL/SQL wrappers sitting inside an Oracle instance? Usually invisible.

The entry point was a SQL injection flaw in the autocomplete search feature of a public-facing Java application running on Apache Tomcat. No vulnerability in Oracle itself — just unvalidated input passed over a JDBC connection using an account with permissions to create Java objects.

How the Oracle Database Toolkit Works

Oracle ships with an embedded Java Virtual Machine (JVM) and a statement that stores Java source code as a database object. The attacker fed malicious code through the injection point, and Oracle compiled it into stored schema objects.

They named the toolkit khunt, following a naming convention that ran through its module names and the files it wrote to disk. The components included:

• A module that opened a Windows command shell for arbitrary OS commands
• A credential dumper that read Oracle’s internal user table and wrote usernames and passwords to a file
• Two file explorers for navigating the filesystem
• An unzip utility
• A reachability check to confirm the toolkit was live
• PL/SQL wrappers to call the underlying Java methods

The technique isn’t new — Huntress noted documented cases in the wild are rare, but the concept has been known for years. What’s novel here is the execution.

Pivoting from Database to Operating System

After establishing a foothold, the attacker opened a Windows command shell and confirmed SYSTEM-level privileges. Then came PowerShell. They invoked the Windows registry tool to copy the SECURITY and SYSTEM hives, enumerated running services, and used the Extensible Storage Engine utility to copy the SAM and SECURITY hives.

Huntress assessed the hives were staged for credential dumping and probable exfiltration — though they described it as an attempt rather than confirmed theft. Apache access logs traced the requests back to a single IP address.

Why Endpoint Tools Miss It

Here’s the crux: storing the toolkit as a database object rather than a file or memory-resident payload puts it outside the scope of most security tooling. Endpoint products focus on processes, binaries, and files. They don’t inspect Java classes and PL/SQL wrappers inside Oracle.

That turns the database from something attackers query for data into a foothold they can operate from. It’s a subtle but significant shift in how we think about database security.

Related reading: Oracle WebLogic RCE attacks show how quickly attackers weaponize critical vulnerabilities. And if you’re wondering about SQL injection prevention best practices, the basics still apply.

Mitigation: It’s Not About the Database Alone

Huntress offered straightforward advice in their analysis: “To avoid these types of attacks, it’s important to ensure the forms aren’t injectable. Practice proper input sanitization and query parameterization for any inputs. It’s also important to ensure that users with the ability to execute queries aren’t overprovisioned.”

That means:

• Validate and parameterize all inputs at the application layer
• Restrict database accounts to the minimum privileges needed
• Monitor for unusual JDBC activity or Java object creation
• Consider extending visibility beyond traditional endpoint tools to include database-level auditing

The attack was detected because of credential theft alerts — not because the toolkit itself was spotted. That’s a lesson in layered defenses. Endpoint tools are necessary, but they’re not sufficient when attackers find creative hiding spots.

As databases become more capable — with embedded JVMs and procedural languages — they also become more attractive as attack platforms. The Oracle database toolkit is a reminder that security teams need to think beyond the file system.

Paperclip AI Flaws Open Door to Unauthenticated Command Execution

Three vulnerabilities in the open-source AI orchestration platform Paperclip have left servers and developers’ machines exposed to unauthenticated command execution. Two of the flaws carry critical ratings, and one holds a perfect CVSS score of 10.0. Researchers at Oasis Security published their findings on August 4, revealing how attackers could exploit these weaknesses to run arbitrary commands and access sensitive data.

The flaws affect Paperclip, a control plane designed for operating what its developers call zero-human companies. Oasis Security uncovered all three bugs during an assessment of the platform’s authenticated and local deployment modes. The disclosure follows a string of similar incidents, including a critical Flowise flaw and a Langflow bug exploited within 20 hours of disclosure.

From Self-Registration to Code Execution: CVE-2026-41679

The most severe vulnerability, CVE-2026-41679 (CVSS 10.0), affects authenticated deployments. Paperclip allowed self-registration without email verification. Its CLI authorization flow let a new user approve their own credential challenge, turning that account into a persistent board-level API key. No separate approver was needed.

That key could then reach the company import route. Paperclip restricted direct company creation to instance administrators, but the equivalent import path checked only for board-level access. An attacker could use this to introduce a bundle containing an agent configured with the process adapter—a legitimate feature that launches a specified command as a child process. Waking that agent ran the attacker’s command with the server’s operating-system privileges.

Second Flaw: Missing Access Checks (GHSA-xfqj-r5qw-8g4j)

A second finding, GHSA-xfqj-r5qw-8g4j (CVSS 8.3), covered several routes that omitted access checks entirely. These exposed heartbeat data, agent documentation, and health information. While less severe than the command execution flaw, this still leaked sensitive operational details to unauthenticated attackers.

A Developer’s Browser as an Attack Path: DNS Rebinding Flaw

The third vulnerability, GHSA-x8hx-rhr2-9rf7 (CVSS 9.6), reached the same execution sink from the opposite direction. Paperclip’s local development mode binds to loopback and treats every request as an implicit instance administrator. That assumption holds for local clients but not for browsers.

DNS rebinding let an attacker-controlled webpage cross that boundary. Once the attacker’s server became unreachable, the browser retried the hostname against loopback while still treating the connection as same-origin. Paperclip accepted the rebound requests as administrator actions. The page then imported and woke a malicious agent, executing commands on the developer’s machine.

Industry Reaction: A Systemic Failure in Identity Boundaries

Darren Guccione, CEO at Keeper Security, called the findings “a systemic failure in how AI agent control planes handle identity boundaries.” An attacker controlling an agent configuration does not merely reach data, he said, but can direct privileged action across every system that agent touches. This highlights the growing risk as AI agents gain more access to enterprise systems.

Patches Released: What You Need to Do

All three vulnerabilities were patched after disclosure. The two authenticated-mode findings were fixed in Paperclip 2026.416.0, which now requires instance administrator privileges for new-company imports. The rebinding flaw was addressed in version 0.3.1, which enables hostname validation in local mode.

If you’re running Paperclip, update immediately:

• For authenticated deployments, upgrade to version 2026.416.0 or later.
• For local development mode, upgrade to version 0.3.1 or later.
• Review your existing agents and imports for any suspicious bundles.
• Check logs for unexpected command executions or agent activations.

The rapid exploitation of similar AI platform flaws underscores the urgency. Attackers are actively scanning for vulnerable AI orchestration tools. The AI agent security landscape is evolving fast, and patching is only the first step. Organizations should also audit their identity boundaries and access controls across all AI-related infrastructure.

Malicious Packages Hit the Open VSX Registry

Counterfeit extensions that copied the names of legitimate developer tools were discovered on the Open VSX registry. Roughly a quarter of them were quietly harvesting the git and continuous integration identity of anyone who ran them.

Security firm Manifold Security published its findings on August 4. The team flagged 77 packages that appeared between July 26 and August 1. Each one republished the name and namespace of a real extension from an account that had zero ownership rights to it.

Every single package beaconed to one domain. That domain was registered just 11 days before the first malicious package surfaced.

What the Payload Actually Collected

Most of the packages were light on data. They sent little more than a hostname. But the squatted namespaces tell a story of their own. The list included AMD, LEGO Education, Hyperledger, Azure, Artsy, Salesforce OSS, a US federal agency, and marketplace.visualstudio — a name that impersonated the marketplace itself.

The other 19 packages carried a much heavier payload. Seconds after activation, they sent the hostname, the operating system username, editor details, and the machine ID. Then things got more serious.

The malicious code read the repository currently open in the editor. It pulled the git remote host and organization, the commit email domain, the branch, and the HEAD commit. It also grabbed continuous integration values, including the GitHub repository name, GitLab project path, and Codespace name.

“On a build runner or a cloud development environment, that is the full private repository name, not just the organization,” Manifold explained.

The Disclosure Was the Disguise

Here’s the twist. The listings actually disclosed what they were doing.

Each one carried a “Telemetry” section that enumerated most of those fields accurately. The disclosure also included assurances that no source code, credentials, or tokens were taken. Manifold checked those claims against the code and found they held up.

Almost all of them, anyway.

One listing stated that continuous integration data covered marker names only and never values. The code, however, sent both. The single most sensitive field in the payload was the one the disclosure explicitly said was not being sent.

These extensions had no other real function. A status bar item rendered a checkmark. One command displayed a message box. Then the beacon fired.

Built to Outlive the Takedown

The collector domain was registered through a registrar that redacts registrant details. The registration term was three years. The code treated any HTTP response as success — including an error — and retried across seven days, resuming on every editor restart.

If every endpoint failed, the beacon queried a DNS TXT record for a replacement collector address. That let the operator relocate infrastructure without shipping new packages.

The payload also reported whether the workspace’s own devcontainer or extensions configuration had pulled the extension in. That distinction matters: it separates installs a repository caused from installs a human chose.

Manifold argued this is critical because name resolution is increasingly automated. Agents and provisioning scripts install by name across two registries whose separate ownership rules make a squatted name indistinguishable from the real one.

How to Protect Yourself

Open VSX removed the packages on August 3, though the infrastructure remained live at the time of writing. If you’re worried about similar attacks, Manifold offered some practical advice:

• Pin by publisher and version where registries are mirrored internally
• Treat the unverified-publisher banner as a blocking condition in automated installs
• Alert on editor processes contacting recently registered domains shortly after startup

This isn’t the first time extension name abuse has caused problems. Earlier research highlighted how malicious VS Code extensions exploit a name reuse loophole. The pattern keeps repeating because the registries haven’t closed the gap.

The takeaway is simple. If you’re running automated installs across a team, don’t trust names alone. Verify the publisher. Check the version. And treat any telemetry disclosure in a random extension as a red flag, not a comfort.