T09 · Insecure Skill Coding Practices
- Location
SKILL.md:223- Finding
Recurring Unencrypted Synchronization of Sensitive Activity Data
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:223-235; additional user-facing instructions atREADME.md:79-91
Vulnerability Type: Sensitive data exposure through unencrypted database snapshots
Risk Level: MediumVulnerable Code
SKILL.md:223-235:markdown ## Remote / Synced Database Access For remote instances (e.g., OpenClaw running on a different machine), the database can be made available by: 1. **Cloud sync**: Copy the DB to a synced folder (Dropbox, OneDrive, iCloud). Use `sqlite3 original.db ".backup '/path/to/synced/copy.db'"` for a safe snapshot. 2. **Set the env var**: `export WHATPULSE_DB="/path/to/synced/whatpulse.db"` on the remote machine. 3. **Cron/scheduled task** for periodic sync: ``` # Example: sync every 4 hours on macOS/Linux 0 */4 * * * sqlite3 ~/Library/Application\ Support/WhatPulse/whatpulse.db ".backup '/path/to/synced/whatpulse.db'" ``` The `.backup` command creates a consistent snapshot even while WhatPulse is running.README.md:79-91:markdown ## Remote Access For AI agents running on a remote server, sync the database periodically. 1. On the WhatPulse machine, schedule a snapshot: ```bash # cron: every 4 hours (adjust as wanted) 0 */4 * * * sqlite3 ~/Library/Application\ Support/WhatPulse/whatpulse.db ".backup '/path/to/synced/whatpulse.db'"-
Sync via cloud storage (Dropbox, OneDrive, etc.) or
rsync. -
On the remote machine:
bash export WHATPULSE_DB="/data/whatpulse.db"text ### Technical Analysis The documented workflow creates a complete SQLite snapshot and places it in a synchronized directory every four hours. No encryption, restrictive file permissions, destination validation, retention controls, or warning about shared-folder and cloud-account exposure is included. The database may contain sensitive behavioral information, including website activity, application usage, keyboard and ...[truncated 2158 chars]-
- Remediation
View remediation
Remediation Suggestions
- Prefer local-only database access and clearly identify remote synchronization as an optional, privacy-sensitive operation.
- Encrypt snapshots before placing them in any synchronized directory. Encryption keys must be stored separately from the snapshot and cloud account.
- Apply restrictive permissions to the snapshot and destination directory, such as owner-only access on supported systems.
- Use an authenticated, encrypted, least-privilege transfer mechanism instead of a generally shared cloud folder.
- Configure the remote account or service with read-only access to only the required snapshot, rather than broader filesystem or cloud-storage access.
- Validate that the destination is not publicly accessible or shared with unintended users before enabling synchronization.
- Define retention and secure-deletion policies so obsolete behavioral snapshots do not accumulate indefinitely.
- Obtain explicit user consent and explain which categories of behavioral data will be copied off-device.
- Avoid recommending a recurring scheduled task as the default. Prefer an explicit, user-initiated export or an opt-in schedule with documented removal instructions.
- Document how to disable the cron entry, revoke remote access, remove historical snapshots, and rotate encryption credentials after suspected exposure.
