Back to skill

Security audit

Picnic Grocery

Security checks for vulnerabilities and agentic risk

Overview

This grocery-ordering skill is mostly purpose-aligned, but it handles Picnic credentials and account data in ways that can leak sensitive information.

Review this skill before installing. Use it only if you are comfortable giving it access to your Picnic account, cart, address, and delivery history. Avoid entering your password as a command-line argument, do not share command output from login or 2FA flows, and treat the included debug.mjs file as unsafe for normal use because it can print raw account delivery data.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (3)

T09 · Insecure Skill Coding Practices

Warning
Location
picnic-cli.mjs:45
Finding

Account Credentials Exposed Through Command-Line Arguments

Content
View full analysis
[countryCode=DE]' }); process.exit(1); } ``` The corresponding documented command is: ```bash node {baseDir}/picnic-cli.mjs login DE ``` ### Technical Analysis The login command obtains the Picnic account password directly from `process.argv`. Command-line arguments are not an appropriate channel for secrets because they may be: - Recorded in shell history. - Visible to other processes or users through operating-system process inspection facilities. - Captured in Agent execution traces, terminal session logs, audit logs, or process monitoring systems. - Retained by wrappers or automation platforms that log invoked commands. Although the password is not explicitly written to a project file, exposing it through the process argument vector creates an avoidable local disclosure risk. ### Attack Path 1. A user follows the documented setup instructions and runs the login command with their email address and password. 2. The shell records the complete command, or the operating system exposes the active process arguments. 3. A local user, monitoring process, execution wrapper, or log reader obtains the password. 4. The exposed credentials are used to attempt access to the victim's Picnic account. 5. If additional authentication is not required or can be separately satisfied, the attacker may access account and grocery-ordering functionality. ### Impact Assessment Successful exploitation exposes the user's Picnic account credentials. The resulting access is limited to privileges available to that Picnic account but may include acce ...[truncated 227 chars]
Remediation
View remediation
[countryCode] ``` The CLI should then securely prompt for the password. - Warn users to remove existing password-bearing commands from shell history and execution logs. - Add automated tests confirming that secrets are never included in command arguments, normal output, or error output. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
picnic-cli.mjs:66
Finding

Authentication Key Disclosed in Two-Factor Authentication Output

Content
View full analysis
', authKey: result.authKey }); } ``` ### Technical Analysis When login requires a second authentication factor, the CLI deliberately returns `result.authKey` in its JSON output. The key is already stored in the local configuration file, so disclosing it in standard output is unnecessary. Standard output is frequently collected by Agent transcripts, terminal logging, shell redirection, CI systems, observability products, and command wrappers. Consequently, the authentication material can persist in locations with weaker access controls than the mode-`0600` configuration file. The key is generated during an incomplete 2FA flow, so its exact independent capabilities depend on the external service. Nevertheless, it is sensitive authentication material and could facilitate session theft or abuse of the pending authentication flow. ### Attack Path 1. A user invokes the login command and the Picnic service requires two-factor authentication. 2. The service returns an authentication key for the pending authentication flow. 3. The CLI writes the key to standard output as the `authKey` JSON property. 4. An Agent transcript, terminal log, redirected output file, CI log, or local observer captures the key. 5. An attacker obtains the captured key and attempts to reuse it against the Picnic API, including continuing or interfering with the pending authentication flow. 6. If the key is accepted in the relevant flow, the attacker gains the account c ...[truncated 548 chars]
Remediation
View remediation
' }); ``` - Keep the pending key only in protected local storage and ensure that existing configuration files retain restrictive permissions. - Consider storing authentication material in an operating-system credential manager rather than a plaintext JSON file. - Review exception handling and dependency responses to ensure authentication keys cannot appear in error messages. - Add centralized output redaction for fields such as `authKey`, `password`, `token`, `authorization`, and session identifiers. - Invalidate or rotate previously exposed authentication material where supported. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
debug.mjs:6
Finding

Undocumented Debug Script Prints Raw Authenticated Delivery Data

Content
View full analysis
Remediation
View remediation
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (7)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The documentation explicitly instructs users to provide their email and password as command-line arguments, which can expose credentials through shell history, process listings, audit logs, and terminal recording systems. In the context of a grocery-ordering skill tied to a real consumer account, this can enable account takeover, access to personal address/order data, and unauthorized cart or delivery changes.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
91% confidence
Finding

The code reads an authentication key from the user's local config file and immediately makes it available to the script without any consent flow, warning, or scope limitation. In a skill context, this is risky because it normalizes silent access to stored credentials and makes accidental misuse, debugging leakage, or later malicious extension of the script much easier.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The script uses the loaded authentication data to perform an authenticated network request without any visible disclosure or runtime confirmation. In a grocery-ordering skill, authenticated API calls are expected, but doing so silently in a standalone debug script increases the risk of unauthorized account access, unintended account activity, and data exposure if the script is run in the wrong context.

Content

No source excerpt is available for this finding.

Missing User Warnings

High
Category
Not specified by scanner
Confidence
99% confidence
Finding

During the 2FA-required login path, the CLI prints result.authKey back to stdout. In agent, shell, and tool-integrated environments, stdout is often logged, surfaced to other components, or stored in transcripts, so exposing a live authentication token can enable account takeover or session hijacking without needing the user's password or 2FA code.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
88% confidence
Finding

The user command outputs sensitive personal data including full name, email, phone, address, and household details directly to stdout. In a skill/agent context, this makes unnecessary PII readily available to logs, calling agents, and downstream consumers, increasing privacy and data-leak risk.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
90% confidence
Finding

The status command returns personally identifying information such as name, email, and address when checking login state. A status/check-health style command is likely to be invoked frequently and implicitly, so embedding PII in its output unnecessarily broadens exposure through logs and agent transcripts.

Content

No source excerpt is available for this finding.

Unpinned Dependencies

Low
Category
Supply Chain
Confidence
94% confidence
Finding

The dependency version is specified with a caret range (^3.2.0), which allows newer minor and patch releases to be installed. This can introduce supply-chain risk because future upstream releases may contain malicious code or breaking security changes without this package being explicitly reviewed or locked by the skill author.

Content

Scanner excerpt · package.json (reported line 9)May include surrounding context.

json
"picnic": "./picnic-cli.mjs"
  },
  "dependencies": {
    "picnic-api": "^3.2.0"
  }
}

Static analysis

No suspicious patterns detected.