Introduction

In the ever-evolving landscape of cyber threats, the VECT ransomware family has emerged as a particularly dangerous player—not because of its sophistication, but due to a catastrophic design flaw that turns it into a data wiper for most files. Check Point Research (CPR) has uncovered that VECT 2.0 permanently destroys files larger than 128 KB instead of encrypting them, making full recovery impossible for victims and even the attackers themselves. This article delves into the technical details of the flaw, its implications, and the broader context of VECT's operations.

The Critical Encryption Flaw

How the Nonce Error Works

At the heart of VECT's encryption mechanism lies a fundamental error in nonce handling. The ransomware uses a four-chunk encryption strategy for files larger than 131,072 bytes (128 KB). For each file, it generates four decryption nonces but then discards three of them due to a programming mistake. This means that for any file exceeding this threshold, the encryption keys are effectively lost. The flaw is consistent across all three platform variants—Windows, Linux, and ESXi—confirming a shared codebase.

Impact on File Recovery

Because the nonces are critical for decryption, any file above 128 KB becomes permanently inaccessible. This threshold is alarmingly low: enterprise assets such as virtual machine disks, databases, documents, and backups are all larger than 128 KB. In practice, VECT acts as a wiper for virtually any meaningful data. Even if the attackers wanted to restore the files after a ransom payment, they cannot—the necessary decryption information is irretrievably lost.

Misidentification and Incorrect Claims

Cipher Confusion

Publicly available threat intelligence reports, as well as VECT's own initial advertisements, have incorrectly claimed that the ransomware uses ChaCha20-Poly1305 AEAD encryption. In reality, VECT employs raw ChaCha20-IETF (RFC 8439) without any authentication. There is no Poly1305 MAC and no integrity protection. This misidentification could lead security teams to implement ineffective countermeasures based on false assumptions.

Unimplemented Speed Modes

VECT advertises three encryption speed modes on Linux and ESXi variants: --fast, --medium, and --secure. However, CPR found that these flags are parsed and then silently ignored. Every execution uses identical hardcoded thresholds, regardless of operator selection. This indicates either incomplete development or deliberate deception.

A Single Codebase Across Platforms

Unlike many ransomware families that develop separate codebases for different operating systems, VECT uses a unified encryption engine built on libsodium. The same file-size thresholds, same four-chunk logic, and same nonce-handling flaw appear in the Windows, Linux, and ESXi variants. This portability suggests a streamlined development process but also means that all platforms inherit the same fatal bugs.

Multiple Implementation Bugs

Beyond the critical nonce flaw, CPR identified several additional bugs that underscore the amateurish nature of VECT's development despite its professional facade.

Self-Cancelling String Obfuscation

VECT attempts to obfuscate strings in its binary using a custom algorithm, but the implementation contains a logical error that causes the obfuscation to cancel itself out. As a result, the strings remain plainly visible to anyone analyzing the code.

Unreachable Anti-Analysis Code

The ransomware includes anti-analysis routines designed to detect debuggers or virtualized environments. However, due to conditional branches that can never be satisfied under normal execution, this code is permanently unreachable. It exists in the binary but never runs, providing no actual protection.

Ineffective Thread Scheduler

VECT employs a thread scheduler intended to improve encryption performance by parallelizing tasks. However, the scheduler is poorly designed and actively degrades performance. The overhead of managing threads outweighs any parallelization benefits, slowing down the encryption process instead of accelerating it.

Background and Emergence

VECT Ransomware first appeared in December 2025 on a Russian-language cybercrime forum as a Ransomware-as-a-Service (RaaS) program. It claimed its first two victims in January 2026, but gained significant notoriety in March 2026 following an announcement of a partnership with TeamPCP, the actor behind several supply-chain attacks. These attacks infected popular software packages such as Trivy, Checkmarx KICS, LiteLLM, and Telnyx, affecting a large base of downstream consumers. VECT later posted on BreachForums, declaring the partnership with TeamPCP and aiming to exploit companies affected by those supply-chain attacks. Additionally, VECT announced a partnership with BreachForums itself, promising that every registered forum user would become an affiliate, gaining access to the ransomware, negotiation platform, and leak site.

Conclusion

The VECT ransomware, despite its professional marketing and partnerships, is fundamentally flawed. Its encryption error effectively turns it into a wiper for all but the smallest files, making ransom demands moot. The string of implementation bugs—from self-cancelling obfuscation to an ineffective thread scheduler—reveals a development effort that prioritized appearance over functionality. For organizations targeted by VECT, the primary concern is data loss, not extortion. Understanding these weaknesses can help defenders identify signs of compromise and mitigate the damage before encryption occurs.