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).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions