T05 · Unauthorized Access and Privilege Escalation
- Location
references/INSTALL.md:56- Finding
Caller-Controlled Agent ID Enables Path Traversal Outside the Agent Directory
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is mostly a coherent session-history feature, but its sample implementation has real risks around unscoped agent IDs, internal path exposure, and misleading deletion behavior for chat transcripts.
Review this before installing, especially if OpenClaw is exposed to multiple users or untrusted dashboard clients. The feature is useful and not clearly malicious, but it should validate agent IDs against configured agents, avoid returning internal file paths, make archive operations transactional or fail closed, and align deletion prompts with actual transcript deletion before being trusted with private chat history.
references/INSTALL.md:56Caller-Controlled Agent ID Enables Path Traversal Outside the Agent Directory
references/backend-history-db.ts.txt:147Archive Listing Exposes Internal Transcript File Paths
references/backend-session-archive.ts.txt:169Fail-Open Archival Can Remove an Active Session After Archival Failure
references/frontend-controllers-sessions.ts.txt:250Permanent Delete Workflow Retains Transcript Files Contrary to User Confirmation
Referenced artifact was not completely inspected
| `src/config/sessions/history-db.ts` | [references/backend-history-db.ts.txt](references/backend-history-db.ts.txt) | SQLite CRUD operations |
Referenced artifact was not completely inspected
| `ui/src/ui/views/sessions.ts` | [references/frontend-views-sessions.ts.txt](references/frontend-views-sessions.ts.txt) | Full view with Session History sectio
The markdown describes sessions.deleteArchived as deleting archived sessions with an optional transcript deletion, which can affect user data. The file does not include any warning, confirmation note, or caution about irreversible data loss or the privacy implications of removing stored transcripts.
This markdown installation guide introduces a sessions.deleteArchived capability, which is a destructive operation affecting user data. The document does not provide any warning about deletion risk, reversibility, or need for confirmation, despite describing user-facing Delete buttons elsewhere in the file.
This code moves transcript files into and out of an archive using fs.renameSync, which changes the user's session file state and can affect data availability. While there is error logging on failure, there is no confirmation prompt, user-facing disclosure, or explanatory comment/docstring warning that these operations relocate session transcripts.
The confirmation dialog says the archived session deletion will permanently delete the session and transcript, but the actual request only sends { sessionId } with no explicit transcript-delete flag or visible guarantee that the backend performs the same action. Mismatched destructive-action messaging can cause users to authorize operations under false assumptions, leading to unintended data retention or deletion and weakening trust and auditability around sensitive chat history management.
This code provides destructive deletion buttons for archived sessions, and similarly for live sessions, without any confirmation prompt, warning text, or inline disclosure about permanence. For code files, destructive or irreversible operations should have some visible user disclosure unless clearly covered elsewhere, which is not evident in this file.
The documentation says this function lists archived sessions, but the implementation accepts an optional status filter and will return active sessions if opts.status is set to "active". This is an intent/documentation mismatch because the comment narrows behavior more than the code actually enforces.
This code makes browser client requests to list sessions, including archived sessions metadata, but the function contains no confirmation, log, print, or explanatory comment disclosing that session data will be transmitted or fetched. For code files, user/system data network operations can warrant a warning unless the disclosure exists elsewhere or is clearly part of the stated skill purpose; no such disclosure is visible in this file.
The patch operation transmits session identifiers and user-supplied updates to the backend, but there is no user-facing notice, print/log, or explanatory comment describing that remote session state will be changed. Although modification may be expected in context, that expectation is not documented within this file.
Both resumeSession and renameSession issue backend requests that alter session state, but unlike the delete flows they provide no confirmation, visible notice, or explanatory comment. For code files, safety-relevant remote operations should have at least some disclosure when not otherwise documented.
Archiving changes the state and location of a session, but the UI only provides a tooltip-like title and no explicit disclosure about what the operation does beyond moving to history. Because this is a state-changing operation affecting user session data, a clearer warning or explanatory text would improve safety and user awareness.
No suspicious patterns detected.