MH bear-notes

• Outcome: Review
• Latest audit: Sep 10, 2026 · 11:28 PM UTC
• Version: 1.0.0

Overview

The skill does what it says for Bear notes, but it should be reviewed because it installs an unpinned third-party CLI and asks users to store a Bear API token in plaintext without security guidance.

Install only if you trust the grizzly upstream dependency and are comfortable giving it Bear note access. Prefer a pinned reviewed version of grizzly, store the Bear token with owner-only permissions, avoid committing or sharing the token file, and rotate the Bear API token if it may have been exposed.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:12
• Finding: Unpinned Third-Party Executable Dependency## Vulnerability Details **File Location**: `SKILL.md`, lines 12–19 **Vulnerability Type**: Supply-chain risk from a mutable dependency reference **Risk Level**: Medium ### Vulnerable Code ```yaml "requires": { "bins": ["grizzly"] }, "install": [ { "id": "go", "kind": "go", "module": "github.com/tylerwince/grizzly/cmd/grizzly@latest", "bins": ["grizzly"], "label": "Install grizzly (go)", }, ``` ### Technical Analysis The installation configuration retrieves the `grizzly` executable using the mutable Go module version `@latest`. Consequently, the installed code can change after this skill has been reviewed without any corresponding modification to the audited project. Because the dependency is sourced from an external GitHub namespace and no immutable version, commit, checksum, or signature is specified, a compromised publisher account, compromised upstream repository, or malicious future release could cause installation of attacker-controlled code. ### Attack Path 1. An attacker compromises the upstream repository, its maintainer account, or its release process. 2. The attacker publishes a malicious release that resolves as `@latest`. 3. A user or agent installs the skill dependency according to the manifest. 4. The Go installer downloads and builds the attacker-controlled version. 5. The resulting `grizzly` binary executes with the invoking user's privileges when the documented commands are used. 6. The malicious binary can access resources available to that user, potentially including Bear notes and the configured Bear token. ### Impact Assessment Successful exploitation permits arbitrary behavior within the privileges of the user installing or invoking the dependency. Potential effects include reading or modifying Bear notes, stealing the Bear API token, accessing other user-readable files, and executing additional local commands. The project itself does ...[truncated 150 chars]
• Remediation: ## Remediation Suggestions - Replace `@latest` with a specifically audited semantic version or immutable commit. - Prefer a release with published checksums or cryptographic signatures, and verify those artifacts before installation. - Record the expected upstream repository and reviewed version in the skill documentation. - Introduce a controlled dependency-update process that requires review and testing before changing the pinned version. - Where supported, generate and retain dependency provenance or software bill-of-materials information.

T09 · Insecure Skill Coding Practices

Note

• Location: SKILL.md:34
• Finding: Bear API Token File Created Without Explicit Restrictive Permissions## Vulnerability Details **File Location**: `SKILL.md`, line 34 **Vulnerability Type**: Insecure plaintext credential-file creation **Risk Level**: Low ### Vulnerable Code ```bash echo "YOUR_TOKEN" > ~/.config/grizzly/token ``` ### Technical Analysis The documented setup command writes a Bear API token to a plaintext file but does not explicitly create the parent directory with private permissions or restrict the resulting file to its owner. The file's permissions therefore depend on the user's active `umask` and any pre-existing directory or file permissions. Under permissive local permission settings, another local account or process may be able to read the token. The token is subsequently supplied to `grizzly` for token-authorized operations such as adding text, listing tags, or opening selected notes. ### Attack Path 1. A user follows the documented token setup command while operating under a permissive `umask`, or writes into a pre-existing path with unsuitable permissions. 2. The token file is created or retained with permissions that allow unintended local access. 3. Another local user or compromised process reads `~/.config/grizzly/token`. 4. The attacker supplies the stolen token to compatible Bear or `grizzly` operations. 5. The attacker performs Bear actions authorized by that token. Exploitation requires local access through another account or process and depends on the host's actual permission configuration. ### Impact Assessment Exposure is limited to the authority granted by the Bear API token. Based on the audited documentation, this may include reading selected note data, listing tags, or modifying notes through supported token-authenticated operations. This issue does not itself grant operating-system privilege escalation, and exploitability is reduced on systems already using a restrictive `umask`.
• Remediation: ## Remediation Suggestions Create the configuration directory and token file with explicit owner-only permissions: ```bash install -d -m 700 ~/.config/grizzly (umask 077 && printf '%s\n' "YOUR_TOKEN" > ~/.config/grizzly/token) chmod 600 ~/.config/grizzly/token ``` Additionally: - Verify ownership before overwriting an existing token file. - Refuse symbolic links at the destination where practical. - Avoid exposing the token through command history; prefer an interactive hidden prompt or secure secret-storage integration. - Document token rotation and revocation procedures in case of suspected disclosure. - Prefer the macOS Keychain over a plaintext file if supported by the tool.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (1)

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The skill instructs users to place a Bear API token in a predictable plaintext file path without warning that the token is a credential that can authorize note-accessing and note-modifying operations. This increases the chance the secret will be stored with weak permissions, exposed through backups, shell history, screenshots, or local compromise, enabling unauthorized access to private notes.

Static analysis

No suspicious patterns detected.