Vect 2.0 Ransomware Acts as Wiper, Thanks to Design Error
A design flaw in the Vect 2.0 ransomware-as-a-service variant causes it to permanently destroy large files instead of encrypting them, making recovery impossible even for victims who pay the ransom.
The latest variant of the Vect ransomware-as-a-service (RaaS) operation contains a critical design flaw that transforms it from a file-encrypting extortion tool into a data wiper, according to research published this week by Check Point Software. The flaw affects the Windows, Linux, and VMware ESXi versions of Vect 2.0 identically and renders the first three-quarters of any file larger than 128KB permanently unrecoverable — even by the ransomware operators themselves.
The bug lies in Vect's implementation of the ChaCha20-IETF encryption scheme. For files exceeding 131,072 bytes, the malware encrypts four independent chunks of data using four freshly generated random 12-byte nonces, but it appends only the final nonce to the encrypted file on disk. "The first three nonces, each required to decrypt its respective chunk, are generated, used, and silently discarded," Check Point researchers wrote. "They are never stored on disk, in the registry, or transmitted to the operator." Because ChaCha20-IETF requires both the 32-byte key and the key and the exact matching 12-byte nonce to decrypt each chunk, the first three-quarters of every large file are lost forever.
This effectively makes Vect 2.0 a wiper for virtually any file containing meaningful data, including enterprise assets such as VM disks, databases, documents, and backups. "Since the vast majority of operationally critical files exceed this 'large-size' threshold, Vect 2.0 functions in practice as a data wiper with a ransomware facade," Check Point noted. The variant also suffers from other incomplete implementation issues, such as encryption modes that are parsed but never applied, string obfuscation routines that cancel themselves out, and a cipher that is incorrectly described in public reporting.
The wiper flaw creates a scenario where a decryption key is utterly useless, making it unlikely that the operators intended to create a wiper instead of ransomware. "Once that becomes known, people will be less likely to pay the ransom," Eli Smadja, group manager of products R&D at Check Point, told Dark Reading. For defenders, the situation is even worse: victims who pay the ransom cannot recover their largest files may only realize the extent of the damage after paying the ransom and receiving a non-functional decryptor. "Victims who pay get nothing back," researchers at Secure.com wrote in response to the findings.
Vect ransomware first appeared on a Russian-language cybercrime forum late last year and quickly claimed its first two victims in January 2026. Last month, the group gained attention when it unveiled a partnership with TeamPCP, the actor behind several recent supply-chain attacks that injected malware into popular software packages such as Trivy, Checkmarx’ KICS, LiteLLM, and Telnyx. The alliance was seen as a boon for Vect, potentially giving them access to millions of victims through TeamPCP's remote access trojan.
The flaw in Vect 2.0 may put a dent in those plans. Combined with the other cryptographic and engineering issues, Check Point's findings "paint a picture of a group with operational ambition … but with cryptographic and software engineering maturity that does not match the scale of the operation they are attempting to run." Because paying a ransom does not work with Vect 2.0, organizations must focus on prevention and recovery preparation to mitigate damage. Check Point recommends training employees in-depth employee training, vulnerability management, and comprehensive backup strategies to defend against this and similar threats.