Two critical vulnerabilities are being actively exploited right now. One is in Langflow — the popular low-code platform for building AI agents and workflows. The other is in Ruby on Rails’ Active Storage image processing pipeline. Attackers are not deploying ransomware. They are not enrolling servers into botnets. They are specifically hunting your OPENAI_API_KEY, your AWS credentials, and your Rails signing secrets. In some cases, they had private exploits before any public proof-of-concept existed.
Langflow: CVSS 9.8, No Authentication Required
CVE-2026-0768 affects Langflow 1.4.2 and earlier. The flaw lives in the validate endpoint, which Langflow uses for its custom component editor. The endpoint accepts a code parameter and executes it as Python — with no authentication check. An attacker sends a POST request, arbitrary Python runs as root, and the server is theirs.
VulnCheck recorded over 50 detections within hours of August 30, rising to 360 by September 1 — with no public proof-of-concept in circulation. That means a private exploit is in use. The credential harvest follows a predictable script: query OPENAI_API_KEY, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, read /root/.cache/langflow/secret_key, pull ~/.ssh, scan .bash_history, exfiltrate. Lateral movement via SSH follows if the harvest yields usable keys.
This is not Langflow’s first security failure. CVE-2025-3248 seeded cryptomining botnets. CVE-2026-0769 racked up 15,000+ successful exploitation attempts. CVE-2026-5027 deployed credential harvesters. JFrog’s security team previously found that Langflow’s “fixed” version for CVE-2026-33017 was still exploitable after patching. The pattern is clear: Langflow ships fast and patches poorly. If you are running an internet-facing Langflow instance with OpenAI or AWS keys in the environment, you should assume that window is closing.
Ruby on Rails: Image Upload to Full Server Compromise
CVE-2026-66066, nicknamed KindaRails2Shell, carries a CVSS score of 9.5. The attack is more surgical than the Langflow one. An attacker uploads a crafted image to any Rails application using Active Storage with libvips for image processing. When Rails generates a variant — a thumbnail, a resized version, anything — libvips processes the file through “unfuzzed” loaders that were never hardened against malicious input. The result is arbitrary file read on the server.
File read becomes full compromise through credential theft. The attacker reads secret_key_base from the process environment or config files, which allows forging valid Rails session cookies. From there, cookie deserialization chains become available, and the path to remote code execution is straightforward. The stolen secrets — RAILS_MASTER_KEY, database credentials, S3/GCS/Azure storage keys, API tokens — remain valid even after you patch. HeroDevs’ analysis is unambiguous: patching is necessary but not sufficient.
Rails 7.0 made config.active_storage.variant_processor = :vips the default, which explains why the exposure surface is so wide. VulnCheck counted 7,100+ internet-facing Rails instances as of August. The patch exists — Rails 7.2.3.2, 8.0.5.1, and 8.1.3.1 — but there is a catch: the fix only works if libvips 8.13 or later is installed. Many production environments run older system libvips that will not receive this version through standard package repos without manual intervention. Rails 7.1, 7.0, and 6.x receive no upstream fix at all.
Why AI Keys Are the Prize
This is not incidental. Attackers are querying OPENAI_API*, AWS_ACCESS*, and AWS_SECRET* by name — not dumping all environment variables indiscriminately. OpenAI API keys can rack up thousands of dollars in inference charges before the victim notices and revokes them. AWS credentials open a path into the full cloud environment. AI platform operators are running environments loaded with high-value API credentials and doing it with less security discipline than the banking sector.
Langflow in particular is popular with developers who prototype AI agents quickly. Fast prototypes become production deployments without the security review those environments warrant. The result is internet-facing Langflow instances with root-accessible Python execution and OpenAI keys sitting in environment variables. That is a very attractive combination for an attacker running a private exploit.
What to Do Right Now
For Langflow: update past 1.4.2 immediately. If your Langflow admin interface is reachable from the internet, put it behind a VPN or auth proxy today — before the update is applied. Given Langflow’s history of incomplete patches, treat the update as a temporary measure and rotate every credential in that environment regardless.
For Rails: upgrade to 7.2.3.2, 8.0.5.1, or 8.1.3.1 and confirm your system libvips is 8.13 or later. Run bundle update rails --conservative to limit collateral updates. Update ruby-vips to 2.2.1+ if you use it directly. If you cannot upgrade immediately, set VIPS_BLOCK_UNTRUSTED=1 as an environment variable — this blocks the exploit on libvips 8.13+ systems. For Rails 7.1 and older, there is no upstream patch. The full patch release notes cover the specifics.
In both cases: rotate secret_key_base, master key, all S3/GCS/Azure keys, database credentials, and every API token the application process could read. Patching without rotation leaves any already-stolen credentials valid indefinitely. Check server logs for POST requests to Langflow’s /api/v1/validate endpoint, unusual environment variable queries, and outbound connections to unexpected destinations. The 360-detection count is from canary systems alone. The real exploitation surface is substantially larger.
Immediate Action Checklist
- Langflow: Update to latest version (past 1.4.2), restrict admin interface to VPN/auth proxy
- Rails: Patch to 7.2.3.2, 8.0.5.1, or 8.1.3.1 — verify libvips 8.13+ is installed
- Temporary Rails mitigation: Set
VIPS_BLOCK_UNTRUSTED=1if immediate upgrade is not possible - Rotate all credentials:
secret_key_base, master key, database passwords, S3/GCS/Azure keys, all API tokens - Audit logs: Look for POST to
/api/v1/validate, env var reads, unexpected outbound connections - Rails 7.1 and older: No upstream patch — implement alternative mitigation or backport













