What is the CVSS score of EUVD-2026-30817?

EUVD-2026-30817 has a CVSS 3.1 base score of 7.6 (High). CVSS vector: CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of AutoGPT are affected by EUVD-2026-30817?

AutoGPT platform versions 0.6.34-0.6.51 are vulnerable to remote code execution through insecure deserialization of cached data, allowing attackers with access to the shared Redis instance to execute…. A patch is available.

How to fix or mitigate EUVD-2026-30817?

Within 24 hours: Identify all systems running AutoGPT 0.6.34-0.6.51 and verify network access controls for the Redis instance. Within 7 days: Deploy vendor-released patch (autogpt-platform-beta-v0.6.52) to all affected systems after validation in a staging environment. Within 30 days: Audit backend and Redis logs for unauthorized cache modifications; implement monitoring for suspicious cache write attempts.

AutoGPT EUVD-2026-30817

| CVE-2026-33233 HIGH

Deserialization of Untrusted Data (CWE-502)

2026-05-19 GitHub_M

Deserialization Redis

7.6

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.6 HIGH

AV:A/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

Attack Vector

Adjacent

Attack Complexity

High

Privileges Required

High

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Patch available

May 19, 2026 - 02:01 EUVD

Source Code Evidence Fetched

May 19, 2026 - 01:43 vuln.today

Analysis Generated

May 19, 2026 - 01:43 vuln.today

DescriptionGitHub Advisory

AutoGPT is a workflow automation platform for creating, deploying, and managing continuous artificial intelligence agents. In versions 0.6.34 through 0.6.51, the backend deserializes Redis cache bytes using pickle.loads without integrity/authenticity checks. The write path serializes values with pickle.dumps(...) into Redis and the read path blindly invokes pickle.loads(...) on bytes with no HMAC/signature or strict schema validation gating deserialization. If an attacker can poison a shared-cache key in Redis, arbitrary command execution is possible in the backend container context, affecting confidentiality, integrity, and availability. This issue has been fixed in version 0.6.52.

AnalysisAI

Insecure deserialization in Significant-Gravitas AutoGPT platform versions 0.6.34 through 0.6.51 lets an attacker who can poison entries in the shared Redis cache achieve arbitrary command execution inside the backend container. The backend's read path invokes pickle.loads on cache bytes with no HMAC, signature, or schema gate, so any attacker-controlled value reaching that key becomes code on retrieval. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV; the vendor shipped a fix in autogpt-platform-beta-v0.6.52.

Technical ContextAI

AutoGPT is a workflow automation platform for building and running continuous AI agents (CPE significant-gravitas:autogpt). Its backend uses Redis as a shared cache and serializes Python objects with pickle.dumps on write and pickle.loads on read. CWE-502 (Deserialization of Untrusted Data) applies directly: Python's pickle format is a documented code-execution primitive - a crafted byte stream can construct objects whose __reduce__ method invokes arbitrary callables (os.system, subprocess.Popen, etc.) during unpickling. Because the cache layer treats Redis as a trust boundary and applies no integrity check (HMAC/signature) or strict schema validation, anyone with write access to a relevant key controls the deserializer's input.

RemediationAI

Vendor-released patch: upgrade to autogpt-platform-beta-v0.6.52 or later, per https://github.com/Significant-Gravitas/AutoGPT/releases/tag/autogpt-platform-beta-v0.6.52 and advisory GHSA-rfg2-37xq-w4m9. If immediate upgrade is not possible, the most impactful compensating control is to harden the Redis trust boundary so untrusted parties cannot write cache keys: require Redis AUTH, enable TLS, bind Redis to a private interface, and apply network policies (Kubernetes NetworkPolicy or firewall rules) that allow only the AutoGPT backend pod/host to reach the Redis port - side effect is that any external tooling that touched Redis directly will break. In multi-tenant setups, dedicate a separate Redis instance or logical database per trust zone rather than sharing keys, accepting the operational overhead of additional Redis instances. Monitoring Redis writes for unexpected sources via slowlog/MONITOR (carefully, due to performance cost) can provide detection while the upgrade is scheduled. Removing the cache feature entirely is not a practical workaround as the backend depends on it.