Back to skill

Security audit

Dailylog

Security checks for vulnerabilities and agentic risk

Overview

DailyLog is a local journaling and productivity logger that stores user-entered notes on disk; it has privacy and hardening gaps but no hidden network, credential, or destructive behavior.

Use this skill only if you are comfortable with personal notes, plans, reminders, and exports being stored as plaintext in ~/.local/share/dailylog. Avoid secrets or regulated data, check local file permissions or use a restrictive umask, and treat exported JSON/CSV/TXT files as sensitive copies of your full log history.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (3)

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/script.sh:6
Finding
Journal Data and Exports May Be Created with Overly Permissive File Permissions## Vulnerability Details **File Location**: `scripts/script.sh`, lines 6-7 **Vulnerability Type**: Insecure local storage permissions **Risk Level**: Medium ### Vulnerable Code ```bash DATA_DIR="${HOME}/.local/share/dailylog" mkdir -p "$DATA_DIR" ``` ### Technical Analysis The script creates a directory intended to contain personal plans, reflections, reminders, habit records, activity history, and exports. It does not establish a restrictive process umask or explicitly assign secure permissions to the directory and files. Consequently, permissions depend on the environment's existing umask. With a commonly used umask of `022`, the directory can be created with mode `0755`, while files created through shell redirection can receive mode `0644`. On a multi-user system, these permissions may allow other local users to list the directory and read journal or export files. The records are intentionally stored as plaintext, making filesystem access sufficient to disclose their complete contents. This issue does not independently grant remote access or elevated privileges; exploitation requires access through another local account or process that can traverse the user's home directory. ### Attack Path 1. The victim runs DailyLog in an environment with a permissive umask, such as `022`. 2. The script creates `~/.local/share/dailylog` without explicitly restricting its mode. 3. The victim records sensitive work plans, reminders, reflections, or other personal information. 4. Log and export files are created using the inherited umask and may be readable by other local users. 5. Another local account traverses the victim's accessible home path and reads the DailyLog files. ### Impact Assessment A successful attack can disclose all readable journal entries, reminders, work-related notes, habit records, activity history, and generated exports belonging to the affected user. The impact is limited to information available throug ...[truncated 161 chars]
Remediation
## Remediation Suggestions - Set a restrictive umask before creating any storage or export files: ```bash umask 077 ``` - Create and enforce private directory permissions: ```bash install -d -m 0700 "$DATA_DIR" ``` - Apply mode `0600` to existing and newly generated logs and exports. - On startup, verify that the data directory is owned by the current user and is not a symbolic link. - Consider warning users that entries are stored as plaintext and offer encryption for particularly sensitive journal content.

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/script.sh:67
Finding
JSON and CSV Exports Do Not Safely Encode User-Controlled Values## Vulnerability Details **File Location**: `scripts/script.sh`, lines 67-84 **Vulnerability Type**: Improper output encoding and CSV formula injection **Risk Level**: Medium ### Vulnerable Code ```bash while IFS='|' read -r ts val; do [ $first -eq 1 ] &amp;&amp; first=0 || echo "," >> "$out" printf ' {"type":"%s","time":"%s","value":"%s"}' "$name" "$ts" "$val" >> "$out" done < "$f" ``` ```bash echo "type,time,value" > "$out" for f in "$DATA_DIR"/*.log; do [ -f "$f" ] || continue local name=$(basename "$f" .log) while IFS='|' read -r ts val; do echo "$name,$ts,$val" >> "$out" done < "$f" done ``` ```bash txt) echo "=== Dailylog Export ===" > "$out" for f in "$DATA_DIR"/*.log; do [ -f "$f" ] || continue echo "--- $(basename "$f" .log) ---" >> "$out" cat "$f" >> "$out" echo "" >> "$out" done ;; ``` ### Technical Analysis Journal values originate from command-line input and are stored without restrictions on quotes, backslashes, commas, or spreadsheet formula prefixes. The JSON exporter inserts these values directly into quoted JSON strings without escaping them. A value containing a double quote, backslash, control character, or embedded newline can therefore produce malformed or structurally altered JSON. The CSV exporter concatenates fields with commas without applying RFC 4180 quoting. Values containing commas, quotes, or line breaks can create additional fields or records. More importantly, values beginning with formula-significant characters such as `=`, `+`, `-`, or `@` can be interpreted as formulas when the CSV file is opened in spreadsheet software. This is not shell command injection because the values are passed as quoted arguments to `printf` or `echo`. Exploitation instead occurs in downstream JSON consumers or spreadsheet applications that trust the generated export. ### Attack Path 1. An ...[truncated 1249 chars]
Remediation
## Remediation Suggestions - Generate JSON with a proven encoder such as `jq`, Python's `json` module, or another serializer that correctly escapes strings. - Do not construct JSON through direct string interpolation. - Implement RFC 4180 CSV encoding: - Wrap every field in double quotes. - Replace each embedded double quote with two double quotes. - Preserve embedded commas and newlines within quoted fields. - If exports are expected to be opened in spreadsheets, neutralize formula prefixes by prepending a single quote or another application-appropriate safe marker to values beginning with `=`, `+`, `-`, or `@`. - Add tests covering quotes, commas, backslashes, carriage returns, newlines, Unicode, and formula-like values.

T09 · Insecure Skill Coding Practices

Note
Location
scripts/script.sh:112
Finding
Search Terms Beginning with Hyphens Are Interpreted as grep Options## Vulnerability Details **File Location**: `scripts/script.sh`, lines 112-116 **Vulnerability Type**: Argument injection into a local utility **Risk Level**: Low ### Vulnerable Code ```bash _search() { local term="${1:?Usage: dailylog search <term>}" echo "Searching for: $term" local found=0 for f in "$DATA_DIR"/*.log; do [ -f "$f" ] || continue local matches=$(grep -i "$term" "$f" 2>/dev/null || true) ``` ### Technical Analysis Quoting `"$term"` prevents shell word splitting and shell metacharacter interpretation, but it does not stop `grep` from treating a value beginning with `-` as an option. Because the command does not include the `--` end-of-options marker, an attacker-controlled search term can modify `grep` behavior. For example, a long option accepted by the installed `grep` implementation could cause another local file to be consumed as a pattern source. Other options can change matching semantics or increase resource consumption. The input is not evaluated by a shell, so arbitrary shell command execution is not established by this code. The search also uses regular-expression matching when the documented behavior only requires a keyword or phrase search. This unnecessarily exposes regular-expression complexity and behavior to user-controlled input. ### Attack Path 1. An attacker supplies or persuades the victim to use a search term beginning with a hyphen. 2. The script passes the value to `grep` without an end-of-options marker. 3. `grep` interprets the search term as one or more command-line options rather than as the intended pattern. 4. Depending on the option and local `grep` implementation, grep may read an attacker-selected local pattern file, perform unexpectedly expensive processing, or produce misleading search results. 5. The script suppresses grep error output and uses `|| true`, reducing the visibility of abnormal behavior. ### Impact Assessment ...[truncated 404 chars]
Remediation
## Remediation Suggestions - Insert the standard end-of-options marker before the user-controlled pattern. - Use fixed-string matching because the command is documented as a keyword or phrase search: ```bash local matches matches=$(grep -iF -- "$term" "$f" 2>/dev/null || true) ``` - Consider limiting search-term length to prevent unnecessarily expensive processing. - Return or display grep errors rather than silently suppressing every failure. - Add regression tests for search terms beginning with `-`, `--`, and grep option names.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (6)

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The skill metadata describes a narrow reflection/journaling tool, but the documented behavior is materially broader: it supports arbitrary logging categories, full-text search, export, archive, and filesystem/status reporting. This mismatch can mislead users or higher-level agents about what data is collected and what operations are available, increasing the chance of unintended retention, discovery, or disclosure of personal information.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The skill explicitly stores timestamped personal logs locally in plain-text files, but it provides no warning that users may record sensitive personal or work information that will persist on disk. In a journaling/reflection context, this is more dangerous because users are likely to enter intimate, health, workplace, or other sensitive details under the assumption of a benign productivity feature.

Missing User Warnings

Medium
Confidence
89% confidence
Finding
The export feature can aggregate all stored entries into json/csv/txt files without any warning that this broadens exposure and creates easily shareable copies of potentially sensitive logs. In the context of personal productivity journaling, exports can unintentionally expose a user's full history, including reflections, reminders, and tracked habits, if the files are synced, emailed, or left in accessible directories.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The script persistently stores all user-entered reflections and activity history under a predictable path in the user's home directory without any privacy notice, retention controls, or sensitivity warning. Because journaling content may contain personal, health, work, or credential-like information, silent long-term storage increases the risk of unintended disclosure to other local users, backups, or support tooling.

Description-Behavior Mismatch

Medium
Confidence
92% confidence
Finding
The manifest description is narrowly scoped to recording daily wins, challenges, learnings, streak tracking, and weekly progress review. In contrast, the help text and dispatcher expose additional capabilities such as planning, reminders, prioritization, tagging, archiving, timeline management, reporting, exporting, and health/status functions that go well beyond simple reflection logging.

Context-Inappropriate Capability

Medium
Confidence
87% confidence
Finding
Commands like plan, remind, prioritize, archive, tag, timeline, and report implement task-management and organizational features rather than recording daily wins, challenges, and learnings. These capabilities are not an obvious implementation detail of journaling or streak tracking and therefore represent context-inappropriate expansion of the skill's role.

Static analysis

No suspicious patterns detected.