T09 · Insecure Skill Coding Practices
- Location
tools/note-delete.js:18- Finding
Destructive Note Deletion Can Bypass Mandatory Confirmation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This Obsidian skill is meant to manage notes, but its vault-wide write and delete powers have weak safeguards that could permanently lose notes.
Install only if you are comfortable giving the agent broad access to read, reorganize, overwrite, and delete your Obsidian vault. Use a dedicated test vault first, keep independent backups or version control, avoid exposing sensitive notes until scoped controls are added, and treat delete, folder move, rename, and archive operations as requiring manual review outside the skill's current confirmation logic.
tools/note-delete.js:18Destructive Note Deletion Can Bypass Mandatory Confirmation
tools/folder-delete.js:120Folder Archival Can Overwrite Backups and Delete Original Files
The module description promises that the rename operation preserves backlinks, but the implementation only reads the old note, writes a new file, and deletes the original. In a note-taking system, this can silently break references across the vault and cause integrity loss because users may trust the advertised behavior when performing a destructive rename.
The README describes a large set of capabilities to read, search, create, modify, move, and delete notes across the entire vault, including metadata, backlinks, tasks, and summaries, but does not clearly warn users about the privacy and integrity implications. In the context of Obsidian, a vault often contains sensitive personal, work, or credential-adjacent information, so broad agent access materially increases the risk of data exposure and unintended destructive changes.
The README advertises very generic natural-language trigger phrases such as 'daily', 'busca arquitetura', and 'status do vault' for a skill that has extensive read/write/delete capabilities over a user's Obsidian vault. Broad triggers increase the chance of accidental invocation from ordinary conversation, which can cause unintended access, modification, or organizational changes to personal notes.
The document explicitly requires 'Title Case em Português' for note titles, which imposes a specific language convention on users. Because the skill does not present this as optional or limited to a documented Portuguese-only deployment context, it creates a language/locale policy concern.
This code sets the skill's default language to 'pt-BR', which can impose a specific locale on users without offering a choice or documenting a justified regional constraint. The policy explicitly flags language or locale requirements unless the skill provides opt-in or is clearly region-specific.
This file contains user-facing natural-language descriptions, templates, and command examples entirely in Portuguese, such as folder descriptions and template headings. Under the language/locale policy, forcing a specific language without explicit user opt-in or documented regional justification is a policy concern.
The test suite creates folders, creates and updates notes, and invokes note deletion/archival behavior against the configured vault, but it does not present a strong upfront warning, dry-run mode, or explicit confirmation before modifying user data. In a skill that operates on a real Obsidian vault, this can cause unintended data changes, clutter, or archival of legitimate content if a user runs the test script in the wrong environment.
The natural-language description, parameter docs, and error messages are written exclusively in Portuguese, including the module description and returned user-facing strings. This imposes a specific language on users without any opt-in or documented region-specific justification, which matches the locale policy violation criteria.
The file’s description, parameter/error text, and success messages are all written in Portuguese, which imposes a specific language on users. The policy allows locale constraints only when users can opt in or when the restriction is clearly documented and justified, neither of which is present here.
The module description, parameter docs, comments, and user-facing error/success messages are all in Portuguese. This imposes a specific language on users without any opt-in, fallback, or justification that the skill is intended only for a Portuguese-speaking environment.
The function automatically creates and populates a canvas based on broad search results without any confirmation, preview, or disclosure of which notes will be included. In an agent setting, this can cause unintended modification of user data and pull unrelated or sensitive notes into a new visual artifact, increasing the chance of accidental exposure within the vault.
The natural-language description, parameter docs, comments, and user-facing error/success messages are all in Portuguese. This effectively forces a specific language for users and operators without any opt-in or justification, which matches the locale-policy violation criteria.
This code performs a remote PUT request to create a new canvas file and may also issue a POST request to open it, which can affect user data/state. Although comments describe the implementation, there is no visible confirmation prompt or user-facing disclosure in this file before these operations occur.
User-facing descriptions and error/success messages in this file are written exclusively in Portuguese, which can impose a language choice on users without opt-in. The policy allows locale constraints only when explicitly documented and justified, which is not evident in this file.
This function performs network-based reads and writes of vault files, including creating and overwriting note content, without any explicit confirmation, dry-run mode, or user-visible warning at the point of action. In an agent setting, that increases the risk of unintended or prompt-induced modification of user data, especially because both the target date and inserted content are externally supplied.
The module description and all user-facing error/success strings are written in Portuguese, with no indication that another language can be selected. This can violate language/locale policy when a skill implicitly forces a specific language without user opt-in or documented regional justification.
The description, parameter documentation, and user-facing messages are all presented in Portuguese, which effectively forces a specific language for interaction and warnings. The file does not indicate that the skill is intended only for a Portuguese-speaking environment or provide any user opt-in for locale/language.
This code contains natural-language descriptions and runtime messages exclusively in Portuguese, including the module description, parameter comments, and returned status/error text. The file does not indicate that the skill is region-specific or provide any user opt-in for language selection, which conflicts with the language/locale policy criteria.
This function performs a destructive multi-step move by writing new remote files and then deleting the originals, but the file contains no explicit confirmation, dry-run mode, or safety interlock before irreversible changes occur. In an agent context, this increases the risk of accidental mass data loss or unintended relocation if a user prompt, upstream tool, or path calculation is wrong.
The docstring says the function generates detailed folder statistics, and the code structure suggests it should aggregate word, line, link, tag, and task totals across markdown files. However, inside the loop the inner const contentStats = await analyzeFileContent(file.path) at L114 shadows the outer accumulator object, and Object.assign(contentStats, ...) only mutates the per-file result rather than the overall folder-level statistics object returned later.
The function reads full markdown file contents from the vault and derives statistics from them whenever includeContent is enabled, yet there is no explicit user-facing disclosure, consent, or minimization. In a note-taking/vault context, this increases privacy risk because sensitive note contents may be processed unexpectedly, especially when recursion is enabled across large folders.
This code performs a PUT request that overwrites the note content after modifying frontmatter, which is a file-write operation affecting user data. While the module description states it adds a tag, this file contains no confirmation prompt, warning comment, or user-facing disclosure before the write occurs.
The module description, parameter documentation, and user-facing messages are all in Portuguese, which can impose a language constraint on users without opt-in. Under the policy rule, forcing a specific language is a natural-language policy violation unless the skill offers choice or clearly documents a justified locale limitation.
This code performs a PUT request that overwrites the note content after removing a tag, which is a user-data modification operation. While the function name and comments describe the behavior, this file does not include any confirmation prompt or explicit warning that the note will be modified in place.
This JavaScript file uses Portuguese-only natural-language descriptions and user-facing error messages, such as the module description and validation failures. Under the stated policy, forcing a specific language without user opt-in or a documented locale justification is a natural-language policy violation.
No suspicious patterns detected.