Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-35002

CVE-2026-35002: Agno Arbitrary Code Execution Vulnerability

CVE-2026-35002 is a remote code execution flaw in Agno versions prior to 2.3.24 that allows attackers to execute arbitrary Python code via the field_type parameter. This article covers technical details, impact, and mitigation.

Published:

CVE-2026-35002 Overview

CVE-2026-35002 is a critical arbitrary code execution vulnerability in Agno versions prior to 2.3.24. The vulnerability exists in the model execution component where attackers can execute arbitrary Python code by manipulating the field_type parameter that is passed unsafely to Python's eval() function. An attacker who can influence the field_type value in a FunctionCall can achieve remote code execution on the target system.

Critical Impact

This vulnerability allows unauthenticated attackers to execute arbitrary Python code remotely by injecting malicious payloads through the field_type parameter, potentially leading to complete system compromise.

Affected Products

  • Agno versions prior to 2.3.24

Discovery Timeline

  • 2026-04-02 - CVE CVE-2026-35002 published to NVD
  • 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-35002

Vulnerability Analysis

This vulnerability is classified under CWE-95 (Improper Neutralization of Directives in Dynamically Evaluated Code), commonly known as "Eval Injection." The flaw stems from the unsafe use of Python's eval() function to dynamically convert string type names to actual Python types. In the vulnerable code, user-controllable input from the field_type parameter in FunctionCall arguments is passed directly to eval() without any sanitization or validation. This allows an attacker to inject arbitrary Python expressions that will be executed in the context of the application.

The vulnerability is network-accessible with low attack complexity and requires no privileges or user interaction, making it trivially exploitable by remote attackers. Successful exploitation grants attackers the ability to execute arbitrary code with the same privileges as the Agno application, potentially enabling data theft, lateral movement, installation of backdoors, or complete system takeover.

Root Cause

The root cause is the dangerous use of Python's eval() function to convert string representations of type names (like "str", "int") into actual Python type objects. The vulnerable code in libs/agno/agno/models/base.py and libs/agno/agno/tools/function.py directly passes the field_type string from untrusted input to eval():

python
python_type = eval(field_type) if isinstance(field_type, str) else field_type

Source: GitHub Commit Update

Since eval() executes any valid Python expression, attackers can inject malicious code such as __import__('os').system('malicious_command') as the field_type value, which will be executed by the Python interpreter.

Attack Vector

The attack vector is network-based. An attacker can craft a malicious FunctionCall request containing a weaponized field_type value in the user_input_fields arguments. When the Agno model execution component processes this request, the malicious payload is passed to eval() and executed. This requires no authentication and no user interaction, making it highly exploitable.

The security patch in libs/agno/agno/models/base.py replaces the dangerous eval() call with a safe type mapping dictionary:

python
                 user_input_schema = []
                 for input_field in fc.arguments.get("user_input_fields", []):
                     field_type = input_field.get("field_type")
-                    try:
-                        python_type = eval(field_type) if isinstance(field_type, str) else field_type
-                    except (NameError, SyntaxError):
-                        python_type = str  # Default to str if type is invalid
+                    if isinstance(field_type, str):
+                        type_mapping = {
+                            "str": str,
+                            "int": int,
+                            "float": float,
+                            "bool": bool,
+                            "list": list,
+                            "dict": dict,
+                        }
+                        python_type = type_mapping.get(field_type, str)
+                    elif isinstance(field_type, type):
+                        python_type = field_type
+                    else:
+                        python_type = str
                     user_input_schema.append(
                         UserInputField(
                             name=input_field.get("field_name"),

Source: GitHub Commit Update

The same fix was applied to libs/agno/agno/tools/function.py:

python
     @classmethod
     def from_dict(cls, data: Dict[str, Any]) -> "UserInputField":
+        type_mapping = {"str": str, "int": int, "float": float, "bool": bool, "list": list, "dict": dict}
+        field_type_raw = data["field_type"]
+        if isinstance(field_type_raw, str):
+            field_type = type_mapping.get(field_type_raw, str)
+        elif isinstance(field_type_raw, type):
+            field_type = field_type_raw
+        else:
+            field_type = str
         return cls(
             name=data["name"],
-            field_type=eval(data["field_type"]),  # Convert string type name to actual type
+            field_type=field_type,
             description=data["description"],
             value=data["value"],
         )

Source: GitHub Commit Update

Detection Methods for CVE-2026-35002

Indicators of Compromise

  • Unusual process spawning from Python/Agno processes (e.g., shells, network utilities)
  • Unexpected outbound network connections from the Agno application
  • Modified or newly created files in application directories
  • Evidence of __import__, os.system, subprocess, or exec strings in application logs or request payloads
  • Anomalous field_type values in FunctionCall requests that contain Python code rather than simple type names

Detection Strategies

  • Implement input validation logging to capture and alert on field_type parameters containing suspicious patterns such as __import__, os., subprocess, exec(, or eval(
  • Deploy web application firewall (WAF) rules to detect and block code injection attempts in API requests
  • Monitor Python application process behavior for signs of code injection (unexpected child processes, file operations, network connections)
  • Use runtime application self-protection (RASP) solutions to detect and block dynamic code execution

Monitoring Recommendations

  • Enable verbose logging for the Agno model execution component to capture all FunctionCall arguments
  • Set up alerts for any field_type values that do not match the expected allowlist: str, int, float, bool, list, dict
  • Monitor system calls made by the Agno process for suspicious activity using tools like auditd or SentinelOne's behavioral AI
  • Implement network monitoring to detect unusual outbound connections from Agno instances

How to Mitigate CVE-2026-35002

Immediate Actions Required

  • Upgrade Agno to version 2.3.24 or later immediately
  • If immediate upgrade is not possible, implement network-level controls to restrict access to Agno instances
  • Review application logs for evidence of exploitation attempts
  • Conduct a security assessment of systems running vulnerable Agno versions to check for compromise
  • Enable additional monitoring and alerting on Agno instances until patching is complete

Patch Information

The vulnerability has been addressed in Agno version 2.3.24. The fix replaces the unsafe eval() function calls with a secure type mapping dictionary that only allows predefined type conversions (str, int, float, bool, list, dict). Organizations should upgrade to Agno v2.3.24 or later. For detailed information about the security fix, refer to the GitHub commit and the VulnCheck Security Advisory.

Workarounds

  • Implement strict input validation at the application or API gateway level to reject any field_type values that do not match the expected types (str, int, float, bool, list, dict)
  • Deploy network segmentation to limit access to Agno instances from untrusted networks
  • Use a WAF or reverse proxy to filter and block requests containing suspicious code patterns in field_type parameters
  • Consider temporarily disabling the affected FunctionCall functionality if not critical to operations
bash
# Example: Input validation at nginx level to block suspicious field_type values
# Add to nginx configuration to reject requests with potential code injection
location /api/ {
    if ($request_body ~* "(eval|exec|__import__|os\.|subprocess)") {
        return 403;
    }
    proxy_pass http://agno_backend;
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.