CVE-2024-1879 Overview
CVE-2024-1879 is a Cross-Site Request Forgery (CSRF) vulnerability in significant-gravitas/autogpt version 0.5.0. The flaw allows attackers to execute arbitrary commands on the AutoGPT server when a victim running AutoGPT on their local network visits a malicious website. The API endpoint receiving instructions lacks CSRF protections, and Cross-Origin Resource Sharing (CORS) is enabled for arbitrary origins by default. This combination allows the attacker not only to issue commands but also to read responses from cross-site queries. The issue is tracked under [CWE-352] and was addressed in AutoGPT version 5.1.
Critical Impact
An attacker can achieve arbitrary command execution on a victim's AutoGPT instance by luring the user to a malicious page, with no authentication required.
Affected Products
- significant-gravitas AutoGPT (now AutoGPT Classic) version 0.5.0
- AutoGPT instances exposing the unprotected instruction API endpoint
- Deployments using the default permissive CORS configuration
Discovery Timeline
- 2024-06-06 - CVE-2024-1879 published to the National Vulnerability Database (NVD)
- 2025-08-05 - Last updated in NVD database
Technical Details for CVE-2024-1879
Vulnerability Analysis
AutoGPT exposes an HTTP API endpoint that accepts instructions for the agent to execute. In version 0.5.0, this endpoint accepts state-changing requests without verifying a CSRF token, origin header, or any equivalent anti-forgery protection. Any browser that has network reachability to the local AutoGPT server can be coerced into issuing requests on the user's behalf.
The situation is worsened by a permissive CORS policy. The server returns Access-Control-Allow-Origin for arbitrary origins by default, which means cross-origin JavaScript can read the response bodies of the requests it triggers. The attacker can therefore both issue commands and exfiltrate their output.
Because AutoGPT can execute shell commands and run code as part of its agent loop, instruction submission is functionally equivalent to remote command execution on the host running the agent.
Root Cause
The root cause is missing CSRF protection on a privileged API endpoint combined with an overly permissive CORS configuration. The endpoint trusts any request that originates from the browser's cookie or network context without validating the requesting origin, and CORS allows arbitrary origins to read responses.
Attack Vector
An attacker hosts a malicious web page containing JavaScript that issues fetch or XMLHttpRequest calls to http://127.0.0.1:<port> or another reachable AutoGPT endpoint. When a user running AutoGPT on their local network visits the page, the browser sends the crafted request to the AutoGPT API. The server accepts the instruction and executes it. The permissive CORS policy allows the attacker's script to read the response, including command output. User interaction is limited to visiting the attacker-controlled URL.
No proof-of-concept exploit code is publicly listed for this issue. See the Huntr Bug Bounty Report for the original technical writeup.
Detection Methods for CVE-2024-1879
Indicators of Compromise
- Unexpected inbound HTTP requests to the AutoGPT API endpoint with Origin or Referer headers pointing to untrusted external domains
- AutoGPT logs showing instruction submissions that were not initiated by the local user
- Child processes spawned by the AutoGPT process executing unexpected shell commands, scripts, or outbound network connections
- Browser history entries on the operator workstation showing visits to unfamiliar sites coincident with anomalous agent activity
Detection Strategies
- Inspect HTTP access logs on the AutoGPT host for POST requests bearing cross-origin Origin headers
- Monitor process ancestry on the AutoGPT host to identify shell or interpreter processes spawned without operator action
- Correlate browser activity on AutoGPT operator machines with agent command execution timestamps
- Apply identification rules for command-execution patterns that originate from the Python interpreter running AutoGPT
Monitoring Recommendations
- Enable verbose request logging on the AutoGPT API and forward logs to a centralized analytics platform
- Alert on any process executed by AutoGPT that performs filesystem modification outside the agent workspace directory
- Track outbound network connections from the AutoGPT host to non-allowlisted destinations
- Review CORS response headers periodically to confirm restrictive origin policy remains in place
How to Mitigate CVE-2024-1879
Immediate Actions Required
- Upgrade AutoGPT to version 5.1 or later, which addresses the CSRF and CORS issues
- Bind the AutoGPT API to 127.0.0.1 only and avoid exposing it on routable network interfaces
- Restrict browser access to the AutoGPT host using host firewall rules while the upgrade is being planned
- Audit recent AutoGPT command history for instructions that the local operator did not submit
Patch Information
The maintainers fixed the issue in AutoGPT 5.1. The corrective change is available in the upstream repository commit referenced by the project: GitHub Commit Changes. Operators running 0.5.0 should upgrade to the patched release rather than backporting changes.
Workarounds
- Run AutoGPT inside an isolated container or virtual machine with no shared browser context
- Place a reverse proxy in front of the AutoGPT API that enforces strict Origin and Referer validation and requires a session-bound CSRF token
- Configure the proxy or application server to set Access-Control-Allow-Origin to a single trusted origin rather than wildcard
- Use a dedicated browser profile that never visits untrusted sites while the AutoGPT server is running
# Configuration example: restrictive nginx reverse proxy in front of AutoGPT
server {
listen 127.0.0.1:8443 ssl;
server_name autogpt.local;
location /api/ {
if ($http_origin !~ "^https://autogpt\.local$") {
return 403;
}
if ($request_method = POST) {
if ($http_x_csrf_token = "") {
return 403;
}
}
add_header Access-Control-Allow-Origin "https://autogpt.local" always;
add_header Access-Control-Allow-Credentials "true" always;
proxy_pass http://127.0.0.1:8000;
}
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

