Security issues in CleverAgents... #7
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
Blocked
Bounty
$100
Bounty
$1000
Bounty
$10000
Bounty
$20
Bounty
$2000
Bounty
$250
Bounty
$50
Bounty
$500
Bounty
$5000
Bounty
$750
MoSCoW
Could have
MoSCoW
Must have
MoSCoW
Should have
Needs feedback
Points
1
Points
13
Points
2
Points
21
Points
3
Points
34
Points
5
Points
55
Points
8
Points
88
Priority
Backlog
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Signed-off: Owner
Signed-off: Scrum Master
Signed-off: Tech Lead
Spike
State
Completed
State
Duplicate
State
In Progress
State
In Review
State
Paused
State
Unverified
State
Verified
State
Wont Do
Type
Bug
Type
Discussion
Type
Documentation
Type
Epic
Type
Feature
Type
Legendary
Type
Support
Type
Task
Type
Testing
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
cleveragents/cleveragents-core#7
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Here are some security problems found within commit
4947b17521, which is the currentmasterbranch of cleveragents-core.These are only POSSIBLE security problems. I have not done extensive analysis. If you say that these security problems can't be exploited, then that should be enough. Just look them over.
(And if you want to complain that I included many security problems that I shouldn't have... ask me for the conversation that I had with Aider to create this list.)
I tried to include all instances of a problem, but I don't promise that I have.
agents/base.py
One basic memory lock is used in
AgentWithMemoryfor_process_wrapper,update_memory, andget_memory.I don't think
Lockis a reentrant lock. If_process_wrappercalls a method that eventually callsget_memory, would there be a deadlock?agents/composite.py
claude-3.7-sonnetreports the following:Component Isolation (High Risk)
• The CompositeAgent combines multiple agents, graphs, and streams without clear isolation boundaries.
• If one component is compromised, it could potentially affect others within the same composite.
• Recommendation: Implement stronger isolation between components, possibly using separate execution contexts or sandboxing.
agents/llm.py
If we ever allow outside programs as agents here, we should be much more careful with
self.config.get("api_key"). For now, that should be okay.agents/tool.py
From bandit:
The
evalfunction is critical to fix.Lines 153-159 read:
This is emphatically not enough security. If I recall correctly, you wrote a bunch of examples of bad things that could be done. You should change this code so that bad examples do not get through.
This part of the code is going to be very, very important when the software goes out. It should be easy to change and modify and fix.
The method
_http_request_toolmakes me very nervous. It can be used to get any http resource that the agent can reach. In particular:Lines 277-285 read:
I don't think that's enough security for safe mode. It doesn't stop safe mode from following soft links. If the user could create a soft link to
/, then the whole file system could be read from safe mode.There's the chance that this code will run on Windows. The filepath should be compared against both
/and drive letters in Windows.langgraph/nodes.py
From bandit:
reactive/route_bridge.py
Lines 87-91 are:
If
route_config.bridge.upgrade_conditionscould have come from the user or the LLM, then the code will execute untrusted code.reactive/stream_router.py
Lines 223-225 are:
Although this tries to limit code to built-in functions, some [built-in functions](https://docs.python.org/3/library/functions.htmnl should give immediate pause:
breakpointcompileevalexecopenAll of those should be obviously bad to run.
templates/base.py
Lines 234-235 are:
If there is any chance that the parameters came from the user or an LLM, then there are some worries.
See K000152186: Python Jinja2 vulnerability CVE-2025-27516
Also look at Server Side Template Injection with Jinja2 for more security problems that can happen with Jinja and user-controlled settings.
From bandit:
templates/deferred_template.py
Line 66 reads:
Line 96 reads:
Although it is not as important as
yaml.safe_load, code should useyaml.safe_dumpinstead ofyaml.dump. According to PyYAML Documentation.templates/enhanced_registry.py
Line 97 is:
Same comment about using
yaml.safe_dumpinstead ofyaml.dumptemplates/graph_templates.py
From bandit:
templates/inline_jinja_handler.py
From bandit:
templates/inline_yaml_jinja.py
Lines 119-120 are:
If the
contentorcontextcame from the user, then Jinja2 might be able to execute Python expressions.templates/jinja_yaml_preprocessor.py:
From bandit:
Lines 94-95 are:
Same problem with Jinja templates.
templates/registry.py
Lines 107-108 are:
Same problem with Jinja templates.
templates/renderer.py:
Lines 98-100 are:
According to Python Jinja2: always autoescape to avoid XSS attacks, if
autoescapeis false, then HTML won't be escaped, so there may be XSS vulnerabilities.From bandit:
There are multiple places where the code processes templates with (possibly) user-supplied values. If that's the case, then there is a security vulnerabitily.
templates/smart_yaml_loader.py
Not a security problem, but the parsing code in lines 73-137 cannot handle nested
forinstructions.Lines 274-275 read:
If user-controlled input is included, this might cause template injection vulnerabilities.
templates/stream_templates.py:
From bandit:
templates/template_store.py
Line 65 is:
and line 154 is:
They should be
yaml.safe_dump.Lines 114-119 have a set of functions -- but they're different than other sets of functions. The functions should be unified.
Line 124 reads:
This might be a security problem.
templates/yaml_jinja_loader.py
From bandit:
If
yaml_contentorcontextcould have come from users, then there might be security issues with lines 126-127.The utility functions in lines 80-91 are different than utility functions in other parts of the code. There should be just one master list of utility functions.
templates/yaml_preprocessor.py
From bandit:
templates/yaml_template_engine.py
From bandit:
Lines 76-77 are:
This has the same problems with YAML as listed above.
templates/yaml_template_engine.py
Lines 97-99 are:
This has the same problems with YAML as listed above.
Lines 388-407 contain a different list of context functions than elsewhere. There should be just one list of functions, used everywhere.
cli.py
Lines 87-89 are:
They will overwrite any file that the user gives. If the program has access to files that the user does not, this might be used to destroy files that the user otherwise doesn't have access to.
Here is the complete conversation between Aider and I for the security code review.