Security audit
Security checks for vulnerabilities and agentic risk
The skill is mostly a coherent local lore index, but it has under-disclosed file-writing behavior that can escape the configured lore folder.
Review before installing. Use it only with a dedicated lore vault and backups, and avoid allowing agents to call `add --file` until the skill rejects absolute paths and path traversal, aligns the read-only/vault-only documentation with the code, and adds confirmation or containment for overwrites.
The skill is presented primarily as a lore index/answering tool, but its documented behavior includes creating new markdown files in the vault and modifying persistent config/index state. That mismatch can mislead operators into approving or invoking a skill with write capabilities they did not anticipate, which is especially risky because the vault path is user-configurable and may point to sensitive local content.
The stated security posture says the user's vault files are never edited, but the code includes an add path that writes and can overwrite vault files. Security documentation mismatches are operationally dangerous because they cause users and platform integrators to mis-scope the skill's capabilities and may lead to unintended destructive use.
The module documentation claims vault files are read-only to the skill, but the add command can create or overwrite markdown files in the vault. This mismatch is dangerous because operators may grant trust or permissions based on the documented read-only posture while the code actually has content-modifying capability.
The skill explicitly invokes Python and describes capabilities that read environment/config, read files from an arbitrary vault path, write persistent state, and execute via shell, but it declares no tool scope or allowed-tools restrictions. This creates an authorization gap: an agent or platform may permit broader execution than users expect, increasing the chance of unintended file access or modification.
The skill maintains persistent state in config and index files and also offers a command to add new vault entries, so actions can outlive a single session and influence later answers. Persistent state is not inherently malicious, but without explicit guardrails it can cause unintended retention, stale canon manipulation, or durable modification of local data beyond what a user expected from a query skill.
much `ask` returns; the meta line reports `used/budget`.
4. **Expiring canon**: `⚠ expiring` means the WITH rule lapses in the
current arc or within `with_limbo_days` (default 7). Surface this to
the user — it usually means someone needs to write the replacement.
5. **`add` is the only writer**, and only into the configured vault.
`retcon` touches the index, never the user's files.
Data from a source is assigned to a variable that is later passed to a sink, creating a variable-mediated taint flow.
_ensure_dir(STATE_DIR)
tmp = os.path.join(STATE_DIR, ".config.tmp")
try:
with open(tmp, "w") as f:
json.dump(cfg, f, indent=2, sort_keys=True)
f.write("\n")
os.replace(tmp, os.path.join(STATE_DIR, "config.json"))
A lore indexing and canon-answering skill unexpectedly includes an authoring primitive that writes arbitrary markdown into the configured vault. In this context, write capability increases the blast radius from passive retrieval to active modification of source canon, enabling tampering, persistence, or abuse of the vault as a writable file target.
The add command writes to a path built from cfg["vault"] and an attacker-controlled --file value via os.path.join without validating that the final resolved path stays inside the configured vault. A crafted filename such as ../../.bashrc can escape the vault and overwrite arbitrary files accessible to the process, especially with --replace or when the target does not yet exist.
_ensure_dir(cfg_vault)
tmp = path + ".tmp"
try:
with open(tmp, "w", encoding="utf-8") as f:
f.write(text)
os.replace(tmp, path)
except OSError as e:
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
def _run(self, argv):
import subprocess as _sp
p = _sp.run([sys.executable, CMD] + list(argv),
capture_output=True, text=True, timeout=30)
return p
This manifest-style header marks the skill as user-invocable but does not define any concrete trigger phrases, scope boundaries, or negative examples. For a user-facing skill, the absence of explicit invocation constraints can make activation conditions ambiguous and increase the chance of unintended invocation.
The module docstring explicitly states there are 'no subprocess launches besides the CLI under test.' In this file, the helper method imports subprocess and invokes subprocess.run to execute lore_index.py, so the documentation is only accurate because of the exception it includes; however, it still documents subprocess activity in a potentially misleading way for a reader expecting no subprocess use in the file.
No suspicious patterns detected.