Attackers have begun exploiting two critical weaknesses in Langflow and Ruby on Rails, moving quickly from vulnerability disclosure to live reconnaissance against internet-facing systems. The activity is especially concerning because the intruders are not merely checking whether a server is vulnerable: observed commands sought cloud credentials, application secrets and information that could support deeper access.

Langflow flaw enables unauthenticated code execution

The Langflow issue, CVE-2026-0768, affects the code validator behind the platform’s custom component editor. Langflow is commonly used to assemble AI applications, agents and automated workflows. According to telemetry described by Cyber Security News, a remote attacker may be able to run code without authenticating first, turning an exposed development tool into a direct entry point to its host.

Initial monitoring recorded more than 50 detections before the total rose to roughly 360 exploitation events. The requests attempted to collect environment variables associated with Langflow administration, OpenAI API access and Amazon Web Services credentials. Operators also probed a local Langflow secret-key file, SSH material and shell-history metadata. Together, those checks suggest an effort to map valuable access rather than immediately launch a destructive payload.

Rails exploitation creates a long-lived secret problem

A separate campaign targeted CVE-2026-66066, a critical Ruby on Rails Active Storage weakness that can progress from arbitrary file reading to remote code execution. File access can expose secret_key_base, database passwords, API tokens and cloud-storage keys. Those assets may remain useful to an attacker after the vulnerable package is updated, making patching only the first part of incident response.

For example, a stolen Rails signing secret could potentially support session forgery until the key is replaced and existing sessions are invalidated. Database or cloud credentials may also provide routes into systems beyond the original web server. The observed Rails attacks reached monitoring systems in several countries, underscoring that scanning and exploitation are not confined to a single region.

What defenders should do now

Organizations should first identify every exposed Langflow and Rails instance, including forgotten development environments and temporary test deployments. Vendor fixes should be applied urgently, while administrative and development interfaces should be placed behind trusted network controls. Internet exposure that is not required for the service should be removed.

• Search web, application and process logs for unusual requests followed by shell commands.
• Look for access to environment variables, secret files, SSH directories and shell histories.
• Rotate API keys, cloud credentials, database passwords and application signing keys that may have been readable.
• Review outbound connections and newly created users, scheduled jobs or persistence mechanisms.

Patching does not erase an intrusion

The most important operational lesson is that remediation must account for what the vulnerable process could see. AI workflow platforms often hold powerful API keys, while web frameworks sit close to databases, identity sessions and storage services. An attacker who briefly controls either application may collect credentials that open a much larger environment.

Security teams should therefore treat an exposed, vulnerable instance as potentially compromised, not simply outdated. Patch deployment, forensic review and secret rotation should proceed together. The active exploitation reported by Cyber Security News shows that defenders have little margin between public awareness of a critical flaw and attempts to turn it into durable access.

Teams should also examine whether secrets retrieved from these servers were reused elsewhere. A cloud key embedded in an application may have permissions unrelated to the workload that stored it, while an SSH key may authenticate to multiple hosts. Mapping each credential to its privileges, usage history and rotation owner helps prevent a server compromise from becoming a lingering identity problem. Coordinated ownership is vital when several engineering and cloud teams share the same application environment.