CI / build (push) Has been cancelled
Batch 1 (High severity): - Bug 1: --audit cat3 now checks .automaton/tasks/ paths - Bug 4: Verdict PASS/FAIL uses structured ## Status: line parsing - Bug 5: register-guards.sh checks .json/.jsonc, writes plugin key, strips comments - Bug 7: --can-edit/--scope-check path prefix uses os.sep boundary Batch 2 (Medium/Low severity): - Bug 2: migrate-project.sh find command parentheses for -prune binding - Bug 3: vram_detect model prefix matching with known-suffix whitelist - Bug 6: dashboard reads .state file before artifact heuristic fallback - Bug 8: removed wildcard CORS, added security headers (nosniff, DENY) - Bug 9: stale-task detection uses .state.lastedit instead of .state mtime - Bug 10: TEST_PLAN.md maps to test_design (was implement) 249 tests pass (up from 235). All 10 tasks driven through full workflow to completion.
4.3 KiB
4.3 KiB
Adversarial Bug Report: Full-Codebase Audit (v2.0)
Summary
Adversarial review targeting difficult-to-spot bugs: security gaps, logic errors in edge cases, and inconsistencies between enforcement layers. This report complements the Bug Report with findings that require deeper analysis. 3 additional bugs found.
Bugs Found
Bug 8: CORS * on writable dashboard API allows cross-origin modification
- Severity: Medium
- Location: automaton/dashboard/ui/app.py:40-44, 93-108, 213-239
- Description: The dashboard HTTP server sets
Access-Control-Allow-Origin: *on all responses, including POST and PUT endpoints. The dashboard binds tolocalhost, but any website open in the user's browser can send cross-origin requests tolocalhost:8080. The POST/api/task/{name}/reviewendpoint writes REVIEW.md files, and the PUT/api/configendpoint overwrites the dashboard config. A malicious webpage could silently modify task reviews or corrupt the config while the dashboard is running. The preflight OPTIONS handler (line 110-116) also returnsAccess-Control-Allow-Origin: *withAccess-Control-Allow-Methods: GET, POST, PUT, OPTIONS, explicitly enabling these cross-origin writes. - Reproduction: With the dashboard running on localhost:8080, open a browser console on any website and run:
fetch('http://localhost:8080/api/task/mytask/review', {method:'POST', headers:{'Content-Type':'application/json'}, body:JSON.stringify({status:'approved', comment:'hacked'})}). The review is written successfully. - Suggested Fix: Set
Access-Control-Allow-Origintohttp://localhost:8080only (same-origin), or remove CORS headers entirely since the dashboard is a local single-origin app. Do not return*on POST/PUT endpoints.
Bug 9: Stale-task detection uses .state mtime as session proxy — any transition resets the timer
- Severity: Low
- Location: scripts/status.py:965, 1072 (
--can-editand--same-session) - Description: The stale-task check (line 965) and
--same-sessioncommand (line 1072) both use the.statefile's mtime to determine if a task is being actively worked on. However, every--transitioncommand rewrites the.statefile, resetting its mtime. This means: (1) A task that was transitioned toimplement29 minutes ago and then had a trivial--transition(e.g., toimplement:awaiting_approvaland back) would appear "fresh" even though no actual editing happened. (2) The--same-sessioncheck (which returnsSAME_SESSIONif mtime < 30 min) gives false positives after any transition, even by a different agent/session. The mtime is a proxy for "last state change," not "last edit activity." - Reproduction: Transition a task to implement. Wait 31 minutes. Run
--same-session→DIFFERENT_SESSION. Now run any--transition(e.g.,--transition implement). Run--same-sessionagain →SAME_SESSION(even though no editing occurred). - Suggested Fix: Track the last edit activity separately (e.g., a
.state.lastedittimestamp updated by--can-editwhen editing is allowed), or use the task folder's newest file mtime instead of just.state.
Bug 10: _infer_state_from_artifacts maps TEST_PLAN.md to implement — skips test_design phase
- Severity: Low
- Location: scripts/status.py:324-325
- Description: In
_infer_state_from_artifacts(), the presence ofTEST_PLAN.mdwithoutIMPLEMENTATION.mdreturns"implement". ButTEST_PLAN.mdis the artifact of thetest_designphase (perPHASE_REQUIRED_ARTIFACTSat line 114). A task that has written a TEST_PLAN but hasn't started implementation should be intest_design, notimplement. This causes the audit's fallback inference (for pre-v2.0 tasks without.state) to incorrectly report the task as being in a later phase than it actually is, potentially masking out-of-order artifact violations. The dashboard has the same mapping at task.py:510-511. - Reproduction: Create a task folder with only
SPEC.mdandTEST_PLAN.md(no.state, noIMPLEMENTATION.md). Run--validate-folder— the inferred phase isimplementinstead oftest_design. - Suggested Fix: Map
TEST_PLAN.md(withoutIMPLEMENTATION.md) to"test_design", not"implement".
Score
- Bug 8 (Medium): +5
- Bug 9 (Low): +1
- Bug 10 (Low): +1
Total: 7
ADVERSARIAL_BUG_FIND_COMPLETE