Security audit

Wakehook

Security checks across malware telemetry and agentic risk

Overview

Wakehook appears to be a legitimate wake-automation service, but it needs review because its built-in replay endpoint can trigger wake actions without authentication in common poll-mode setups if the service is reachable.

Review before installing. Use a strong GOOGLE_WEBHOOK_AUTH_TOKEN even in poll mode, bind or firewall port 8080, avoid exposing /test/replay publicly, and remove or block that endpoint in production if possible. Only add subscriber URLs you trust, prefer signed/authenticated subscribers, protect .env and wake.sqlite with restrictive permissions and encrypted backups, and revoke the Google OAuth grant if the host or database is exposed.

SkillSpector

By NVIDIA

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands

Findings (8)

Description-Behavior Mismatch

Medium

Confidence: 95% confidence
Finding: The manifest frames the skill as posting wake events to the user's agent, but the design expands it into a multi-subscriber event bus that broadcasts sensitive wake/sleep data to arbitrary endpoints. This is a scope-expansion and data-sharing risk because operators or future defaults could route personal health-derived events beyond the user's intended agent without clear consent boundaries.

Description-Behavior Mismatch

Medium

Confidence: 94% confidence
Finding: The design adds generic subscriber fan-out and retry/delivery behavior that materially exceeds the stated purpose of notifying the user's agent. In a security-sensitive context involving health-derived events, hidden extensibility increases exfiltration risk, persistence of delivery to unintended receivers, and operator misunderstanding about where personal data is being sent.

Intent-Code Divergence

Medium

Confidence: 87% confidence
Finding: The document contradicts itself by calling additional sinks and generic fan-out out of scope for v1 after describing them elsewhere as active behavior. This inconsistency is dangerous because it can cause reviewers, deployers, or users to underestimate actual data flows and security obligations, especially around health-event broadcasting and third-party delivery.

Context-Inappropriate Capability

Medium

Confidence: 90% confidence
Finding: The `/test/replay` endpoint creates a synthetic wake event and feeds it into `engine.process`, which can trigger downstream morning automations without requiring genuine sleep-provider data. Although it is protected by the same shared-token check as `/webhook`, this capability is not part of the stated user-facing purpose of converting provider sleep events into neutral wake events, so exposure of the token or deployment with auth disabled would let an attacker trigger actions on demand.

Missing User Warnings

Medium

Confidence: 97% confidence
Finding: The design discusses broadcasting wake events to multiple subscribers and storing OAuth tokens locally, but the skill description lacks clear privacy and security warnings about handling health-derived personal data. Because wake times, sleep intervals, and persistent tokens are sensitive, omission of these warnings makes unsafe deployment and uninformed consent more likely.

Missing User Warnings

Medium

Confidence: 82% confidence
Finding: The README instructs users to store OAuth client credentials in a .env file and a long-lived refresh token in the sqlite database, but it does not prominently warn that this service processes highly sensitive health/sleep data and persistent tokens that could enable ongoing access if the host is compromised. In the context of a self-hosted automation tool, this is more of a security/privacy design and documentation weakness than an exploit primitive, but it still increases the chance of negligent handling of sensitive secrets and personal health information.

Missing User Warnings

Medium

Confidence: 87% confidence
Finding: The skill instructs the user to store Google OAuth client credentials and obtain a long-lived refresh token in `wake.sqlite`, but it does not provide a clear privacy and secret-handling warning. If the host, working directory, backups, or logs are exposed, an attacker could reuse the refresh token to access sleep-related account data and maintain ongoing access.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The skill normalizes disabling webhook authentication on loopback with `INSECURE_NO_AUTH` and does not strongly warn about the risk of unauthorized local triggering. On many systems, other local users, containers, browser-based SSRF, or misconfigured port exposure can reach loopback services, allowing spoofed wake events that trigger agent actions.

VirusTotal

65/65 vendors flagged this skill as clean.

View on VirusTotal

Static analysis

Detected: suspicious.exposed_secret_literal

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: src/cli/auth.ts:49

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: src/sources/google/oauth.ts:48