Skip to content

bug: exception messages flow into ops/system-agent API responses (py/stack-trace-exposure siblings of #1860) #1917

Description

@webmixgamer

Summary

CodeQL flagged py/stack-trace-exposure on restart_fleet during PR #1912, which fixed its own instance (response carries HTTPException.detail or the exception class name only; full message + traceback go to the backend log via exc_info=True — see the pattern at src/backend/routers/ops.py, the restart_fleet error branch). The same raw-str(e)-into-response pattern pre-exists at sibling sites that PR deliberately left untouched (minimal-changes rule):

  • Open CodeQL alert #231: src/backend/routers/system_agent.py:83 (ref main)
  • src/backend/routers/ops.py:205 — fleet health "Agent not responding: {str(e)[:50]}" (truncated, lowest risk)
  • src/backend/routers/ops.py:564stop_fleet per-agent "error": str(e)
  • src/backend/routers/ops.py:751_stop_agent_container "error": str(e) (feeds emergency_stop results)
  • src/backend/routers/ops.py:1056 — ops costs "Failed to fetch metrics: {str(e)}"
  • (grep-worthy: routers/agents.py single-agent stop/start raise HTTPException(500, f"...{str(e)}") — same class via detail)

All these endpoints are admin-gated, so exposure is bounded — but exception messages can embed internals (the #1885 reaped-cmdline and git-stderr-PAT classes, docs/memory/learnings.md 2026-07-14), and alert #39 (the restart_fleet instance on main) demonstrates CodeQL files them as findings.

Acceptance criteria

Found while resolving the code-scanning review on PR #1912 (#1860).

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions