On this page (7 sections)
Agno, a Python framework for building AI agents, contains a critical code injection flaw in versions before 2.3.24. A value called field_type, supplied on a FunctionCall input field, was passed to Python's built-in eval(). Anyone who could influence that value could run arbitrary Python code inside the Agno process. The issue is tracked as CVE-2026-35002.
If you run Agno behind an API or web UI, or let it process output from untrusted tools or models, you should check your version now. The fix is a normal package upgrade, and the maintainers say there is no safe workaround.
What happened
According to the GitHub advisory, the model execution component of Agno took the field_type parameter of a FunctionCall input field and handed it to eval(). The advisory describes the impact as full loss of confidentiality, integrity and availability for the Agno process, which means whatever the process can read, write or run is within reach.
The flaw is classified as CWE-95, improper neutralization of directives in dynamically evaluated code. The CVE description adds that an attacker can influence the field_type value in a FunctionCall to achieve remote code execution. Credit in the advisory goes to harshsinha03.
Why eval() on input is dangerous
eval() takes a string and runs it as a Python expression. That is fine for trusted, hard-coded strings, but if any part of the string comes from outside, the sender decides what code runs. The original code only expected simple type names such as str or int, and used eval() as a shortcut to turn the name into a real Python type. Nothing limited the input to those names.
This pattern is common in AI agent tooling, where function arguments may be generated by a model or passed in from a client. In that setting, the text reaching your code may be partly controlled by a user, a document the model read, or another tool, so values should be treated as untrusted even when they look like internal configuration.
Who is affected
Every deployment on agno earlier than 2.3.24 carries the vulnerable code. Real exposure depends on whether untrusted data can reach the field_type parameter. The advisory names these routes as examples:
- An API that accepts FunctionCall inputs from clients
- A web UI that lets users submit or shape those inputs
- Untrusted tool or model output that feeds into FunctionCall input fields
The CVSS vector on the advisory page rates the attack as network-reachable, low complexity, with no privileges or user interaction required. That describes the worst case, where the input is directly reachable. An Agno script that only runs locally with fully trusted inputs is less exposed, but upgrading is still the right move because the cost is low.
How to check your exposure
Start by finding every place Agno is installed: application virtual environments, containers, CI images, notebooks and any servers hosting agent APIs. Then read the installed version.
pip show agnoLook at the Version line in the output. Anything below 2.3.24 is vulnerable. To see which version a project pins, search its dependency files.
grep -rn "agno" requirements*.txt pyproject.toml 2>/dev/nullThen review how your agents receive input. If a public endpoint, chat interface or third-party tool can supply FunctionCall arguments, treat that service as a priority.
What to do now
The maintainers state that all users should upgrade to 2.3.24 or later, and that the 2.6.x release line includes the fix. See the v2.3.24 release for details.
pip install --upgrade agno
pip show agno0 of 8 done
The advisory is explicit that there is no safe workaround. If you truly cannot upgrade right away, it says to make sure no untrusted input can reach the field_type parameter, but it calls upgrading strongly preferred. Treat any such restriction as a short-term stopgap.
What the fix changes
The patch commit removes the eval() calls. In their place, the code looks up a string in a fixed mapping of known types (str, int, float, bool, list and dict). A value that is already a Python type is accepted as is, and anything else falls back to str. The same change covers both the synchronous and asynchronous execution paths and the UserInputField.from_dict method. A fixed lookup table is the standard way to replace eval() here, because input can only select from a known list and never be run as code.
Detection and monitoring
The sources do not describe indicators of compromise, and there is no confirmed exploitation reported, so there is no specific signature to hunt for. General steps still apply:
- Review application logs for FunctionCall inputs with unusual field_type values, such as anything other than simple type names
- Watch the Agno host for unexpected child processes, outbound connections or file changes
- Track dependencies in CI so builds fail or warn when agno falls below 2.3.24
- Subscribe to the project's GitHub advisories to catch future fixes
If Agno sits behind a public web endpoint, keep the surrounding site healthy as well. A security scan and certificate and header monitoring will not detect this flaw, but they help you notice other changes on the public side of the service. For wider context on hardening, see website security for small business.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.