Yesterday we walked through how CVE-2026-66066 - "KindaRails2Shell" - lets an unauthenticated attacker read a Rails application's secret key through a malformed file upload. We wrote it up as a mechanism worth understanding, not yet a live incident. It turns out that framing was already out of date: according to The Hacker News, citing research from VulnCheck, the same bug was being actively probed against honeypot systems days before our piece went live - alongside a second, entirely unrelated critical flaw in Langflow, the open-source AI agent-building platform.
Two bugs, no shared codebase, one shared moment
There's no supply chain link between Rails and Langflow, and no evidence the same crew is behind both campaigns. What connects them is timing and opportunity: VulnCheck's VP of threat research, Caitlin Condon, described the activity as attackers "conducting a mix of reconnaissance and credential harvesting" - the kind of broad, automated sweep that treats any newly weaponisable CVE as worth a try, regardless of what the underlying software does. The Langflow flaw, CVE-2026-0768, was actually disclosed by Trend Micro's Zero Day Initiative back on 9 January 2026 and affects Langflow 1.4.2 and earlier - it's been patchable for nearly eight months, which makes its reappearance in live attack traffic this week less a fresh zero-day story and more a patching-discipline one.
What the honeypots actually recorded
The specifics are unglamorous in exactly the way real credential theft usually is. Attackers queried environment variables including LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS* and AWS_SECRET*, read the cached secret key at /root/.cache/langflow/secret_key, and checked for SSH access and the size of .bash_history - a shopping list for anyone hoping to pivot from a compromised AI workflow server into whatever cloud accounts and model API budgets it was configured to use. VulnCheck logged more than 50 detections within hours on 30 August, rising past 360 by the following day.
A French IP, an Israeli C2, and canaries in three countries
The geography is a useful reminder of how little source IPs tell you on their own. One cluster of activity traced to a single IP address in France, with command-and-control infrastructure reached in Israel; a separate cluster of traffic, sourced mostly from Russia, hit canary systems exclusively in the UK. Vulnerable, internet-facing hosts turned up concentrated in the US, Germany, Malaysia, Brazil and India. None of that geography should be read as attribution - infrastructure gets rented, proxied and abandoned faster than any of it can be mapped to a specific group - but it does illustrate the scale: this isn't one actor with one target, it's a landscape of opportunistic scanning that a newly public CVE, or a newly popular writeup of one, seems to accelerate rather than create.
The lesson isn't "don't write about CVEs"
It would be easy to draw the wrong conclusion here - that publicity around a vulnerability causes its exploitation. It doesn't; VulnCheck's honeypots caught this activity independently of any one outlet's coverage, and the underlying scanning infrastructure for both bugs was almost certainly already probing before either bug had a nickname. The actual lesson is the boring, familiar one: the gap between "a vendor shipped a patch" and "every internet-facing instance applied it" is measured in months, not days, and that gap is precisely where this kind of automated credential harvesting lives. We've made a similar point about an earlier Langflow CVE that stayed exploitable weeks after IBM's same-day fix, and about the identity sprawl created when AI agent platforms accumulate cloud and API credentials nobody's tracking closely.
- Treat "patched eight months ago" as no guarantee of "patched everywhere" - inventory internet-facing Langflow, Rails and similar framework instances against current versions now, not after a KEV listing forces the question.
- Rotate and scope down API keys and cloud credentials stored in environment variables on any AI agent or workflow server exposed to the internet.
- Monitor for the specific recon pattern here - environment variable enumeration, cached secret file reads, SSH and bash history checks - as a signal worth alerting on even before code execution succeeds.
- Don't over-index on source IP geography when triaging alerts; treat it as a data point for scale, not a conclusion about who's responsible.
- Assume any newly documented critical CVE, however old the underlying flaw, is being scanned for somewhere within days - patch cadence needs to assume that baseline, not react to it.
If you'd like help auditing which of your internet-facing platforms are still running against CVEs that were patched months ago, or tightening how AI agent servers store the credentials they depend on, email sales@halfteck.com.