Vibe coding — writing software by prompting AI and shipping the output without deep review — is not just a habit your developers have picked up. It is showing up in attacker tools now too. VECT ransomware, a Ransomware-as-a-Service operation that surfaced in December 2025, has the structural fingerprints of unreviewed AI code generation all through it. The most consequential is a logic error so fundamental that VECT permanently destroys the data it was supposed to hold hostage. Every file over 128KB is rendered permanently irrecoverable because the encryption loop discards three of the four nonces it generates.
Check Point Research published their technical analysis on 29 April 2026. Their conclusion: VECT is the work of novice actors who know what a professional ransomware tool should look like, but demonstrably struggled to build one. The result is a data wiper dressed up as ransomware.
This article covers what VECT is, how the 128KB bug works, why AI-generated code produces this exact class of error, and what the two-sided development environment means for organisations whose own developers are using the same tools. For the broader security picture of vibe coding in production, this is one piece of a larger picture.
What is VECT ransomware and what makes researchers think it was partly AI-generated?
VECT is a Ransomware-as-a-Service (RaaS) operation — the operator provides the builder, infrastructure, and negotiation platform; affiliates deploy it and take a cut. It appeared in December 2025 on Russian-language cybercrime forums, claimed its first two victims in January 2026, then released VECT 2.0 in February 2026 targeting Windows, Linux, and VMware ESXi.
Check Point Research accessed the builder panel via BreachForums and did static analysis on the compiled binaries. VECT’s .text section has flat entropy and libsodium source path strings sitting in plaintext — both signs of unobfuscated, unreviewed code. CPR identified three structural signatures consistent with AI code generation.
Signature 1 — Nonce overwrite bug. The encryption loop generates a fresh nonce per chunk but writes all four to a single shared buffer. Only the final nonce survives to disk.
Signature 2 — Self-cancelling XOR obfuscation. VECT applies XOR twice with the same key, which cancels the effect entirely and leaves strings in plaintext. That is the pattern you get when a model combines obfuscation snippets without understanding that they invert each other.
Signature 3 — Geofencing inconsistency. The Linux and ESXi variants enforce CIS geofencing and exit without encrypting. The Windows variant has no such check. That is consistent with AI-generated platform variants produced independently without anyone cross-checking shared requirements.
CPR also found advertised speed modes that are parsed but never read back, and anti-analysis routines that are compiled but permanently unreachable. Their inference: “The authors know what features a professional ransomware tool should have, but demonstrably struggled to implement them correctly or at all.”
These are the same vulnerability classes that appear across legitimate AI-coded production applications — logic errors, missing controls, dead code — because the same generation process produces them on both sides.
💡 RaaS (Ransomware-as-a-Service): A criminal business model where an operator provides the ransomware builder, infrastructure, and negotiation platform; affiliates deploy and share revenue. VECT distributed access keys to all BreachForums members in April 2026, removing the usual affiliate vetting barrier.
How does the 128KB file destruction bug work — and why does it make paying the ransom pointless?
VECT uses ChaCha20-IETF via libsodium to encrypt files. Stream ciphers require a unique random value for each encryption operation — a nonce. If that nonce is not saved, decryption is mathematically impossible regardless of whether you hold the key.
💡 Nonce: A “number used once” — a unique random value required by stream ciphers like ChaCha20 to ensure each encryption operation produces distinct output. Losing a nonce makes the ciphertext permanently unreadable, even with the correct key.
For files over 131,072 bytes (128KB), VECT divides the file into four chunks and encrypts each with a freshly generated 12-byte nonce. All four nonces get written to the same buffer variable — each iteration overwrites the previous one. Only the fourth nonce makes it to disk. The first three are gone.
So what does that mean in practice? Paying the ransom gets you a key and the fourth nonce. The first three quarters of every large file are irrecoverable. As CPR noted, 128KB is smaller than a typical email attachment — database files, VM images, email archives, and documents with attachments all exceed it.
JUMPSEC, which independently analysed VECT, found a second bug on top of this: files between 32KB and 128KB are never encrypted at all — just renamed with the .vect extension. Their summary: “The only files that Vect can actually decrypt and restore are files under 32KB.”
The practical upshot: do not pay. Focus on offline or immutable backup restoration, and check files in the 32KB–128KB range first — those are only renamed and fully recoverable without any key.
Why does AI-generated code produce exactly this kind of bug — and does that apply to defenders too?
The nonce overwrite is a loop state error. Any developer who has debugged a loop writing results into a single variable instead of indexed slots will recognise it immediately. A human developer writing encryption code typically knows nonces must be per-operation. An LLM generating from training examples where loop results are accumulated may not apply that constraint.
The double-XOR failure is the same class of mistake. The geofencing inconsistency across platform ports is the clearest diagnostic of all: models prioritise local functional correctness over global coherence — code that looks right at the snippet level but breaks down when requirements must hold across variants generated in separate sessions.
VECT is not an isolated case either. Transparent Tribe (APT36) was documented in early 2026 using AI coding tools to produce implants that were “often unstable and riddled with logical errors” — volume over sophistication, flooding defensive telemetry with disposable binaries.
The defender-side connection is direct. The generation process is the same on both sides. What differs is the review gap. If your team ships AI-generated code and your review process does not specifically audit loop state variables, per-iteration nonce initialisation, and multi-platform logic parity, your organisation shares the same risk class as VECT’s developers. The code is not malware. The review gap looks identical.
What is VECT 2.0 and what does the fact that threat actors iterated tell us?
The timeline is tight: VECT appeared December 2025, VECT 2.0 released February 2026, CPR analysis published 29 April 2026. That is a two-month development iteration cycle.
What changed in 2.0: expanded platform targeting (Linux and ESXi added), RaaS infrastructure, formal affiliate onboarding. What did not change: the 128KB nonce bug. They added reach without fixing the core encryption flaw.
On 18 April 2026, VECT issued access keys to all registered BreachForums users, removing the usual vetting barrier entirely. As JUMPSEC noted: “Lockbit spent years working on their encryptor before opening the gate to affiliates, whereas Vect have gone straight to opening the gate to anyone.” The affiliate fee is real; the negotiation link returns a 404.
VECT’s confirmed victims were reached via TeamPCP, responsible for supply chain attacks in March 2026 affecting more than 1,000 SaaS environments. VECT announced a formal partnership with TeamPCP to exploit compromised organisations. The parallel campaign targeting the AI coding toolchain itself is covered separately.
The arms-race argument rests on that iteration. VECT 1.0 had bugs; VECT 2.0 corrected some and expanded reach. The trajectory is real — VECT is the evidence.
What does the arms race mean for organisations whose developers are also using AI coding tools?
Vibe coding creates security risk on both sides of the fence. VECT is the first documented case where attacker-side vibe coding produced a traceable, analysable outcome — a broken tool. But VECT 2.0 confirms attackers apply correction processes, just like any development team would.
The asymmetry matters. When VECT’s nonce bug broke its own ransomware, the cost fell on victims — not on the operators. If a defender’s AI-generated encryption code had the same flaw, the cost would fall on the organisation that shipped it: breach notification, regulatory scrutiny, litigation exposure.
The review practices that would have caught VECT’s nonce bug — auditing loop state management, per-iteration variable initialisation, and multi-platform logic parity — apply equally to any team shipping AI-generated cryptographic code. Standard code review designed to catch human-written bugs may not catch these, because the failure modes are different.
VECT is early-stage. The appropriate response is preparation: targeted review practices for the specific bug classes AI generation produces, implemented before the adversarial trajectory matures. Understanding this threat in the context of the full vibe coding security landscape — from institutional deployment to statistical vulnerability rates to toolchain attacks — clarifies why the risk is structural, not incidental. The governance implications of a two-sided arms race — who owns the risk when the code writes itself — are the next layer.
Frequently Asked Questions
What is VECT ransomware?
VECT is a Ransomware-as-a-Service (RaaS) operation first advertised on Russian-language cybercrime forums in December 2025. Version 2.0, released February 2026, targets Windows, Linux, and VMware ESXi systems. Check Point Research analysed it in April 2026 and found structural signatures consistent with partly AI-generated code, including a logic error that permanently destroys data in files over 128KB.
Can VECT ransomware decrypt my files if I pay the ransom?
For files over 128KB, no — decryption is cryptographically impossible. VECT’s nonce overwrite bug discards three of the four encryption nonces when processing large files. Without those nonces, the ChaCha20-IETF cipher cannot reverse the encryption regardless of what key the attacker provides. The information required to build a decrypter was destroyed the moment VECT ran.
What is the 128KB file destruction threshold in VECT?
VECT processes files over 131,072 bytes (128KB) in four equal chunks. It generates a unique nonce for each chunk but writes all four to the same buffer variable — each write overwrites the previous. Only the fourth nonce survives to disk. The first three are gone, making the first three quarters of every large file permanently irrecoverable.
What is a cryptographic nonce and why does losing one matter?
A nonce is a unique random number required once per encryption operation in stream ciphers like ChaCha20. It ensures each chunk produces distinct ciphertext. If it is not saved, the ciphertext from that chunk can never be decrypted — even by the person who created it.
Is VECT ransomware actually a data wiper?
In practical effect, yes — for all files over 128KB, VECT permanently destroys data with no recovery path. VECT was advertised as ransomware, but the nonce bug made it an accidental wiper. Files between 32KB and 128KB are not encrypted at all — only renamed with the .vect extension and fully recoverable without any key.
What structural evidence led Check Point Research to call VECT partly AI-generated?
Three code signatures: a nonce overwrite logic error; double-XOR obfuscation that cancels itself; and geofencing logic present in Linux/ESXi variants but absent in Windows. Each is characteristic of unreviewed AI code generation. The inference is structural — no actor admitted using an AI tool.
Who is TeamPCP and how does VECT connect to them?
TeamPCP is a threat actor responsible for March 2026 supply chain attacks on Trivy, LiteLLM, Checkmarx KICS, and Telnyx, affecting more than 1,000 SaaS environments. VECT announced a formal partnership with TeamPCP to exploit compromised organisations. VECT’s two confirmed victims were reached via the Trivy supply chain pathway.
Is vibe-coded malware more or less dangerous than traditionally written ransomware?
Currently less sophisticated — VECT’s core encryption is broken — but not less dangerous in impact. A data wiper causes the same data loss as functioning ransomware without any recovery path. VECT 2.0’s existence confirms attackers are iterating. The concern is not where VECT is today; it is where the next version lands.
How does VECT compare to ransomware like LockBit?
LockBit and comparable professional RaaS operations employ experienced developers who review and test their encryption. VECT’s structural bugs — self-cancelling obfuscation, incorrect cipher identification in its own advertising, geofencing inconsistency across platforms — do not appear in mature operations. VECT is early-stage adversarial vibe coding: dangerous in its accidental destructiveness, not yet at the technical maturity of established RaaS groups.
Did hackers use ChatGPT to write VECT ransomware?
CPR found structural evidence of AI code generation but did not identify a specific LLM tool. The evidence is inferential: the bug profile matches patterns LLMs produce when generating code without review. No actor has claimed to have used a specific AI tool to build VECT.
What should an organisation do if hit by VECT ransomware?
Do not pay — decryption is not possible for files over 128KB. Files between 32KB and 128KB were never encrypted, only renamed with the .vect extension, so those are recoverable without any key. Recovery depends on offline or immutable backups and containment of lateral movement paths (WMI, SMB, SSH).
