Security audit
Security checks for vulnerabilities and agentic risk
Wakehook largely matches its stated wake-automation purpose, but it needs review because it handles sensitive sleep data and long-lived OAuth tokens while leaving a test trigger unauthenticated when its webhook token is unset.
Review before installing. Use poll mode where possible, bind the service to trusted interfaces, set strong webhook/admin tokens, disable or protect /test/replay, send events only to trusted HTTPS endpoints, pin package/container versions, and protect or encrypt the SQLite database that stores Google refresh tokens.
SKILL.md:26Unverified Remote Installer Is Downloaded and Executed Through a Shell
src/server.ts:27Fail-Open Authentication Permits Unauthorized Synthetic Wake and Agent Triggers
src/db.ts:22Long-Lived Google OAuth Tokens Are Stored in Plaintext Without Enforced File Permissions
Dockerfile:5Container Build Falls Back to Unlocked Dependency Resolution
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
bunx wakehook # run without installing — or: bun add wakehook
# or Docker:
docker run -v wakehook-data:/data --env-file .env ghcr.io/robbeverhelst/wakehook
2 · Configure — create config.json in your working directory:
The declared purpose centers on a wakehook integration that connects sleep-data providers to an agent via webhook and triggers wake-based automations. The supplied code does none of that. It is a generic time utility module for timezone formatting and parsing local times. While such helpers could support scheduling logic elsewhere, this chunk by itself does not implement the described wakehook behavior, external integrations, authorization, or webhook delivery. That is a material description-behavior mismatch rather than a mere supporting detail.
The skill recommends curl ... | bash, which executes a remote script directly from the network without prior verification. This is a classic supply-chain risk: if the endpoint, CDN, or transport path is compromised, arbitrary code will run immediately on the user's machine.
## Prerequisites (check, don't assume)
1. **Bun ≥ 1.3** — `bun --version`; install with `curl -fsSL https://bun.sh/install | bash`.
wakehook is Bun-only (`bun:sqlite`); never run it with Node.
2. **Google OAuth credentials** — a Google Cloud project with the **Health API**
enabled and the `googlehealth.sleep.readonly` scope, plus an **OAuth 2.0
The instructions pass .env secrets into a long-running container while also mounting persistent storage, which can expose OAuth credentials and refresh-token material to containerized code. If the image is compromised, mutable, or overly privileged, those secrets may be read and abused for persistent access to the user's Google health data and webhook integrations.
bunx wakehook
(Docker alt: `docker run -v wakehook-data:/data --env-file .env ghcr.io/robbeverhelst/wakehook`.)
Keep it running (long-lived process / service). In poll mode it polls Google
every `pollIntervalMs` **around the morning window only** (set `pollWindowOnly:
false` to poll all day) and, on the morning wake, POSTs the agent once.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
/**
* Google OAuth 2.0 token handling. The one-time `auth` CLI mints the refresh
* token; at runtime we transparently refresh the access token as it nears expiry.
*
* NOTE: publish the OAuth app to "In Production" (still unverified, 100-user cap)
* so the refresh token does not expire after 7 days (the "Testing" default).
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
/**
* Google OAuth 2.0 token handling. The one-time `auth` CLI mints the refresh
* token; at runtime we transparently refresh the access token as it nears expiry.
*
* NOTE: publish the OAuth app to "In Production" (still unverified, 100-user cap)
* so the refresh token does not expire after 7 days (the "Testing" default).
The design materially expands the skill from an agent-specific wake trigger into a vendor-neutral event bus that broadcasts health-derived wake events to multiple consumers. That scope expansion increases attack surface and data exposure risk because users invoking an OpenClaw/Hermes skill would not reasonably expect multi-subscriber redistribution of sensitive sleep/wake data.
Wake times and sleep-session details are sensitive health-adjacent data, and the design explicitly broadcasts them to every subscriber without indicating any explicit user-facing privacy warning or consent flow. In the context of a skill marketed as agent wake automation, silent redistribution to arbitrary URLs is especially dangerous because users may not understand that intimate behavioral data can be copied to multiple external services.
Documented fan-out to arbitrary subscriber URLs exceeds the stated skill purpose and creates a concrete exfiltration path for sensitive health-inferred events. Because each subscriber can be independently configured, a misled user or downstream automation could unknowingly send wake/health metadata to third parties, making the mismatch security-relevant rather than merely architectural.
The README promotes broadcasting health-derived wake events to arbitrary subscribers but does not prominently warn that wake times and inferred sleep information are sensitive personal data. In this skill context, the feature is explicitly about transmitting health-adjacent behavioral data to other services, so lack of privacy guidance increases the risk of accidental disclosure to third parties or insecure endpoints.
The example payload includes a user identifier, wake timestamp, and session duration details, but the documentation does not warn that these fields can reveal sensitive health and behavioral patterns when forwarded to subscribers. Because the skill is designed to integrate with arbitrary URLs and automation platforms, users may unintentionally leak personal data into logs, third-party workflows, or unsecured webhook endpoints.
The README instructs users to run a container image from GHCR without a pinned tag or digest, which makes the deployed artifact mutable over time. That creates a supply-chain risk: a later image change, compromised registry account, or unexpected breaking update could cause users to run unreviewed code.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl -X POST http://localhost:8080/test/replay \
-H "Authorization: Bearer $GOOGLE_WEBHOOK_AUTH_TOKEN" \
-H 'Content-Type: application/json' \
-d '{}' # fires a synthetic wake "now"; pass {"end":"...","durationMin":420} to control it
The skill instructs the agent to handle environment-based secrets and perform network interactions, but it does not declare any explicit tool scope or permission boundary. In a skill system, missing scope declarations increase the chance that an agent executes sensitive actions without clear user visibility or sandbox restrictions.
The skill processes sensitive sleep/health data and instructs the user to store OAuth-derived access material, including a refresh token in a local database, without a clear privacy and retention warning. Health telemetry and long-lived tokens are sensitive; mishandling them can expose private behavioral data and enable ongoing account access.
The webhook-mode instructions tell the user to expose a public HTTPS endpoint and register it with an external provider, but they understate the security implications of exposing an internet-reachable service. A publicly accessible webhook increases attack surface for probing, replay attempts, brute-forcing weak tokens, and misconfiguration that could trigger unauthorized events.
The Docker example pulls and runs ghcr.io/robbeverhelst/wakehook without a fixed tag or digest, so future executions may fetch different, unreviewed code. This creates a supply-chain risk where a compromised or changed image could gain access to mounted data and .env secrets.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl -X POST http://localhost:8080/test/replay \
-H 'Content-Type: application/json' -d '{}'
This code persists OAuth access and refresh tokens in a local SQLite database in plaintext, with no visible encryption, OS keychain integration, access control hardening, or user-facing disclosure. If the host, container filesystem, backup, or local account is compromised, an attacker could recover long-lived refresh tokens and impersonate the user against Google/Fitbit APIs.
The webhook handler parses inbound notifications and then uses the referenced user identifier to obtain an access token and fetch sleep data from the Google Health API. While the code comments describe the mechanism, there is no user-facing confirmation, warning, or disclosure near this path that external notifications will cause retrieval of personal health data.
The manifest positions the skill as enabling wake-triggered automations for the user's agent. The design explicitly documents a generic preset posting raw signed events to arbitrary subscriber URLs, with OpenClaw-specific translation only as an optional preset, indicating a more general integration platform than advertised.
The config sets "timezone": "Europe/Brussels", which imposes a specific locale setting in natural-language terms without any indication here that the user can opt in or override it. Under the policy rule for language/locale constraints, a fixed locale can be a violation unless it is explicitly optional or clearly justified as region-specific.
The runtime dependency hono is specified with a caret range, which allows automatic installation of newer releases within the major version. That weakens reproducibility and can expose deployments to newly introduced vulnerabilities or malicious upstream changes, especially significant here because this skill exposes a webhook-facing service.
"test": "bun test"
},
"dependencies": {
"hono": "^4.6.14"
},
"devDependencies": {
"@semantic-release/changelog": "^6.0.3",
The manifest uses an unpinned hono version even though advisories exist for that package, making it impossible to verify whether the installed version is affected. In this skill's context, hono is the web framework for an inbound webhook service, so framework-level issues such as CSRF, cookie handling, or routing flaws could directly affect externally reachable endpoints.
The dev dependency @semantic-release/changelog is not pinned to an exact version, so CI or release environments may resolve different package versions over time. This is primarily a software supply-chain hygiene issue affecting release integrity rather than direct runtime compromise.
"hono": "^4.6.14"
},
"devDependencies": {
"@semantic-release/changelog": "^6.0.3",
"@semantic-release/exec": "^7.0.0",
"@semantic-release/git": "^10.0.1",
"@semantic-release/npm": "^13.1.0",
Detected: suspicious.exposed_secret_literal