VECT ransomware, first spotted in late 2025 as a Ransomware-as-a-Service (RaaS) offering on a Russian-language cybercrime forum, quickly gained notoriety after claiming early victims in early 2026. But when security researchers at Check Point Research (CPR) dug into the VECT 2.0 code, they uncovered a stunning flaw: instead of encrypting large files, the ransomware permanently destroys them. This Q&A explores how VECT's amateur coding turned a would-be encryption tool into an accidental wiper, the misidentified cipher, ignored speed modes, and the group's controversial partnerships.
What is VECT ransomware and how did it emerge?
VECT is a Ransomware-as-a-Service (RaaS) program that first appeared in December 2025 on a Russian-language cybercrime forum. It claimed its first two victims in January 2026. The group resurfaced after announcing a partnership with TeamPCP—the actor behind several supply-chain attacks in March 2026 that injected malware into popular software packages such as Trivy, Checkmarx’ KICS, LiteLLM, and Telnyx. These attacks affected a broad base of downstream consumers. Shortly after the headlines, VECT posted on BreachForums announcing the collaboration with the goal of targeting companies affected by those supply-chain attacks. VECT also promised that every registered BreachForums user would become an affiliate, gaining access to VECT’s ransomware, negotiation platform, and leak site—a highly unusual open recruitment tactic.
How does a critical nonce flaw turn VECT 2.0 into a wiper?
In VECT 2.0, a severe bug in the encryption implementation causes the ransomware to permanently destroy large files instead of encrypting them. The flaw lies in how the code handles decryption nonces for files exceeding 131,072 bytes (128 KB). For every such file, VECT generates four nonces but then discards three of them—only one nonce is properly stored for decryption. This means that recovery is impossible, even for the attacker. Since the threshold is only 128 KB, virtually any meaningful file—virtual machine disks, databases, documents, backups—gets wiped. CPR confirmed this flaw exists across all publicly available VECT versions, making the ransomware operate as an accidental wiper.
Which cipher does VECT actually use and why was it misidentified?
Contrary to multiple widely-cited threat intelligence reports and VECT’s own advertisements, the ransomware does not use ChaCha20-Poly1305 AEAD. Instead, it employs raw ChaCha20-IETF per RFC 8439 with no authentication at all. There is no Poly1305 MAC and no integrity protection. This misidentification has spread because early reports accepted VECT’s claims at face value, and because the library used (libsodium) makes it easy to accidentally use the unauthenticated variant. The lack of authentication means that even if the nonce bug were fixed, an attacker or victim could not verify that encrypted data had not been tampered with—another severe design weakness.
Are the advertised encryption speed modes truly functional?
No. VECT advertises three encryption speed modes—--fast, --medium, and --secure—across its Linux and ESXi variants. However, CPR discovered that these flags are parsed and then silently ignored. Every execution applies identical hardcoded thresholds regardless of which mode the operator selects. This means the speed control is purely cosmetic; the ransomware always behaves the same way. This is another example of the “professional facade, amateur execution” pattern observed throughout the codebase. Operators who think they are choosing a secure mode are actually getting the same flawed behavior as the fast mode.
How are the Windows, Linux, and ESXi variants connected?
All three platform variants of VECT—Windows, Linux, and ESXi—share an identical encryption design built on the libsodium library. They use the same file-size thresholds, the same four-chunk logic, and the same nonce-handling flaw. CPR confirmed this by analyzing the code across platforms. The shared implementation proves that VECT is a single codebase ported across platforms, not separate developments. This consistency made it easier for researchers to identify the flaw, but it also means that every variant is equally broken. Any file above 128 KB is permanently destroyed on any operating system, making network-wide recovery impossible.
What other bugs or amateur mistakes exist in VECT?
Beyond the catastrophic nonce flaw, CPR identified multiple additional bugs and design failures in all variants. These include self-cancelling string obfuscation (where obfuscation routines undo each other), permanently unreachable anti-analysis code that never executes, and a thread scheduler that actively degrades encryption performance—the exact opposite of its intended purpose. Together, these issues paint a picture of a group that projects professionalism but delivers amateur execution. The encryption engine itself is poorly implemented, and the mistakes suggest the developers may have rushed development or lacked deep cryptographic expertise.
What partnerships did VECT announce and what do they mean?
VECT made two key partnership announcements. First, it announced a partnership with TeamPCP, the group behind supply-chain attacks in March 2026 that injected malware into software packages like Trivy, KICS, LiteLLM, and Telnyx. VECT aimed to exploit companies affected by those attacks. Second, VECT announced a partnership with BreachForums, promising that every registered forum user would become an affiliate, gaining access to the ransomware, negotiation platform, and leak site. This open recruitment is highly unusual—most ransomware groups vet affiliates carefully. The partnerships suggest VECT is trying to rapidly expand its reach, but the underlying technical flaws may limit its effectiveness as a ransomware operation.