AI Development Tool Network Exposure Audit: 12-Point Security Checklist for Langflow, Marimo, Jupyter, and Ollama
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
AI development tools are the fastest-growing unauthenticated RCE attack surface in enterprise environments. Langflow, Marimo, Jupyter Notebook, Ollama, LocalAI, and similar platforms all share a common design characteristic: they execute code or process complex inputs by design. That makes network exposure a direct path to arbitrary code execution.
Both recent critical vulnerabilities in this category exploited simple misconfigurations: Langflow CVE-2025-34291 was exploited against internet-accessible instances; Marimo CVE-2026-39987 was an unauthenticated WebSocket endpoint on any instance reachable from an untrusted network. Neither required a sophisticated attack. Both resulted in full system compromise.
This checklist covers discovery, exposure assessment, and remediation for the four most commonly deployed AI development tools in enterprise environments.
Discovery: Find Every AI Tool Running in Your Environment
You cannot audit what you have not found. AI tools are frequently installed by developers without IT visibility, often on cloud VMs, in Kubernetes namespaces, or on developer workstations with port forwarding.
Check 1: Scan internal networks for known AI tool ports.
Default ports to scan:
- Langflow: 7860 (development), 7861 (secondary), 443 (if behind reverse proxy)
- Marimo: 2718 (default), 2719, 8080 (if behind reverse proxy)
- Jupyter Notebook/Lab: 8888 (default), 8889, 9999
- Ollama: 11434
- LocalAI: 8080
- Open WebUI: 3000, 8080
nmap -p 7860,7861,2718,2719,8888,8889,9999,11434,3000 10.0.0.0/8 --open -oG ai_tool_scan.txt
Also search cloud environments:
# AWS: find security groups allowing these ports from 0.0.0.0/0
aws ec2 describe-security-groups \
--query 'SecurityGroups[?IpPermissions[?contains(to_string(FromPort), `7860`) || contains(to_string(FromPort), `8888`) || contains(to_string(FromPort), `11434`)]].[GroupId,GroupName]'
Check 2: Search endpoint management for AI tool processes.
In your EDR or MDM:
# Search for process names
langflow, marimo, jupyter, ollama, localai, open-webui, stable-diffusion-webui, comfyui
Also search for the Python interpreter running with these tool names as arguments. Developers frequently launch them via python -m langflow run or python -m jupyter notebook.
Check 3: Audit cloud Kubernetes namespaces.
kubectl get services --all-namespaces | grep -E '7860|8888|11434|2718|3000'
kubectl get ingress --all-namespaces | grep -E 'langflow|marimo|jupyter|ollama'
Langflow: Audit and Remediation
Langflow is an AI workflow builder with a web UI that executes arbitrary code through its node execution engine. CVE-2025-34291 allowed unauthenticated remote code execution through the API. MuddyWater (Iran-nexus APT) actively exploited public instances.
Check 4: Verify Langflow is not internet-accessible.
From outside your network, attempt:
curl -s https://[your-domain]/api/v1/flows/ -o /dev/null -w "%{http_code}"
A 200 response from an unauthenticated request means your Langflow instance is exposed with no authentication.
Also check: does your Langflow instance bind to 0.0.0.0 or to 127.0.0.1?
ss -tlnp | grep 7860
# Should show 127.0.0.1:7860, not 0.0.0.0:7860
Check 5: Verify authentication is enforced.
Langflow requires explicit configuration to enable authentication. Check your startup configuration:
langflow run --help | grep auth
# or check environment variables:
env | grep -i LANGFLOW_AUTO_LOGIN
LANGFLOW_AUTO_LOGIN=true disables the login requirement and should never be set on any network-accessible instance.
Remediation:
- Update to Langflow 1.1.0 or later (patches CVE-2025-34291)
- Set
LANGFLOW_AUTO_LOGIN=falseand configure user accounts - Bind to 127.0.0.1 if no reverse proxy:
langflow run --host 127.0.0.1 - If a reverse proxy is required, require authentication at the proxy layer (Nginx:
auth_basic, Cloudflare Access, or similar) - Block external access at firewall level for all instances not requiring external access
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Marimo: Audit and Remediation
Marimo is a reactive Python notebook that CVE-2026-39987 turned into an unauthenticated remote code execution vector via its /terminal/ws WebSocket endpoint. An LLM agent exploiting this vulnerability exfiltrated AWS credentials and an SSH private key, then drained an internal PostgreSQL database, all in under two minutes.
Check 6: Find any internet-accessible Marimo instances.
Scan for the Marimo WebSocket terminal endpoint specifically:
curl -s -o /dev/null -w "%{http_code}" http://[host]:2718/terminal/ws \
-H "Upgrade: websocket" -H "Connection: Upgrade" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
-H "Sec-WebSocket-Version: 13"
A 101 (Switching Protocols) response means the WebSocket endpoint is open and unauthenticated. This is the exact attack vector for CVE-2026-39987.
Check 7: Verify no Marimo processes bind to 0.0.0.0.
find / -name "coreaudiod" -not -path "/usr/sbin/coreaudiod" 2>/dev/null
This command detects a specific post-exploitation artifact from CVE-2026-39987 exploitation. The Marimo exploit replaced coreaudiod with malware. Any result from this command on a system running Marimo indicates active compromise.
Also check the Marimo process binding:
ss -tlnp | grep 2718
ps aux | grep marimo
Remediation:
- Update to Marimo 0.23.0 or later (patches CVE-2026-39987)
- Launch with
--host 127.0.0.1to bind only to localhost - Block
/terminal/wsat any reverse proxy or firewall in front of Marimo - Rotate all credentials (AWS, SSH keys, database passwords) on any host that ran a vulnerable version and was network-accessible
Jupyter Notebook and JupyterLab: Audit and Remediation
Jupyter is the most widely deployed AI development tool in enterprise environments and also the most frequently misconfigured. Unlike Langflow and Marimo (which have specific recent CVEs), Jupyter's risk is primarily architectural: it executes arbitrary code by design, and many deployments have weak or no authentication.
Check 8: Find Jupyter instances without token or password authentication.
curl -s http://[host]:8888/api/kernels -o /dev/null -w "%{http_code}"
A 200 response means the Jupyter instance is running without authentication. An attacker can create a kernel and execute arbitrary Python.
Also check the Jupyter config for authentication settings:
jupyter notebook --show-config 2>/dev/null | grep -E 'token|password|ip|open_browser'
# Or check the config file:
cat ~/.jupyter/jupyter_notebook_config.py | grep -E 'token|password|ip'
Look for c.NotebookApp.token = '' (empty token) or c.NotebookApp.password = '' with c.NotebookApp.ip = '0.0.0.0'.
Check 9: Verify Jupyter is not bound to a public interface.
ss -tlnp | grep 8888
The Jupyter process should show 127.0.0.1:8888, not 0.0.0.0:8888 or *:8888.
Remediation:
- Always launch with explicit localhost binding:
jupyter notebook --ip=127.0.0.1 - Use JupyterHub for multi-user deployments (provides authentication layer)
- For remote access, use SSH port forwarding rather than binding to a public interface:
ssh -L 8888:localhost:8888 user@server - Set a strong token or password:
jupyter notebook password - For cloud deployments, require authentication at the load balancer or ingress layer before traffic reaches Jupyter
Ollama: Audit and Remediation
Ollama serves local LLM models through a REST API. By default, the Ollama API is unauthenticated and accepts requests from any client that can reach port 11434. This is intentional for local development but becomes an attack vector in any environment where the port is network-accessible.
Check 10: Verify Ollama API is not externally accessible.
curl -s http://[host]:11434/api/tags | head -c 200
A JSON response listing installed models means the Ollama API is unauthenticated and accessible. From an internal network perspective, any system that can reach this endpoint can:
- List all models installed
- Pull additional models (potentially very large, constituting a denial-of-service)
- Generate completions that could be used to probe for sensitive context
- In multi-agent setups, redirect model responses to feed downstream agents
Check 11: Verify Ollama binding.
ss -tlnp | grep 11434
# On macOS:
lsof -i :11434
Ollama binds to 127.0.0.1 by default. If it shows 0.0.0.0 or a specific network interface IP, the service has been explicitly configured or a firewall rule is missing.
Remediation:
- Set
OLLAMA_HOST=127.0.0.1environment variable to restrict binding - For cloud deployments that require remote access, implement a reverse proxy with authentication (Nginx basic auth as a minimum; Cloudflare Access or similar for production)
- Add a firewall rule blocking external access to port 11434
- For Kubernetes deployments, do not expose the Ollama service type as LoadBalancer or NodePort
Organization-Wide Controls
Beyond per-tool configuration, these organization-level controls reduce AI tool exposure systematically.
Check 12: Establish an AI tool registration and approval process.
The root cause of AI tool exposure in most organizations is that tools are deployed by individual developers or teams without security review. Establish a lightweight process:
- Require registration of any AI development tool accessible beyond the developer's own workstation
- Define approved deployment patterns (localhost only, or behind specific authenticated reverse proxy configurations)
- Add AI tool ports to your perimeter scan schedule so new deployments are detected automatically
- Include AI tool version checks in your vulnerability management program since these tools ship new CVEs frequently
Crawl your cloud environment weekly for the port list in Check 1. Any new hit requires immediate review before the next business day. This single automated check would have identified both the Langflow and Marimo exposures that led to active exploitation in 2026.
The bottom line
Langflow CVE-2025-34291 and Marimo CVE-2026-39987 were both trivially exploited because the tools were accessible from untrusted networks. The fix in both cases required one configuration change: binding to localhost or adding an authenticated reverse proxy. The harder problem is organizational: AI tools are deployed faster than security teams discover them. Automated port scanning for AI tool default ports, run weekly against your cloud environments and internal subnets, is the single highest-leverage control in this category.
Frequently asked questions
Is Langflow safe to use after patching CVE-2025-34291?
Patching to Langflow 1.1.0 or later closes CVE-2025-34291 specifically. Whether Langflow is safe to expose to the internet after patching depends on your authentication configuration. Langflow's execution model involves running code through a web interface by design. Even a fully patched instance should require authentication and should ideally be restricted to internal networks or accessed through a VPN. Do not assume patch plus public internet exposure is an acceptable configuration for any code execution platform.
Can an attacker do anything useful with access to the Ollama API?
An unauthenticated Ollama API exposes model inference, model management (pull and delete), and in some configurations the ability to read conversation history. In a standalone deployment, the most immediate risk is unauthorized model use and the ability to pull large models that fill disk space. In multi-agent or RAG architectures where Ollama is one component, compromising the model inference layer can allow an attacker to inject malicious responses into automated decision pipelines or extract data from the context window of an active session.
Do these tools expose risks in containerized environments?
Yes, and containerization can create a false sense of security. A Docker container running Jupyter or Langflow with a published port (-p 8888:8888 or similar) exposes the same risk as running it directly on a host. Container network policies need to explicitly restrict which source IPs can reach AI tool ports. In Kubernetes, default network policies allow all pod-to-pod communication within a cluster, meaning a compromised application pod can reach any AI tool running elsewhere in the cluster even if the service has no external LoadBalancer.
What should I do if I find a Langflow or Marimo instance that has been exposed?
Treat it as a presumed compromise incident. Take the instance offline immediately. Collect any available logs from the tool and the host. Rotate all credentials that were accessible from that environment: cloud provider credentials, API keys in environment variables, database passwords, and SSH keys. Examine the host for post-exploitation artifacts using the commands in the Marimo section (coreaudiod process, new cron jobs, new authorized SSH keys, unusual network connections). Review cloud provider audit logs for API activity from credentials that were accessible on that host.
How do I scan my organization for exposed AI development tools on the network?
Scan your internal network for default AI tool ports: 7860 (Gradio/common AI app default), 8888 (Jupyter), 7681 (Langflow), 3000 (Marimo), 11434 (Ollama API). Use nmap: nmap -p 7860,8888,7681,3000,11434 --open 10.0.0.0/8. For internet-facing exposure, search your IP ranges on Shodan using the filter 'port:11434' (Ollama) or 'http.favicon.hash:...' for specific tool UIs. Also scan for default credentials: Jupyter instances with token='' or no password prompt, and Langflow instances accessible without authentication. Include AI tool port scanning in your quarterly external attack surface assessment alongside standard web port scans.
How do you implement a secure multi-user AI development environment that gives data science teams the access they need without creating unauthenticated RCE exposure?
The architecture that balances access and security for multi-user AI development environments has four required components. First, a centralized authentication gateway -- JupyterHub for Jupyter-based workflows, or an authenticated reverse proxy using Cloudflare Access, Authelia, or OAuth2 Proxy with your existing identity provider for Langflow and Marimo -- ensures no tool endpoint is reachable without a valid identity assertion. Second, network segmentation that places all AI development infrastructure in a dedicated VLAN or Kubernetes namespace with egress rules that permit only specific outbound destinations: PyPI, Hugging Face Hub, your internal artifact registry, and approved API endpoints. Blanket internet egress from compute nodes that execute arbitrary code is what turns a credential theft into a broad data exfiltration. Third, per-user isolated compute: JupyterHub's spawner configuration can launch a separate container per user so one user's kernel cannot access another user's filesystem or environment variables. Fourth, secrets management that injects API keys and database credentials at runtime via a vault integration rather than storing them in notebook files or environment variable exports that persist in container images. With these four components, data science teams get persistent, self-service access while your attack surface for each tool category in this checklist is eliminated at the architecture level rather than through per-instance configuration.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.