Bitwarden Credential

• Outcome: Review
• Latest audit: Sep 15, 2026 · 1:41 AM UTC
• Version: 1.0.0

Overview

This Bitwarden skill is purpose-aligned but asks an agent to handle live vault session tokens and plaintext secrets in unsafe command-line paths.

Review before installing. Only use a Bitwarden helper that keeps BW_SESSION and plaintext secrets out of chat, command history, process arguments, and agent transcripts. Prefer running Bitwarden CLI locally with the session already in the environment, hidden prompts or stdin for secrets, and sanitized output that never prints created-item JSON.

A.I.G

Vulnerability Patterns

• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/bitwarden-credential.sh:22
• Finding: Credentials Exposed Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/bitwarden-credential.sh`, lines 22-29 **Vulnerability Type**: Sensitive information exposure through process arguments **Risk Level**: High ### Vulnerable Code ```bash NAME="${1:-}" USERNAME="${2:-}" PASSWORD="${3:-}" NOTES="${4:-}" if [ -z "$NAME" ] || [ -z "$USERNAME" ] || [ -z "$PASSWORD" ]; then echo "Usage: bitwarden-credential.sh <name> <username> <password> [notes]" exit 1 fi ``` The insecure invocation pattern is also explicitly documented in `SKILL.md`, lines 32-40 and 49: ```bash BW_SESSION="<session-key>" ./bitwarden-credential.sh <name> <username> <password> [notes] ``` ```bash ./scripts/bitwarden-credential.sh "<name>" "<username>" "<password>" "[notes]" ``` ### Technical Analysis The script accepts passwords, API keys, OAuth tokens, and other secrets as positional command-line arguments. Command-line arguments are not an appropriate transport for sensitive values because they can be exposed through: - Process inspection interfaces such as `ps` or `/proc`. - Shell command history. - Agent command transcripts and execution telemetry. - Endpoint monitoring and operating-system audit logs. - CI/CD logs or debugging output that records executed commands. Quoting the arguments prevents shell word splitting but does not prevent their disclosure through process metadata or command logging. ### Attack Path 1. A user or AI agent follows the documented invocation pattern and includes a credential as the third argument. 2. The shell starts the script with the secret present in its argument vector. 3. A process monitor, local process running under an authorized account, shell-history collector, audit subsystem, or agent telemetry system records the command arguments. 4. An attacker obtains access to the process data, history, transcript, or logs. 5. The attacker extracts and reuses the password, API key, or OAuth token. ### Impact Assessment Successful exploitation discloses the cr ...[truncated 421 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not accept passwords or tokens as positional command-line arguments. - Read the secret from standard input or a dedicated file descriptor. For interactive use, use a hidden prompt such as `read -r -s`. - Keep non-sensitive fields such as the item name and username separate from secret input. - Avoid generating or logging commands that contain credentials. - Update `SKILL.md` so none of its examples place passwords, tokens, or session keys directly on a command line. - Where automation requires non-interactive input, pass the secret through a protected pipe or permission-restricted temporary mechanism and ensure it is never written to logs. - Clear temporary shell variables when they are no longer required, while recognizing that this does not remediate prior argument-vector exposure. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/bitwarden-credential.sh:59
• Finding: Bitwarden Vault Session Token Exposed in Process Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/bitwarden-credential.sh`, line 59 **Vulnerability Type**: Session token exposure through process arguments **Risk Level**: High ### Vulnerable Code ```bash echo "$ITEM_B64" | bw create item --session "$BW_SESSION" ``` ### Technical Analysis Although the session token initially resides in the `BW_SESSION` environment variable, the script expands it into the `bw` command's `--session` argument. This places the active Bitwarden session key in the child process's argument vector. On systems where process arguments can be inspected, another local process or monitoring component may capture the session token while `bw` is running. Process accounting, endpoint telemetry, debugging tools, and audit logs may also persist the argument after the command completes. A Bitwarden session token represents an unlocked vault session. Its compromise is more severe than disclosure of a single credential because it may permit operations against multiple items in the user's vault until the session expires or the vault is locked. ### Attack Path 1. The user unlocks the Bitwarden vault and exports a valid `BW_SESSION` value. 2. The script invokes `bw create item --session "$BW_SESSION"`. 3. The shell expands the token and places it in the `bw` process argument vector. 4. A local observer, process-monitoring utility, endpoint agent, or audit system captures the arguments. 5. An attacker obtains the captured session token. 6. Before the session expires or the vault is locked, the attacker supplies the token to Bitwarden CLI commands and performs operations allowed by that unlocked session. ### Impact Assessment The attacker may gain access to the user's unlocked Bitwarden vault for the lifetime of the stolen session. Depending on the account, vault organization, and Bitwarden authorization model, this may expose passwords, API keys, secure notes, identities, and other stored secrets. The token could also permit crea ...[truncated 185 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not include the session token in the `bw` command's argument vector. - Allow the Bitwarden CLI to consume the inherited `BW_SESSION` environment variable instead: ```bash printf '%s' "$ITEM_B64" | bw create item ``` - Do not document invocation examples that place `BW_SESSION` directly before a command where shell history or automation logs may capture it. - Run the Skill only in a trusted, least-privileged environment with appropriately restricted process visibility. - Lock the vault promptly after the required operation when continued unlocked access is unnecessary. - Avoid logging environment variables, command traces, or debugging output while handling the session. - If exposure is suspected, lock the vault immediately to invalidate the session and authenticate again. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/bitwarden-credential.sh:58
• Finding: Created Vault Item May Be Disclosed Through Standard Output<![CDATA[ ## Vulnerability Details **File Location**: `scripts/bitwarden-credential.sh`, lines 58-60 **Vulnerability Type**: Sensitive command response written to standard output **Risk Level**: High ### Vulnerable Code ```bash echo "Storing: $NAME" echo "$ITEM_B64" | bw create item --session "$BW_SESSION" echo "Done." ``` ### Technical Analysis The script does not capture, filter, or redirect the output of `bw create item`. Consequently, the Bitwarden CLI response is forwarded directly to the script's standard output. If the CLI returns the created item representation, that response may contain the login username, password, notes, or other item metadata. In an AI-agent environment, standard output is commonly retained in conversation transcripts or execution records. It may also be collected by terminal loggers, CI/CD systems, centralized logging agents, or calling applications. The script's success messages do not prevent the intervening CLI response from being displayed or persisted. ### Attack Path 1. A user or agent invokes the script to store a credential. 2. The script submits the Base64-encoded item to `bw create item`. 3. The Bitwarden CLI returns information about the newly created item on standard output. 4. Because the output is neither captured nor sanitized, it is propagated to the terminal, agent transcript, or automation logs. 5. An attacker or unauthorized log reader accesses the retained output. 6. The attacker extracts and reuses any credential or sensitive note included in the response. ### Impact Assessment The vulnerability may disclose the exact credential that was intended to be protected in Bitwarden, along with its username, item name, notes, and metadata. Exposure scope depends on the CLI response and the retention and access controls of the surrounding terminal, agent, or logging environment. Compromise of the disclosed credential may grant access to the associated external account or service. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Capture the Bitwarden CLI response instead of forwarding it directly to standard output. - Validate the command's exit status and emit only a fixed, non-sensitive success message. - If an item identifier is required, parse and print only the identifier after confirming that it is not sensitive. - Never print the complete created-item JSON, password, notes, session token, or encoded item payload. - Use `printf` rather than `echo` for controlled input handling. - Configure agent, terminal, and automation environments to avoid retaining sensitive command output. - Add automated tests that verify no password, token, notes value, or complete vault item appears on stdout or stderr during successful and failed executions. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• 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

Findings (6)

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: Passing `BW_SESSION` and secrets directly on the command line can expose them through shell history, process listings, terminal scrollback, or local audit/logging tools. Because this skill handles highly sensitive material, documenting this pattern without warnings or safer alternatives materially increases the risk of credential leakage on the user's machine.

Missing User Warnings

High

• Confidence: 96% confidence
• Finding: The example shows secret material embedded in a literal shell command, which may be captured in shell history, clipboard history, terminal logging, or monitoring tooling. Even though the destination is a password manager, the handling path is unsafe because the plaintext secret is exposed before it reaches Bitwarden.

Ssd 3

High

• Confidence: 99% confidence
• Finding: This skill explicitly instructs the user to return a valid Bitwarden session token to the agent so the agent can operate with the user's vault permissions. In the context of an agent skill, this is especially dangerous because it normalizes credential delegation to the agent and can give the agent or any intermediary full access to stored secrets.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The script tells the user to provide the Bitwarden session key back to the agent, effectively transferring a live vault access token. A BW_SESSION value is itself a sensitive credential; exposing it to an agent allows actions against the user's vault for the lifetime of that session and can enable unauthorized secret access or modification.

Vague Triggers

Medium

• Confidence: 91% confidence
• Finding: The trigger phrases are broad enough to match generic requests involving passwords, API keys, or credentials, which can cause the skill to activate outside a clearly intended Bitwarden-storage workflow. In this context, that increases the chance that sensitive secrets are solicited or handled when the user did not explicitly intend to use Bitwarden, creating avoidable exposure and confusion.

Missing User Warnings

Medium

• Confidence: 85% confidence
• Finding: The script packages the provided username and password into JSON and sends them to `bw create item`, which is the core purpose of the skill but still involves handling and transmitting secrets. While there is a minimal status message (`Storing: $NAME`), there is no explicit disclosure in comments or user-facing output that sensitive credentials are being processed and stored via the CLI.

Static analysis

No suspicious patterns detected.