In early 2026, VECT Ransomware-as-a-Service (RaaS) made headlines not just for its partnership with supply-chain attackers TeamPCP, but for a devastating technical flaw in its encryption engine. Check Point Research discovered that VECT 2.0's encryption implementation contains a critical bug: for any file larger than 128 KB, three out of four decryption nonces are discarded, making recovery impossible—even for the attackers themselves. This means VECT, designed as ransomware, effectively acts as a wiper for large files, destroying virtual machine disks, databases, backups, and other meaningful data. Despite claiming attention with professional ads and partnerships, VECT's underlying code is riddled with amateur errors, from misidentified ciphers to ignored performance options. Below, we answer the most pressing questions about this flawed ransomware.
- What makes VECT 2.0 more than just ransomware?
- Why can’t even the attackers recover large files?
- What encryption algorithm does VECT really use?
- How do the platform variants (Windows, Linux, ESXi) compare?
- Are the advertised speed modes actually functional?
- What background does VECT have, and who is behind it?
What makes VECT 2.0 more than just ransomware?
VECT 2.0 is billed as ransomware, but a critical design flaw turns it into a wiper for files exceeding 128 KB. Normally, ransomware encrypts data and holds it for ransom, with the possibility of decryption after payment. However, VECT's encryption implementation discards three of the four decryption nonces required to recover large files. This means that for any file above that threshold—encompassing virtual machine disks, databases, documents, backups, and other enterprise assets—full recovery is impossible. The attacker cannot undo the encryption even if they want to. This effectively transforms VECT from a tool for extortion into one for data destruction, a severe misstep for a RaaS operation aiming to maintain a reputation for recoverability.
Why can’t even the attackers recover large files?
The flaw lies in the nonce handling during encryption. VECT uses a four-chunk logic for files above 131,072 bytes (128 KB). Each chunk should have its own unique nonce for encryption, but the implementation erroneously reuses the same nonce for three of the four chunks or discards the necessary nonce information during the process. Without these nonces, decryption is mathematically impossible—no key, no master password, no trick can reconstruct the original data. This is not a simple bug; it's a permanent design failure that affects all three platform variants (Windows, Linux, and ESXi). Check Point Research confirmed this across all publicly available VECT versions, meaning any victim with a file over 128 KB loses it forever.
What encryption algorithm does VECT really use?
Public reports initially claimed VECT uses ChaCha20-Poly1305 (an authenticated encryption scheme with a MAC), but this is false. Check Point Research found that VECT actually uses raw ChaCha20-IETF (as per RFC 8439) with no Poly1305 authentication tag. There is no integrity protection at all. This misidentification likely stems from VECT's own marketing materials, which advertise AEAD capabilities that are not implemented. The use of unauthenticated ChaCha20 means an attacker could tamper with ciphertext undetected, but given the nonce flaw, such tampering is moot—the data is already unrecoverable. This mismatch between claimed and actual encryption highlights the amateur execution beneath VECT's professional facade.
How do the platform variants (Windows, Linux, ESXi) compare?
All three variants share an identical encryption design, built on the libsodium library. They use the same file-size thresholds, the same four-chunk logic for large files, and the same nonce-handling flaw. This confirms that VECT uses a single codebase ported across platforms, rather than separate implementations. The bug thus applies universally—Windows servers, Linux workstations, and ESXi hypervisors are all equally affected. This uniformity simplifies analysis for defenders but underscores the scale of impact: any file over 128 KB on any platform encrypted by VECT is permanently destroyed. The shared architecture also means any future fix would need to be applied consistently across all ports.
Are the advertised speed modes actually functional?
No. VECT advertises three encryption speed modes—--fast, --medium, and --secure—on its Linux and ESXi variants. However, these flags are parsed and then silently ignored. Every execution applies identical hardcoded thresholds and logic, regardless of which mode the operator selects. This is a clear sign of unfinished or poorly tested code. The performance impact is also notable: the thread scheduler in VECT actually degrades encryption speed compared to a simple serial implementation, contradicting its stated goal of optimization. Together, these issues paint a picture of a ransomware group that prioritizes marketing hype over functional reliability.
What background does VECT have, and who is behind it?
VECT first appeared in December 2025 on a Russian-language cybercrime forum as a Ransomware-as-a-Service program. It claimed its first two victims in January 2026 but gained notoriety after partnering with TeamPCP, the group behind several supply-chain attacks in March 2026. These attacks infected popular software like Trivy, Checkmarx's KICS, LiteLLM, and Telnyx, impacting many downstream users. VECT then announced the partnership on BreachForums, stating an aim to exploit companies affected by those supply-chain attacks. Additionally, VECT partnered with BreachForums itself, promising that every registered forum user becomes an affiliate with access to the ransomware, negotiation platform, and leak site—a highly unusual open affiliate model. This aggressive recruitment and connection to notorious actors marks VECT as an emerging threat despite its technical shortcomings.