Security audit
Security checks for vulnerabilities and agentic risk
This skill is mostly transparent about what it does, but it can automatically read and decrypt WorkBuddy credentials and extract a local build key from a running client process, which needs careful review before use.
Install only if you understand that this skill may access WorkBuddy local credential files, decrypt an access token, attach a debugger to a running WorkBuddy client, and save a reusable local build key. Avoid broad or automatic scheduling unless you are comfortable with that credential access, and protect or remove any generated at_rest_buildkey.json file if you stop using the skill.
The script launches CDP tooling against the running client, extracts atRestSecretKey, and writes it to disk in JSON form. This is a credential/secret-recovery workflow that can enable decryption of locally protected data and persistence of that capability, which is far beyond daily check-in functionality and poses severe compromise risk.
The documented behavior includes CDP/WebSocket runtime evaluation against a live client and extraction of cryptographic key material for local decryption, yet the declared purpose remains a simple rewards check-in. This understatement is dangerous because it conceals credential-access and secret-persistence risks behind a benign workflow.
The documented behavior includes CDP/WebSocket runtime evaluation against a live client and extraction of cryptographic key material for local decryption, yet the declared purpose remains a simple rewards check-in. This understatement is dangerous because it conceals credential-access and secret-persistence risks behind a benign workflow.
The documented behavior includes CDP/WebSocket runtime evaluation against a live client and extraction of cryptographic key material for local decryption, yet the declared purpose remains a simple rewards check-in. This understatement is dangerous because it conceals credential-access and secret-persistence risks behind a benign workflow.
The documented behavior includes CDP/WebSocket runtime evaluation against a live client and extraction of cryptographic key material for local decryption, yet the declared purpose remains a simple rewards check-in. This understatement is dangerous because it conceals credential-access and secret-persistence risks behind a benign workflow.
The documented behavior includes CDP/WebSocket runtime evaluation against a live client and extraction of cryptographic key material for local decryption, yet the declared purpose remains a simple rewards check-in. This understatement is dangerous because it conceals credential-access and secret-persistence risks behind a benign workflow.
The summary markets the skill as simple automatic check-in, but the body shows it can recover protected credentials by extracting a decryption/build key from a live client. That understated description makes the skill more dangerous because users may invoke it casually without understanding it can access sensitive authentication material.
A self-healing feature that attaches a debugger to a running application to extract a build key is not proportionate to the stated task of daily check-in. This introduces a credential-recovery and live-process-inspection mechanism that could be abused to access protected application secrets or normalize invasive debugging behavior without clear user consent.
This script enables attaching Node/V8 debugging to an already-running process via process._debugProcess(pid), which is far beyond what a daily check-in skill needs. Debug attachment can expose runtime state and enable powerful inspection or manipulation of another process, making it a dangerous capability in this context.
The module docstring explicitly states that the script self-heals by extracting a WorkBuddy at-rest build key from a running client. For a daily check-in skill, recovering a client decryption/build key is unrelated and grants access to broader protected local data, indicating deliberate overreach beyond the advertised feature.
This code enumerates local processes, identifies WorkBuddy instances, and selects candidate PIDs for inspection. In the context of a simple points/check-in automation skill, process discovery for the purpose of attaching to the client is unnecessary and materially increases risk by enabling unauthorized introspection of the user's local application state.
The script silently writes a sensitive atRestSecretKey to disk without a clear, informed user confirmation. Persisting extracted secret material increases exposure to local compromise, accidental disclosure, or later misuse by other tools or malware.
The code reads a stored secret (atRestSecretKey via workbuddyStorage.loggerGet), serializes the containing object, and emits it on stdout as JSON without any interactive warning, consent, or scope limitation. Exposing a secret key through process output makes it easy for the caller, logs, wrappers, or other local tooling to capture and reuse credentials, leading to account compromise or unauthorized API access.
The script uses process._debugProcess(pid) to attach a V8 inspector to another local process, then evaluates JavaScript inside that process to access internal Electron storage and extract sensitive data. This is an invasive cross-process introspection capability that effectively bypasses normal application boundaries; in the context of a simple daily check-in skill, it is far more privileged than necessary and creates a clear credential-theft primitive.
This script attaches to a running WorkBuddy client over the Node inspector, invokes an internal API to retrieve atRestSecretKey, and persists that key to disk. The extracted key is explicitly described as a build-level constant used to decrypt local credential envelopes, which is unrelated to the stated purpose of performing a daily check-in and materially increases the ability to access protected local secrets.
The script silently writes a sensitive decryption/build key to at_rest_buildkey.json and also prints the key to stdout, creating multiple unnecessary exposure paths. There is no user notice, consent, or protective handling, and the surrounding comments state the key can be reused offline to decrypt local credential envelopes, making the behavior especially dangerous.
The code implements a deliberate secret-extraction capability by querying electron.workbuddyStorage.loggerGet() and pulling atRestSecretKey for offline reuse. In the context of a check-in automation skill, this is unjustified functionality that can enable decryption of local credential material and broader compromise beyond the advertised feature.
The skill declares no explicit permission or allowed-tools scope even though its documented behavior includes reading environment variables and files, writing cache files, making network requests, and invoking Python/Node helpers. Missing scope declarations increase the chance that an automation framework grants broader execution than users expect, especially given the skill also handles credentials and local process interaction.
The invocation phrases are broad and overlap with common language such as '签到' or 'checkin', which can cause accidental activation of a skill that performs sensitive credential and process-inspection operations. The danger is elevated by the hidden high-risk behavior behind what sounds like a routine request.
The 'when to use' guidance is ambiguous and broad, encouraging activation whenever users ask about points or sign-in status. For a skill that may read credentials and attach to a live process during recovery, loose activation criteria increase the chance of unintended execution and surprise access to sensitive local resources.
The manual extraction step is described as 'read-only', but the workflow also writes the recovered build key to a local cache file. This is misleading and matters because persisting decryption material increases the risk of later theft or misuse by other local processes or users.
The documentation does not give a clear upfront warning that self-healing may attach a debugger to a running client process and extract a decryption key. Lack of transparent notice undermines informed consent and makes a sensitive local-inspection capability more likely to be triggered unexpectedly.
The trigger set is overly broad for a skill that performs an account-affecting action automatically. Generic phrases such as "签到" and "checkin" can plausibly appear in unrelated conversation or scheduling contexts, increasing the chance of unintended invocation and unauthorized execution of the daily check-in flow.
This code can load a locally cached at-rest secret key or an environment-provided secret, then decrypt protected credential fields into plaintext JWTs. For a skill whose stated purpose is only daily check-in, this capability expands access to sensitive credentials beyond the minimum needed and creates a reusable primitive for secret extraction or repurposing if the skill or surrounding agent is abused.
The functions load_build_key, decrypt_field, and unwrap silently retrieve secret material and decrypt credential envelopes without any user-facing disclosure or consent checkpoint. In an agent skill context, that opacity is risky because users may invoke a simple 'check in' action without realizing the skill can access and transform stored secrets into plaintext credentials.
No suspicious patterns detected.
