PraisonAI praisonaiagents 1.6.77 Unauthenticated Remote Code Execution — Detection and Remediation Guide

Security Arsenal is issuing this advisory following the public release of exploit code for an unauthenticated remote code execution (RCE) vulnerability in PraisonAI's praisonaiagents package, version 1.6.77 (documented at Exploit-DB #52639). PraisonAI is an increasingly popular open-source framework for orchestrating multi-agent AI workflows, and its server components are frequently stood up by developers and data science teams — often directly on internet-facing infrastructure, inside cloud notebooks, or as internal microservices with little to no network segmentation.

An unauthenticated RCE in this class of tooling is a worst-case scenario for defenders: AI agent frameworks typically run with access to sensitive API keys (OpenAI, Anthropic, cloud providers), internal data sources, vector databases, and sometimes shell tools the agents themselves are allowed to invoke. A single unauthenticated request that yields code execution on the host collapses the entire trust boundary of your AI pipeline. With public exploit code now available, any exposed instance should be assumed to be scanned and targeted within hours, not weeks.

No CVE identifier has been assigned to this issue at the time of writing, and the vendor has not shipped a confirmed fixed release. That means your defensive posture today rests on identification, isolation, and detection — not patching.

Technical Analysis

Affected Products and Versions

• Product: PraisonAI praisonaiagents Python package
• Affected version: 1.6.77 (and, until vendor confirmation, treat all adjacent versions in the 1.6.x line as suspect)
• Deployment models at risk:
  • Standalone PraisonAI API/agent servers (commonly launched via the praisonai CLI or a uvicorn/flask-style embedded server)
  • Docker containers exposing the PraisonAI web or API interface
  • Cloud-hosted notebooks and demo servers bound to 0.0.0.0
  • Internal agent microservices reachable from less-trusted network zones

How the Vulnerability Works (Defender's Perspective)

Based on the published proof-of-concept, the vulnerability allows a remote, unauthenticated attacker to achieve code execution by sending a crafted request to an exposed PraisonAI agent endpoint. The underlying pattern is one we see repeatedly in AI/LLM frameworks: an API endpoint accepts user-supplied input that is passed — with insufficient validation — into a code-evaluation, template-rendering, or tool-invocation path inside the Python runtime. Because the agent server is designed to execute dynamic instructions on behalf of LLM workflows, the trust boundary between "data from the network" and "code the interpreter will run" is dangerously thin.

Key exploitation characteristics defenders should internalize:

• No authentication required. Any client that can reach the listening port can attempt exploitation.
• Exploitation is request-driven. The initial indicator of compromise is an inbound HTTP request to the PraisonAI service containing unusual payloads (Python builtins, os., subprocess, __import__, eval, exec, base64 blobs) from a source that has no business talking to your agent infrastructure.
• Post-exploitation runs under the PraisonAI service account. Whatever API keys, environment variables, mounted secrets, and network reachability the agent host has, the attacker inherits. In AI deployments this is frequently catastrophic: cloud credentials, LLM provider keys, database connection strings, and sometimes agent-authorized shell tools.
• Python process spawning shells is the canonical post-exploitation signal. A python/python3/uvicorn process that suddenly spawns cmd.exe, powershell.exe, /bin/sh, /bin/bash, curl, wget, or a reverse-shell interpreter is the highest-fidelity detection you can build.

Exploitation Status

• Public PoC: Yes — exploit code is published on Exploit-DB (#52639). Treat exploitation as trivially accessible to low-skill attackers.
• CISA KEV: Not listed at time of writing (no CVE assigned).
• Vendor patch: No confirmed fixed release at time of writing. Monitor the PraisonAI GitHub repository and PyPI release history for praisonaiagents.
• Internet exposure: Expect automated scanning. AI framework ports and endpoints are actively enumerated by opportunistic botnets and initial access brokers.

Detection & Response

The detections below target the full attack lifecycle: the inbound exploit request, the post-exploitation process chain, and the outbound connections an implant will make. Deploy all of them — any single layer alone will miss real intrusions.

Sigma Rules

---
title: PraisonAI Python Process Spawning Shell or Downloader
id: 3f9a2b71-6c44-4e8d-9a21-7b5c1d0e8f42
status: experimental
description: Detects a Python/uvicorn process (typical of PraisonAI agent servers) spawning shells, script interpreters, or download utilities — the canonical post-exploitation behavior of unauthenticated RCE in Python web frameworks.
references:
  - https://www.exploit-db.com/exploits/52639
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.execution
  - attack.t1059
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\python.exe'
      - '\python3.exe'
      - '\uvicorn.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\curl.exe'
      - '\wget.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate AI agent tools authorized to invoke system commands (review and allowlist by exact CommandLine hash)
  - Developer workstations running local agent test harnesses
level: high
---
title: Linux Python Web Process Spawning Shell
id: 8c1d4e62-2a97-4b53-bf38-9e0a6c2d41b7
status: experimental
description: Detects python/python3/uvicorn processes spawning interactive shells or download tools on Linux — consistent with post-exploitation of an RCE in a Python-based agent server such as PraisonAI praisonaiagents.
references:
  - https://www.exploit-db.com/exploits/52639
  - https://attack.mitre.org/techniques/T1059.004/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.execution
  - attack.t1059.004
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/python'
      - '/python3'
      - '/uvicorn'
      - '/gunicorn'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/socat'
      - '/perl'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Agent frameworks explicitly granted shell tools — baseline expected tool invocations and alert on deviations
level: high
---
title: Suspicious Inbound Payload to AI Agent HTTP Endpoint
id: b47e0f39-1d58-4c6a-a692-5f8e3b07d256
status: experimental
description: Detects inbound web requests to AI agent service ports containing Python code-execution primitives (eval, exec, __import__, os.system, subprocess) in the request body — indicative of exploitation attempts against PraisonAI and similar LLM agent frameworks.
references:
  - https://www.exploit-db.com/exploits/52639
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_payload:
    cs-request-body|contains:
      - '__import__'
      - 'os.system'
      - 'os.popen'
      - 'subprocess.'
      - 'eval('
      - 'exec('
      - 'base64.b64decode'
  condition: selection_payload
falsepositives:
  - Legitimate agent prompts discussing Python code — tune to POST method only and require remote (non-RFC1918 or non-approved) source IPs where possible
level: medium

KQL — Microsoft Sentinel / Defender

This query hunts the post-exploitation process chain across Windows and Linux endpoints ingested into Sentinel, and also surfaces network connections from Python interpreter processes to external infrastructure — a strong reverse-shell and payload-staging signal. Tune the parent process list to match how PraisonAI is launched in your environment (check your container images and systemd units).

let SuspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "certutil.exe", "curl.exe", "wget.exe", "mshta.exe", "rundll32.exe", "/bin/sh", "/bin/bash", "/usr/bin/curl", "/usr/bin/wget", "/usr/bin/nc", "ncat", "socat"]);
union withsource=tableName *
| where tableName in ("DeviceProcessEvents", "SecurityEvent", "Syslog")
| extend ParentProc = coalesce(InitiatingProcessFileName, tostring(split(Process, " ")[0]), "")
| extend ChildProc = coalesce(FileName, Process, "")
| extend CmdLine = coalesce(ProcessCommandLine, CommandLine, "")
| where ParentProc has_any ("python", "uvicorn", "gunicorn", "praisonai")
| where ChildProc has_any (SuspiciousChildren)
    or CmdLine has_any ("__import__", "os.system", "subprocess", "base64 -d", "b64decode", "/dev/tcp/")
| project TimeGenerated, tableName, DeviceName, Computer, AccountName, ParentProc, ChildProc, CmdLine, InitiatingProcessCommandLine, RemoteIP
| order by TimeGenerated desc

For network-layer hunting (outbound connections from the agent server — reverse shells, C2, payload retrieval), run this against Defender network events or firewall CEF logs:

DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName has_any ("python", "python3", "uvicorn", "praisonai")
| where RemoteIPType == "Public"
| where RemotePort !in (443, 80) or RemoteUrl !has_any ("api.openai.com", "api.anthropic.com", "pypi.org", "github.com")
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, RemotePort
| order by FirstSeen desc

Velociraptor VQL

Use this hunt artifact across your fleet to identify PraisonAI deployments (so you know what to isolate) and to flag live Python processes with suspicious child processes or suspicious outbound connections. The first query inventories exposure; the second hunts active compromise.

-- Inventory PraisonAI deployments and flag suspicious python process activity
LET inventory = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'praisonai|praisonaiagents'
   OR Exe =~ '(?i)praisonai'

LET suspicious = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)^(python|python3|uvicorn|gunicorn)'
   AND CommandLine =~ '(?i)(__import__|os\.system|subprocess|base64|socket|pty\.spawn|/dev/tcp)'

SELECT * FROM inventory
UNION ALL
SELECT * FROM suspicious

Pair it with a live netstat check to catch established reverse shells from agent hosts:

-- Find outbound connections owned by python processes (possible reverse shells / C2)
SELECT Pid, Name, Status, LocalAddr, LocalPort, RemoteAddr, RemotePort
FROM netstat()
WHERE Name =~ '(?i)python|uvicorn|praisonai'
  AND Status =~ 'ESTABLISHED'
  AND NOT RemoteAddr =~ '^(127\.|10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|::1)'

Remediation & Hardening Script

Until a patched praisonaiagents release is available, the script below (Bash, for the Linux/container hosts where PraisonAI typically runs) does three things: identifies exposed PraisonAI listeners, verifies the installed package version, and applies compensating network controls to restrict access to the service port. Run it on every host and container node where PraisonAI may be deployed.

#!/bin/bash
# Security Arsenal — PraisonAI praisonaiagents 1.6.77 RCE exposure check & containment
# Run as root on any host that may run PraisonAI agent servers.

set -u
echo "=== [1/4] Checking installed praisonaiagents version ==="
PIP_VER=$(python3 -m pip show praisonaiagents 2>/dev/null | grep -i '^Version' || echo "not installed via pip")
echo "praisonaiagents: $PIP_VER"
# If version is 1.6.77 (or unpatched), treat the host as exposed.

echo "=== [2/4] Identifying listening PraisonAI / python web services ==="
ss -tlnp 2>/dev/null | grep -Ei 'python|uvicorn|gunicorn|praisonai' || echo "No python web listeners found."

echo "=== [3/4] Checking for internet-facing bindings (0.0.0.0) ==="
ss -tlnp 2>/dev/null | grep '0.0.0.0' | grep -Ei 'python|uvicorn|gunicorn' && \
echo "!! WARNING: Agent service bound to 0.0.0.0 — isolate immediately." || echo "OK: no wildcard-bound python services."

echo "=== [4/4] Applying compensating controls ==="
# Adjust the port to your PraisonAI deployment (common defaults: 8080, 8000, 5000).
AGENT_PORT=8080
# Allow only your trusted management subnet to reach the agent service.
TRUSTED_SUBNET="10.0.0.0/8"
iptables -C INPUT -p tcp --dport "$AGENT_PORT" -s "$TRUSTED_SUBNET" -j ACCEPT 2>/dev/null || \
iptables -I INPUT -p tcp --dport "$AGENT_PORT" -s "$TRUSTED_SUBNET" -j ACCEPT
iptables -C INPUT -p tcp --dport "$AGENT_PORT" -j DROP 2>/dev/null || \
iptables -A INPUT -p tcp --dport "$AGENT_PORT" -j DROP
echo "Applied: port $AGENT_PORT restricted to $TRUSTED_SUBNET; all other sources dropped."

echo "=== Done. Next: rotate any API keys/secrets in the service environment if exposure is confirmed. ==="

Remediation

Given there is no patched release and no assigned CVE at the time of writing, treat this as an active exposure-management problem, not a patch-Tuesday item.

1. Inventory immediately. Find every praisonaiagents installation: pip show praisonaiagents, container image scans, notebook environments, developer workstations, and any server running a praisonai/uvicorn process. You cannot protect what you haven't found — AI tooling is routinely deployed outside formal change management.
2. Take exposed instances offline or behind controls. If an instance is reachable from the internet or from untrusted network segments, remove that reachability today. Bind to 127.0.0.1 where possible, place the service behind an authenticated reverse proxy (mTLS or SSO-gated), and enforce firewall allowlists as shown in the script above.
3. Assume compromise for internet-exposed instances. For any instance that was publicly reachable since the PoC publication, run the detection queries above across the full exposure window, not just the last 24 hours. Look for python-spawned shells, unexpected outbound connections, new files in the service working directory, and modified agent configuration/tool definitions.
4. Rotate secrets — this is the critical step most teams miss. PraisonAI deployments almost always carry LLM provider API keys (OpenAI, Anthropic, etc.), cloud credentials, and database connection strings in environment variables or config files. If an instance was exposed and potentially exploited, rotate every secret in that environment. Review your LLM provider and cloud billing/usage logs for anomalous consumption — stolen AI API keys are monetized within hours.
5. Monitor vendor channels for a fix. Watch the PraisonAI GitHub repository and the praisonaiagents PyPI release history for a patched version; upgrade and re-verify immediately upon release. Subscribe to the Exploit-DB entry for updates and check CISA KEV periodically in case a CVE is assigned and confirmed exploited.
6. Harden AI agent architecture going forward. Run agent frameworks in dedicated, egress-restricted containers or VMs; strip shell-tool permissions agents don't strictly need; enforce egress filtering so a compromised agent host cannot reach arbitrary internet destinations; and apply the principle that an AI agent server is a remote code execution engine by design and must be segmented accordingly.
7. Add AI/LLM infrastructure to your attack surface management scope. Agent frameworks, vector databases, model-serving endpoints, and notebook servers are the fastest-growing unauthenticated-RCE surface in enterprise environments. They must appear in your external scans, asset inventory, and vulnerability management SLAs.

The defensive lesson here extends beyond PraisonAI: the AI tooling ecosystem is shipping networked services with developer-grade security assumptions, and attackers have noticed. Treat every exposed agent endpoint as a pre-authentication shell waiting to be found.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub