VECT Ransomware 2.0: A Flawed Encryption Engine That Turns Into a Wiper

Introduction

Check Point Research (CPR) has uncovered a critical flaw in VECT 2.0 ransomware that transforms it from a file-encrypting menace into a data-destroying wiper for any file larger than 128 KB. This vulnerability, present in all three platform variants (Windows, Linux, ESXi), means that the attackers themselves cannot recover lost data—making VECT an accidental wiper rather than a true ransomware tool. The discovery also exposes multiple other bugs and false claims in the ransomware's design, painting a picture of a professional-looking operation with amateur execution.

The Encryption Flaw: Why Large Files Are Lost Forever

At the heart of VECT's failure is its encryption implementation. The ransomware uses raw ChaCha20-IETF (RFC 8439) without authentication—not the claimed ChaCha20-Poly1305 AEAD. For every file exceeding 131,072 bytes (128 KB), the code discards three out of four decryption nonces. This means that only one quarter of the data in a large file is properly encrypted; the rest is effectively scrambled beyond recovery.

The flaw is systematic: VECT divides files into four chunks but only stores one nonce for the entire operation. As a result, any file above the 128 KB threshold becomes impossible to decrypt—even for the attackers. Full recovery is a pipe dream. For enterprise assets like virtual machine disks, databases, documents, and backups, the threshold is incredibly low, making VECT a de facto wiper for almost any meaningful dataset.

Misidentification and Missing Features

Wrong Cipher, No Integrity

Multiple threat intelligence reports—and VECT's own initial advertisements—claimed the ransomware used ChaCha20-Poly1305, a cipher with built-in authentication. In reality, VECT employs raw ChaCha20 with no Poly1305 MAC and no integrity protection whatsoever. This misidentification could lead defenders to assume some level of data integrity that simply does not exist.

Speed Modes That Do Nothing

VECT advertises three encryption speed modes—--fast, --medium, and --secure—on Linux and ESXi variants. However, these flags are parsed and then silently ignored. Every execution uses identical hardcoded thresholds, regardless of the operator's selection. The promised performance tuning is a mirage.

A Unitary Codebase Across Platforms

Windows, Linux, and ESXi variants of VECT share an identical encryption design built on libsodium. CPR confirmed that the same file-size thresholds, the same four-chunk logic, and the same nonce-handling flaw are present across all three. This confirms a single codebase ported between platforms, making the vulnerability universal. Any victim running any variant is equally affected.

Beyond the Core Flaw: Additional Bugs

The nonce flaw is far from the only issue. CPR identified several other bugs and design failures across all variants:

• Self-cancelling string obfuscation: Obfuscation routines that undo their own effects, doing nothing to hide the code.
• Permanently unreachable anti-analysis code: Blocks of code designed to hinder reverse engineering that can never be executed due to flawed logic.
• Counterproductive thread scheduler: A multi-threading mechanism meant to speed up encryption actually degrades performance because of poor implementation.

These issues further underline the amateur foundation behind VECT's professional facade.

Background: The RaaS Operation and TeamPCP Partnership

VECT Ransomware first appeared in December 2025 as a Ransomware-as-a-Service (RaaS) program on a Russian-language cybercrime forum. After claiming initial victims in January 2026, the group gained notoriety by announcing a partnership with TeamPCP, an actor responsible for several supply-chain attacks in March 2026. Those attacks injected malware into popular software packages—including Trivy, Checkmarx's KICS, LiteLLM, and Telnyx—affecting a large downstream base.

Shortly after those attacks made headlines, VECT posted on BreachForums to announce their collaboration with TeamPCP, aiming to exploit companies hit by the supply-chain incidents. Additionally, VECT announced a partnership with BreachForums itself, promising that every registered forum user could become an affiliate, gaining access to VECT's ransomware, negotiation platform, and leak site. This low-barrier affiliate model is unusual and could expand the ransomware's reach—but the technical flaws severely limit its effectiveness.

Conclusion: A Ransomware That Destroys, Not Extorts

The VECT ransomware family, despite its professional marketing and high-profile partnerships, is fundamentally broken. The encryption flaw that turns large files into unrecoverable junk makes it less of a ransomware and more of a wiper. Combined with misidentified ciphers, non-functional features, and multiple amateur bugs, VECT represents a cautionary tale: even sophisticated-looking cyber threats can be undermined by poor implementation. For defenders, the key takeaway is clear: relying on VECT's own claims is dangerous, and the only reliable defense is robust backup and recovery practices.