Threat actors are actively exploiting critical vulnerabilities in Langflow and Ruby on Rails, turning internet-exposed development and application platforms into targets for credential theft, reconnaissance, command-and-control activity, and possible remote code execution. The most important takeaway for defenders is that these are not theoretical bugs waiting for proof-of-concept interest: exploitation has already been observed in the wild, and the activity appears focused on secrets that can unlock cloud accounts, AI service accounts, databases, and follow-on infrastructure.
The reported flaws are CVE-2026-0768 in Langflow and CVE-2026-66066, also called KindaRails2Shell, in Ruby on Rails environments using specific Active Storage image-processing behavior. Both issues are rated critical, and both affect systems that often sit close to sensitive credentials. That combination makes them especially risky for organizations experimenting with AI workflow tools, exposing internal apps for convenience, or allowing untrusted file uploads without tightly isolating processing components.
Why this activity matters
Langflow is commonly used to build and test AI workflows, which means exposed instances may contain API keys, model provider tokens, environment variables, database references, and cloud credentials. According to reporting based on VulnCheck findings, attackers probing Langflow systems have been looking for values such as Langflow superuser settings, OpenAI-related API keys, AWS access keys, secret keys, shell history, and SSH access clues. That behavior suggests the immediate objective is not simply system compromise; it is credential collection for broader movement.
CVE-2026-0768 is described as a user-supplied input validation failure that can allow arbitrary Python code execution in the context of the root user. If an exposed Langflow service is reachable from the internet and vulnerable, the impact can be severe: an attacker may be able to run commands, harvest local secrets, deploy tooling, pivot to internal services, or use the host as part of a larger campaign.
The Rails vulnerability, CVE-2026-66066, is also dangerous because it can expose arbitrary server-side files and secrets before leading to remote code execution in some scenarios. The issue involves a discrepancy between Active Storage and libvips when processing uploaded images. Applications are at particular risk if they use libvips for Active Storage image variants and accept image uploads from untrusted users. In practical terms, a feature as ordinary as user profile image uploads or content attachments can become an entry point if the vulnerable conditions are present.
What attackers appear to be doing
Observed activity includes reconnaissance, credential probing, and command-and-control setup. VulnCheck reportedly recorded dozens of detections within hours on August 30, with the count rising into the hundreds shortly afterward. The traffic against canary systems included attempts to query environment variables, read Langflow secret material, inspect SSH-related access, and evaluate shell history.
Previous exploitation against Langflow-related vulnerabilities has also included deployment of Python credential harvesters, proxy agents, SimpleHelp remote access tooling, and cryptocurrency mining components. In one observed chain, attackers disabled auditd, creating a forensic blind spot, then dropped additional tooling and scanned for other targets. That pattern is consistent with commodity intrusion operations that combine opportunistic scanning with rapid post-exploitation monetization.
For Rails, active exploitation was also detected against canary systems in multiple regions. The concern is not limited to data exposure. If application secrets such as secret_key_base, Rails master keys, database credentials, cloud storage keys, or API tokens are obtained, attackers may be able to forge signed values, decrypt credentials, access connected services, or move from file disclosure to code execution.
Immediate actions for Langflow owners
Security teams should first determine whether Langflow is deployed anywhere in development, lab, cloud, or shadow IT environments. AI workflow systems are often spun up quickly and may not be represented in traditional asset inventories. Search cloud accounts, container platforms, developer workstations, and externally exposed services for Langflow instances.
If Langflow is internet-accessible, restrict access immediately with network controls, VPN, identity-aware proxy, or allowlists. Then upgrade to a fixed version as soon as vendor guidance is available for the affected release line. Where patching cannot be performed immediately, treat the instance as high risk: remove public exposure, rotate credentials present in environment variables or configuration files, and review logs for suspicious API calls, shell execution, outbound connections, newly written scripts, and unexpected remote access tools.
Because attackers are specifically looking for AI and cloud secrets, assume exposed keys may be compromised if they were accessible to the Langflow process. Rotate model provider API keys, cloud access keys, database passwords, Git tokens, and any credentials stored in local files, environment variables, or Langflow configuration. Review cloud audit logs for unusual API calls made with those credentials.
Immediate actions for Rails teams
Rails application owners should identify apps that use Active Storage with libvips and accept image uploads from users or other untrusted sources. Those applications deserve priority review even if they are not high-profile public services. File upload paths often exist in administrative portals, support tools, internal collaboration platforms, and customer-facing profile or attachment features.
Apply Rails security updates and vendor-recommended mitigations promptly, but do not stop there. The reporting notes that some patching may block one file-read technique while leaving concerns around signed variation keys and Marshal deserialization under specific conditions. That means teams should follow upstream Rails guidance closely, rotate secrets where exposure is possible, and invalidate or rotate signing keys if there is any evidence that secret_key_base or related credentials were accessible.
Add compensating controls around image handling: isolate processing workers, reduce privileges, block access to sensitive local files from upload processors, validate file types defensively, and monitor for abnormal variant-generation requests. Where feasible, process untrusted media in a sandboxed service rather than inside the main application environment.
Detection and response priorities
Look for requests attempting to access environment variables, Rails credentials, master keys, secret_key_base, SSH files, shell history, cloud credential files, and Langflow cache files. Monitor for unexpected outbound connections to unfamiliar infrastructure, newly installed remote access software, cryptocurrency mining processes, disabled logging services, and suspicious Python scripts.
For incident response, prioritize credential containment. Patch the vulnerable software, but also rotate exposed secrets, revoke stale tokens, review cloud IAM activity, and check whether harvested credentials were used elsewhere. A clean vulnerability scan after patching does not prove attackers failed to collect keys before the fix.
The broader lesson is that developer-facing AI and web application frameworks are now high-value targets because they concentrate credentials and automation privileges. Keep these systems off the open internet whenever possible, minimize secrets available to runtime processes, and design upload-processing paths as hostile input zones rather than trusted application features.
Source: The Hacker News source