Skip to content

Potential fix for code scanning alert no. 2: Information exposure through an exception - #288

Open
Exohayvan wants to merge 1 commit into
mainfrom
alert-autofix-2
Open

Potential fix for code scanning alert no. 2: Information exposure through an exception#288
Exohayvan wants to merge 1 commit into
mainfrom
alert-autofix-2

Conversation

@Exohayvan

Copy link
Copy Markdown
Contributor

Potential fix for https://github.com/AetherMesh-AI/aethermesh-core/security/code-scanning/2

To fix this safely without changing endpoint behavior, keep returning stable reason_code values but replace client-facing reason text derived from exceptions with generic, non-sensitive messages. Log detailed exception information on the server for debugging.

Best single approach here:

  1. In src/aethermesh_core/runtime_service.py, add a module logger.
  2. In preflight_local_result_report exception handlers:
    • Log the exception with logger.exception(...) (includes traceback in server logs).
    • Call _reject_local_result_report with a generic user-safe reason string instead of str(exc).
  3. Keep existing persistence and response schema intact (status, attempt_id, reason_code, etc.) so functionality remains the same from an API-contract perspective, while removing sensitive exception content from responses.

This addresses both variants (line 1309 and 1311 exception sources), since both currently pass str(exc) to the returned rejection payload.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

…ough an exception

Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
@Exohayvan
Exohayvan marked this pull request as ready for review July 23, 2026 02:07
@Exohayvan Exohayvan added type:bug Type: bug or broken behavior. priority:P2 Priority P2: high-impact near-term work. system:api System: HTTP/API surface. system:runtime System: local node runtime/service lifecycle. area:local-api Area: generated triage label for local api. area:api-response Area: API response schemas or route payloads. area:result-reporting Area: generated triage label for result reporting. risk:medium Risk: changes existing working behavior with moderate regression risk. needs:review Needs: generated triage label for review. labels Jul 23, 2026
@Exohayvan Exohayvan added status:ready Human-readable workflow status: ready for the next review or merge step. status:in-review Human-readable workflow status: under review. status:blocked Human-readable workflow status: blocked by a failing gate or dependency. and removed needs:review Needs: generated triage label for review. status:ready Human-readable workflow status: ready for the next review or merge step. status:in-review Human-readable workflow status: under review. labels Jul 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:api-response Area: API response schemas or route payloads. area:local-api Area: generated triage label for local api. area:result-reporting Area: generated triage label for result reporting. priority:P2 Priority P2: high-impact near-term work. risk:medium Risk: changes existing working behavior with moderate regression risk. status:blocked Human-readable workflow status: blocked by a failing gate or dependency. system:api System: HTTP/API surface. system:runtime System: local node runtime/service lifecycle. type:bug Type: bug or broken behavior.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant