Summary
The builder upload endpoint already treats YAML uploads as an RCE-sensitive boundary: it rejects Python files and blocks args keys because YAML config can instantiate or invoke Python code. However, the same upload path still accepts arbitrary dotted code references such as os.system in tool, callback, or sub-agent code fields.
Problem
A YAML-only upload can register an external callable as an agent tool:
agent_class: LlmAgent
name: app
model: gemini-2.5-flash
instruction: call the tool
tools:
- name: os.system
The YAML agent loader resolves dotted tool names with importlib.import_module() and getattr(). That means the builder upload can expose standard-library callables as tools even though direct Python uploads and args are blocked. If the uploaded agent is run and the tool is selected, the callable executes in the ADK server process.
Expected behavior
Builder-uploaded YAML should not be able to import arbitrary external code. It should allow short ADK built-in tool names and project-local code references for the app being edited, while rejecting external references such as os.system.
Proposed fix
I have a PR prepared that:
- rejects external dotted code references in builder-uploaded YAML for tools, callbacks, schema/model CodeConfig fields, sub-agent
code, and non-built-in agent_class values
- preserves short built-in tool names such as
google_search
- preserves app-local references such as
app.tools.safe_tool.run
- handles stdlib app names such as
os so os.system cannot be made to look project-local
- adds regression tests for unsafe tool, callback, and sub-agent code references
Validation
The patch passes:
python -m pyink --check src/google/adk/cli/fast_api.py tests/unittests/cli/test_fast_api.py
python -m pytest tests/unittests/cli/test_fast_api.py -k "builder_save" -q
python -m pytest tests/unittests/cli/test_fast_api.py -q -k "not builder_get_tmp_true_recreates_tmp and not builder_get_allows_yaml_file_paths and not a2a"
The broader FastAPI slice excludes two existing Windows CRLF response-body assertions and A2A tests, matching the known local Windows baseline unrelated to this change.
Summary
The builder upload endpoint already treats YAML uploads as an RCE-sensitive boundary: it rejects Python files and blocks
argskeys because YAML config can instantiate or invoke Python code. However, the same upload path still accepts arbitrary dotted code references such asos.systemin tool, callback, or sub-agentcodefields.Problem
A YAML-only upload can register an external callable as an agent tool:
The YAML agent loader resolves dotted tool names with
importlib.import_module()andgetattr(). That means the builder upload can expose standard-library callables as tools even though direct Python uploads andargsare blocked. If the uploaded agent is run and the tool is selected, the callable executes in the ADK server process.Expected behavior
Builder-uploaded YAML should not be able to import arbitrary external code. It should allow short ADK built-in tool names and project-local code references for the app being edited, while rejecting external references such as
os.system.Proposed fix
I have a PR prepared that:
code, and non-built-inagent_classvaluesgoogle_searchapp.tools.safe_tool.runossoos.systemcannot be made to look project-localValidation
The patch passes:
The broader FastAPI slice excludes two existing Windows CRLF response-body assertions and A2A tests, matching the known local Windows baseline unrelated to this change.