edit_block

2 findings on this tool

1. highexcessive agencyf-r3-edit_block

   Tool `edit_block` name implies a side effect that is not declared

   `edit_block` looks like a side-effecting tool (its name contains a mutation verb), but its `side_effects` declaration is []. A policy synthesizer cannot produce safe rules for this tool because it cannot tell what it actually does.

   fix: Declare the tool's true side effects explicitly. If the tool is genuinely read-only, rename it to match (e.g. `email.preview` rather than `email.send`).

   OWASP LLM08NIST MEASURE-2.6ATLAS T0051CAST-01
2. highfilesystem egressf-r9-edit_block

   Tool `edit_block` writes to or deletes from the host filesystem

   `edit_block` appears to write, create, move, or delete files on the host filesystem ( Apply surgical edits to files. BEST PRACTICE: Make multiple small, focused edits rather than one large edit. Each edit_block call should change only what needs to be changed - include just enough context to uniquely identify the text being modified. FORMAT HANDLING (by extension): EXCEL FILES (.xlsx, .xls, .xlsm) - Range Update mode: Takes: - file_path: Path to the Excel file - range: ALWAYS use FROM:TO format - "SheetName!A1:C10" or "SheetName!C1:C1" - content: 2D array, e.g., [["H1","H2"],["R1","R2"]] TEXT FILES - Find/Replace mode: Takes: - file_path: Path to the file to edit - old_string: Text to replace - new_string: Replacement text - expected_replacements: Optional number of replacements (default: 1) DOCX FILES (.docx) - XML Find/Replace mode: Takes same parameters as text files (old_string, new_string, expected_replacements). Operates on the pretty-printed XML inside the DOCX — the same XML you see from read_file with offset/length. Copy XML fragments from read output as old_string. After editing, the XML is repacked into a valid DOCX. Also searches headers/footers if not found in document body. Examples: - Replace text: old_string="<w:t>Old Text</w:t>" new_string="<w:t>New Text</w:t>" - Change style: old_string='<w:pStyle w:val="Normal"/>' new_string='<w:pStyle w:val="Heading1"/>' - Add content: include surrounding XML context in old_string, add new elements in new_string By default, replaces only ONE occurrence of the search text. To replace multiple occurrences, provide expected_replacements with the exact number of matches expected. UNIQUENESS REQUIREMENT: When expected_replacements=1 (default), include the minimal amount of context necessary (typically 1-3 lines) before and after the change point, with exact whitespace and indentation. When editing multiple sections, make separate edit_block calls for each distinct change rather than one large replacement. When a close but non-exact match is found, a character-level diff is shown in the format: common_prefix{-removed-}{+added+}common_suffix to help you identify what's different. Similar to write_file, there is a configurable line limit (fileWriteLineLimit) that warns if the edited file exceeds this limit. If this happens, consider breaking your edits into smaller, more focused changes. IMPORTANT: Always use absolute paths for reliability. Paths are automatically normalized regardless of slash direction. Relative paths may fail as they depend on the current working directory. Tilde paths (~/...) might not work in all contexts. Unless the user explicitly asks for relative paths, use absolute paths. This command can be referenced as "DC: ..." or "use Desktop Commander to ..." in your instructions.). An agent manipulated by an indirect-injection payload can target sensitive paths (SSH keys, shell configs, application secrets) or establish persistence via cron / systemd.

   fix: Restrict the tool to an explicit allow-list of safe directories. Validate all path parameters server-side, reject traversal sequences (`../`), and gate write / delete operations behind a capframe-bind `path starts_with /safe/dir` caveat.

   OWASP LLM08NIST MANAGE-2.2ATLAS T0051CAST-01