Beyond CVEs: How Orca Now Detects and Blocks Malicious Packages

Key Findings

• Supply chain attacks increasingly rely on weaponizing legitimate packages by pushing malicious new versions, not just exploiting known vulnerabilities, creating a detection gap in most AppSec toolchains.
• Recent campaigns like Mini Shai-Hulud (May 2026) and the @redhat-cloud-services npm compromise (June 2026) demonstrate that malicious packages can execute payloads on install, before application code ever runs.
• Most AppSec tools, including SAST, SCA, and secrets scanners, were designed to detect insecure or vulnerable code, not intentionally weaponized dependencies. Identifying whether a package was built to cause harm requires a dedicated solution for this type of risk.
• Orca AppSec now detects and blocks malicious packages across the IDE, pull requests, and CI/CD pipelines, with full dependency tree coverage and a Path to Root visualization that shows exactly how a malicious package entered your project.
• The policy ships in Block mode by default, so teams are protected without additional configuration.

Why Traditional AppSec Toolchains Weren’t Designed to Detect Malicious Packages 

Modern application security programs have become remarkably good at finding vulnerabilities. SAST surfaces insecure code patterns. SCA identifies outdated or vulnerable open source dependencies. Secrets detection catches leaked credentials before they reach production. Together, these tools give teams more visibility into application risk than ever before.

But that visibility has a boundary. Every tool in a typical AppSec stack was built around a shared assumption that the packages you’re working with are doing what they appear to do. Most of them are not designed to ask a more fundamental question of if this package was deliberately built to cause harm. That is the question at the center of malicious package detection, and it’s a problem that most application security toolchains weren’t designed to solve.

A Different Kind of Supply Chain Risk

Open source dependencies introduce real risk, and tracking CVEs across a dependency tree is essential work. But vulnerability scanning and malicious package detection are solving two different problems.

A CVE describes a flaw in a legitimate package, one that was written in good faith but contains a bug that can be exploited. Malicious packages however are different in nature. They may have no CVEs and may appear legitimate at first glance. The harm is intentional and often immediate, with payloads designed to execute on install, steal credentials, or propagate through a CI/CD pipeline before any security control has a chance to intervene.

This distinction matters because catching malicious packages requires a different approach: tracking known malicious packages through centralized threat intelligence and package reputation data, then checking whether any appear in your dependency tree. No CVE database covers this. Organizations can have mature SCA coverage, a well-tuned SAST pipeline, and active secrets detection, and still have no visibility into whether a package in their dependency tree was designed to be a weapon. “Open source security” tends to get treated as a single category, when in practice it covers meaningfully different problems that require different tools.

What Do Recent Campaigns Reveal About Malicious Package Attacks? 

A handful of recent campaigns illustrate why this matters in practice.

In May 2026, a threat group compromised TanStack, Mistral AI, UiPath, and more than 160 npm and PyPI packages in a coordinated worm attack known as Mini Shai-Hulud. The initial payload executed the moment a developer ran npm install, with no user interaction and no CVE to trigger a scanner. Within minutes, the worm had stolen npm tokens and GitHub Personal Access Tokens and used them to publish additional malicious package versions automatically.

A few weeks later, 32 packages under the @redhat-cloud-services npm scope were compromised through unauthorized commits to the RedHatInsights GitHub organization. The Miasma payload was embedded as a preinstall script, triggering automatically the moment a developer ran the install command, before any application code executed.

None of these attacks exploited a known vulnerability. There was no CVE. The packages themselves were the attack vector, and a standard AppSec toolchain, however well-configured, would not have flagged them. AI is accelerating the trend, lowering the barrier to creating convincing malicious packages at scale, resulting in a surge that has hit victims ranging from small teams to even first-class enterprises.

Orca’s Approach: Detection and Enforcement Across the SDLC

Orca AppSec now includes malicious package detection as a native capability, eliminating a blind spot that exists across most AppSec toolchains today, integrated into the same platform and policy engine that manages SAST, SCA, secrets, and IaC findings. Teams don’t need to add a new tool, manage a separate integration, or build a new workflow.

Secure by default

The malicious package policy ships in Block mode. If a known malicious package is detected in a dependency tree, whether it’s a direct dependency or buried several layers deep, CI builds fail and PR merges are blocked. Teams can move specific repositories to Warn mode or dismiss individual alerts, but the default posture is protection without requiring any setup.

Full dependency tree coverage

Most malicious packages don’t arrive as direct dependencies. They’re transitive, meaning your package depends on a package that depends on a package that’s malicious. Orca scans the complete dependency tree and stores the full path from the root manifest to the offending package. Coverage spans npm, PyPI, Maven, NuGet, Go, Cargo, and RubyGems, with additional package managers to follow.

Path to Root visualization

When a malicious package is detected, Orca shows the full dependency path both visually in the platform and inline in the terminal, so developers don’t need to leave their workflow to understand the scope of the issue:

This matters particularly for transitive dependencies, where the fix isn’t removing the offending package directly. It’s handling the package that pulled it in.

Integrated where developers work

Detection fires at PR creation, on push and merge, in CI pipelines, at the CLI, and in the IDE. Security teams can enforce policy at the pipeline level. Developers who want inline feedback get a sidebar widget showing the affected dependency branch with a Quick Fix option to open the manifest directly.

Closing the Gap

Most organizations building cloud-native software have layered defenses across code, dependencies, secrets, and infrastructure. But those tools were designed around the premise that the packages being analyzed are legitimate. The risk, in that framing, is in how you use them, not in what they are.

Malicious package detection adds the missing dimension: coverage for packages that are themselves the threat, through the same platform, policy engine, and workflows teams already use.

Interested in seeing how Orca AppSec works across your SDLC? Schedule a personalized demo.