CVE-2026-33234: AutoGPT SSRF Vulnerability

CVE-2026-33234 Overview

CVE-2026-33234 is a Server-Side Request Forgery (SSRF) vulnerability in AutoGPT, a workflow automation platform for creating, deploying, and managing continuous artificial intelligence agents. The flaw affects versions 0.1.0 through 0.6.51 and resides in the SendEmailBlock component located at autogpt_platform/backend/backend/blocks/email_block.py. The block accepts user-supplied smtp_server and smtp_port values and passes them directly to Python's smtplib.SMTP() without validation. This bypasses the platform's hardened SSRF protections used by every other block. The issue is fixed in version 0.6.52.

Critical Impact

Authenticated users on shared AutoGPT deployments can perform non-blind internal network port scanning and service banner fingerprinting against private, loopback, link-local, and cloud metadata addresses.

Affected Products

• AutoGPT Platform versions 0.1.0 through 0.6.51
• SendEmailBlock component in autogpt_platform/backend/backend/blocks/email_block.py
• Shared/multi-tenant AutoGPT deployments where authenticated users can execute blocks

Discovery Timeline

• 2026-05-19 - CVE-2026-33234 published to NVD
• 2026-05-19 - Last updated in NVD database

Technical Details for CVE-2026-33234

Vulnerability Analysis

The vulnerability stems from missing input validation in AutoGPT's email block. The SendEmailBlock exposes smtp_server (string) and smtp_port (integer) as per-execution block inputs controlled by the calling user. These values flow directly into smtplib.SMTP(), which opens a raw TCP connection to the supplied host and port. The platform maintains a centralized SSRF defense in backend/util/request.py through the validate_url_host() function and a BLOCKED_IP_NETWORKS blocklist. That defense covers private, loopback, link-local, and cloud metadata ranges, but the SMTP code path never invokes it. Classified as [CWE-918] Server-Side Request Forgery, the issue allows an authenticated tenant to coerce the AutoGPT backend into initiating TCP connections to arbitrary internal endpoints.

Root Cause

The root cause is an inconsistent application of SSRF controls. The platform implements robust URL validation for HTTP-based blocks but never routes SMTP host inputs through the same validation layer. As a result, BLOCKED_IP_NETWORKS enforcement is silently bypassed for SMTP connections.

Attack Vector

An authenticated attacker configures a workflow containing SendEmailBlock and supplies an internal IP address such as 169.254.169.254, 127.0.0.1, or an RFC1918 address as smtp_server, plus any TCP port as smtp_port. When the block executes, smtplib.SMTP() connects and reads the target's TCP banner. If the connection fails or the protocol negotiation errors, smtplib embeds the captured banner in the exception message. The execution framework persists that exception as user-visible block output, turning the bug into a non-blind port scanner and service fingerprinting primitive against the deployment's internal network and cloud metadata services.

No public proof-of-concept code is required to reproduce the issue. The behavior follows directly from supplying internal targets to the block. See the GitHub Security Advisory GHSA-4jwj-6mg5-wrwf for additional technical context.

Detection Methods for CVE-2026-33234

Indicators of Compromise

• Block execution logs showing SendEmailBlock invocations with smtp_server set to private, loopback, link-local, or cloud metadata IP ranges such as 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 169.254.0.0/16.
• SendEmailBlock invocations targeting non-SMTP ports such as 22, 80, 443, 3306, 6379, or 8080.
• Persisted block output or exception messages containing TCP service banners from internal hosts.

Detection Strategies

• Parse AutoGPT execution logs and alert on any SendEmailBlock execution where smtp_server resolves to an internal or metadata address.
• Monitor outbound connections originating from the AutoGPT backend process to RFC1918, loopback, or 169.254.169.254 destinations.
• Inspect stored block outputs for non-SMTP protocol banners (for example, SSH-2.0, HTTP response strings) that indicate fingerprinting activity.

Monitoring Recommendations

• Enable verbose audit logging for all block executions and retain inputs alongside outputs for forensic review.
• Forward AutoGPT backend network telemetry to a centralized SIEM and create rules for backend-to-internal-asset traffic on unexpected ports.
• Correlate per-user block execution volume to identify accounts performing systematic scans across IP ranges.

How to Mitigate CVE-2026-33234

Immediate Actions Required

• Upgrade AutoGPT to version 0.6.52 or later, which routes SMTP host inputs through validate_url_host() and the BLOCKED_IP_NETWORKS blocklist.
• Audit existing workflows for SendEmailBlock usage and review historical execution outputs for evidence of internal scanning.
• Restrict authenticated access to shared AutoGPT deployments until the patch is applied.

Patch Information

The maintainers fixed the vulnerability in AutoGPT platform release autogpt-platform-beta-v0.6.52. The patch applies the existing SSRF validation logic to the SMTP host and port inputs of SendEmailBlock. Release notes are available at the GitHub AutoGPT Release Note and the advisory at GHSA-4jwj-6mg5-wrwf.

Workarounds

• Disable or remove SendEmailBlock from available blocks until upgrade is possible.
• Apply egress network controls on the AutoGPT backend to deny connections to RFC1918, loopback, link-local, and cloud metadata IP ranges.
• Run the AutoGPT backend in a network segment that has no route to sensitive internal services or instance metadata endpoints.

# Example egress restriction using iptables on the AutoGPT backend host
iptables -A OUTPUT -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -d 127.0.0.0/8 ! -o lo -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -j REJECT