Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

The instructions explicitly write an npm auth token into .npmrc, creating a plaintext credential file in the working directory. Even though the token comes from an environment variable, materializing it to disk increases exposure through backups, accidental commits, local malware, or interrupted cleanup.

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

The note that NPM_PUBLISH_TOKEN is set in ~/.local/keys/env.sh documents a specific secret source location, which meaningfully lowers the bar for credential targeting on a compromised system or by an over-privileged agent. Combined with the nearby instructions, it creates a clear path from secret location to on-disk token use.

This one-liner both materializes the npm token into .npmrc and immediately uses it in a chained command, making credential exposure and accidental execution more likely. Chaining also weakens opportunities for human review and can leave the secret file behind if later segments fail unexpectedly.

The instruction to write ${NPM_PUBLISH_TOKEN} into .npmrc creates a plaintext credential file on disk, which may be read by other local processes, accidentally committed, backed up, or recovered if cleanup fails. Because this is framed as a routine release step, the skill normalizes unsafe credential handling and makes accidental secret exposure more likely.

The dedicated guidance to source NPM_PUBLISH_TOKEN from ~/.local/keys/env.sh and use the '.npmrc trick' documents a concrete secret retrieval and storage workflow that exposes credential material to local compromise, mishandling, and operational mistakes. In this skill's context, which already mentions auto-extracted Slack session credentials, the overall pattern reflects lax secret-handling practices and increases concern about broader credential exposure.

This section states that the tool uses credentials already stored by the Slack desktop app and accesses macOS Keychain material to do so. In a personal automation utility this may be intentional, but in a skill designed for agents it materially lowers the barrier for credential theft and unauthorized account use because the agent can act as the user without separate authorization.

The documented flow reads and decrypts Slack cookies, scans LevelDB for xoxc- tokens, validates them, and reuses them automatically. This is classic credential-access behavior; if abused, it enables impersonation of the Slack user, broad message access, and stealthy persistence through cached tokens.

The skill explicitly describes extracting Slack session credentials from macOS Keychain, cookies, and LevelDB rather than using Slack-supported OAuth. That gives the tool access as the logged-in user and normalizes credential harvesting from local stores, which is highly dangerous in an agent context because any compromised or over-privileged agent can silently inherit full Slack access.

The notes reinforce that the tool is built around Keychain access and Slack local storage path inspection. In the context of an agent skill, this makes the capability more dangerous because it is packaged as convenience automation while depending on sensitive credential-extraction primitives that can be repurposed for unauthorized access.

The skill is presented as a Slack messaging utility, but its authentication model relies on extracting Slack session material from local app storage, cookies, LevelDB, and macOS Keychain. That is a materially more sensitive behavior than ordinary messaging and could expose user session credentials or normalize credential-harvesting patterns under an innocuous description.

The skill is presented as a Slack messaging utility, but its authentication model relies on extracting Slack session material from local app storage, cookies, LevelDB, and macOS Keychain. That is a materially more sensitive behavior than ordinary messaging and could expose user session credentials or normalize credential-harvesting patterns under an innocuous description.

Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Use of Keychain-backed secret extraction to recover Slack session material is a credential-access capability with direct account implications. A skill that can retrieve or facilitate retrieval of these secrets can be abused to impersonate the user, access private Slack data, and persist beyond a normal bot-scoped integration.

The implementation does not authenticate to Slack through a normal user-approved flow; it harvests session material directly from macOS Keychain, Slack cookies, and LevelDB storage. That behavior materially exceeds the declared CLI-based Slack interaction purpose and enables covert account access by reusing desktop session credentials.

The file comment explicitly describes extracting Slack credentials from Keychain, cookies, and LevelDB, which is strong evidence of credential access functionality. In the context of a Slack messaging skill, this is highly dangerous because it facilitates unauthorized recovery and reuse of the user's session secrets.

The getKeychainKey function is specifically designed to query the macOS Keychain for Slack Safe Storage secrets across multiple account names. Accessing these secrets allows subsequent decryption of protected Slack data, enabling session theft and impersonation.

This code actively extracts secrets from local protected storage, decrypts them, and iterates candidate tokens until one validates. That is credential harvesting behavior, not a necessary or proportionate mechanism for checking messages, and it could let the skill impersonate the user in Slack.

The skill accesses macOS Keychain material associated with Slack without any user-facing disclosure or consent flow. Silent access to protected local secrets is dangerous because it bypasses user expectations and is a common precursor to credential theft and account takeover.

This specific line is only an error message referring to the Keychain, not the credential-access action itself. While it is part of a malicious credential-harvesting module, the line alone does not introduce additional exploitability beyond the surrounding implementation.

This line derives an AES key from the Slack Safe Storage secret using PBKDF2 so the code can decrypt the encrypted Slack cookie. That directly operationalizes credential theft by converting protected local secrets into reusable session material.

The skill writes recovered Slack tokens to disk in a local cache file without any visible consent, warning, or protection controls. Persisting stolen or sensitive session credentials increases the window of compromise and exposes them to reuse by other local processes or future exfiltration.

The code sends harvested bearer tokens and decrypted session cookies to Slack's API to test which stolen credentials are valid, all without user awareness. This confirms usable credentials for impersonation and normalizes unauthorized access as part of runtime behavior.