How ENCFORGE Ransomware Exploits Langflow’s CVE‑2025‑3248 to Hijack AI Models

1. Who the attackers are: JADEPUFFER’s second strike

The campaign is attributed to the same AI‑agent‑driven threat actor (ATA) JADEPUFFER that first appeared in early July, capable of autonomous reconnaissance, credential harvesting, lateral movement, and destructive ransomware. After an initial Langflow attack that encrypted Nacos and production databases, JADEPUFFER returned three weeks later with a compiled Go ransomware, ENCFORGE, now targeting AI model assets.

Both attacks used the same ransom‑contact email [email protected], providing strong attribution evidence.

2. Infiltration path: CVE‑2025‑3248 as a persistent entry

The attack chain starts with the unprotected Langflow endpoint /api/v1/validate/code in versions prior to 1.3.0, which allows any remote attacker to execute Python code on the server. CVE‑2025‑3248 (CVSS 9.8) was added to the CISA KEV list on 5 May 2025 and remains the unified entry point for JADEPUFFER.

Langflow is a widely deployed open‑source LLM orchestration framework that typically stores API keys, cloud credentials, vector‑database connections, and object‑storage tokens in environment variables and a Postgres backend, making it an attractive jump‑pad for credential theft.

3. ENCFORGE details: ransomware built for AI infrastructure

3.1 Positioning and coverage

Filename: .lockd (dot file to evade directory scans)

Packaging: UPX 5.20

Compiled with: Go 1.22.12 (static linking)

Internal project name: encfile Auxiliary tool: keyforge (key generator)

Hashes: packed 8cb0c223…, unpacked ea7822ea… AV detection rate: 0 (both packed and unpacked are undetected)

ENCFORGE targets roughly 180 file extensions covering the modern AI/ML stack, including: .ckpt, .h5, .onnx, .pb, .pkl/.pickle, .pt/.pt2/.pth, .safetensors, .ggml/.gguf, .model (model checkpoints) faiss (vector‑search index) arrow/.feather, .parquet, .tfrecord, .npy/.npz, .vec, .duckdb (training and columnar data) .keychain/.keychain-db, .xcodeproj, .pages/.numbers (developer‑oriented formats)

The binary includes a --include flag that lets attackers add custom file‑matching patterns at runtime; its built‑in help examples reference LoRA adapter files ( *lora) and legacy GGML weights ( *ggjt), showing intentional targeting of AI environments.

3.2 Encryption mechanism

ENCFORGE encrypts files with AES‑256‑CTR, generating a fresh symmetric key for each run and wrapping it with an RSA‑2048 public key compiled into the binary. Rather than encrypting whole files, it selectively encrypts data blocks, mirroring speed‑optimisation tactics used by ransomware families such as LockBit and BlackCat. Encrypted files receive a .locked suffix, and three ransom‑note files ( README, HOW_TO_DECRYPT, README_DECRYPT) are dropped, all referencing the same ransom email address.

Notably, ENCFORGE contains no network‑exfiltration code; Sysdig observed no data leakage, dark‑web dumps, or Tor payment portals. The attackers’ only leverage is the encrypted AI assets.

4. Container escape: five‑minute, six‑iteration path to host‑root

After gaining code execution inside the Langflow container, the attackers performed standard post‑exploitation checks ( id, uname -m, hostname) and harvested credentials (cloud keys, DB strings, API tokens). They probed internal service reachability via /dev/tcp and replayed credentials against internal databases and caches.

The pivotal discovery was write access to /var/run/docker.sock. Controlling the Docker socket grants root on the host because any process can instruct the Docker daemon to launch a privileged container with the host filesystem mounted, enabling arbitrary read/write outside the original container namespace.

When a direct curl download of ENCFORGE from the C2 server failed, the attackers switched tactics: they copied the binary from the container’s /proc filesystem to the host and executed it there.

The following timeline shows the six Python scripts written and iterated over roughly five minutes:

12:07:01 – do.py v1: baseline curl‑over‑unix‑socket wrapper

12:07:25 (+24 s) – do.py v2: added copy via /proc/ root, removed generic exec

12:08:08 – ns.py: shared exec_in_bigrun() helper, hard‑coded PID 4242

12:08:39 – x.py: each command runs in a one‑off container

12:09:01 – h.py: raw AF_UNIX socket HTTP client, no subprocess dependency

12:10:04 – deploy.py v1: Docker API discovers host PID, copies binary, attempts run

12:12:25 (+2 min 24 s) – deploy.py v2: adds live‑lock execution and post‑run verification

The final payload (deploy.py v2) discovers the target process PID via the Docker API, copies ENCFORGE from the container’s procfs to a host directory, then uses nsenter to enter the host PID and network namespaces and execute the ransomware.

Escape container configuration (JSON excerpt):

{
  "Image": "registry.internal/app:2.3.1",
  "HostConfig": {
    "Binds": ["/:/host:rw"],
    "Privileged": true,
    "PidMode": "host",
    "NetworkMode": "host"
  }
}

Key command‑line flags used by ENCFORGE: --try-run – scans the filesystem --lock – performs actual encryption --task-id gcp_h1 – tags the node as a GCP target within a larger campaign.

The most alarming aspect is the attackers’ autonomous adaptation: when the preferred download path was blocked, they pivoted within five minutes to a completely different technique (Docker‑socket‑based host escape), demonstrating goal‑driven decision‑making rather than simple script tinkering.