Back to skill

Security audit

SOLO.ro cli

Security checks for vulnerabilities and agentic risk

Overview

This skill is coherent for SOLO.ro accounting access, but it asks users to install an unpinned third-party CLI and store financial account secrets locally while documenting destructive queue deletion without clear safeguards.

Review this before installing. Use only if you trust the `solo-cli` Homebrew tap and are comfortable giving that CLI access to SOLO.ro financial records. Protect `~/.config/solo-cli/config.json` and `cookies.json` with owner-only permissions, avoid cloud-synced or shared locations, and require explicit confirmation before any queue deletion.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:13
Finding

Unpinned Executable Installed from an Unverified Third-Party Homebrew Tap

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 13-16
Vulnerability Type: Supply-chain exposure through an unpinned third-party dependency
Risk Level: Medium

Vulnerable Code Snippet:

markdown
If the `solo-cli` command is not available, install via Homebrew:
```bash
brew install rursache/tap/solo-cli
text

### Technical Analysis

The Skill instructs the user or agent to install and execute `solo-cli` from the third-party Homebrew tap `rursache/tap`. It does not pin an immutable version or commit, validate a checksum or cryptographic signature, or provide source code that can be audited alongside the Skill.

Consequently, the code executed by this command can change after the Skill has been reviewed. Homebrew formula installation may execute formula-controlled installation logic, and the resulting CLI receives access to SOLO.ro credentials, reusable session cookies, uploaded financial documents, and accounting records. The repository does not contain the CLI implementation, so its network destinations, credential handling, transport security, and data processing cannot be independently verified.

Network communication with SOLO.ro is necessary for the declared functionality. The issue is not network access itself, but the delegation of that sensitive access to a mutable, unaudited third-party executable.

### Attack Path

1. An attacker compromises the third-party Homebrew tap, its maintainer account, release infrastructure, or an artifact referenced by the formula.
2. The attacker modifies the formula or distributed executable while retaining the expected `solo-cli` name.
3. A user or agent follows the Skill instruction and runs `brew install rursache/tap/solo-cli`.
4. Homebrew downloads and installs the modified component, potentially executing formula-controlled installation logic.
5. The installed CLI reads the configured SOLO.ro username and password or the cached session cookies when in
...[truncated 1002 chars]
Remediation
View remediation

Remediation Suggestions

  • Prefer an official, authenticated distribution channel operated or explicitly endorsed by SOLO.ro.
  • Pin the CLI to an immutable version, release artifact, or audited source commit rather than installing the mutable latest formula.
  • Publish and verify a cryptographic checksum or signature before execution.
  • Include a link to the CLI source and Homebrew formula so their authentication and network behavior can be audited.
  • Configure automated dependency monitoring and repeat security review whenever the pinned version changes.
  • Document the expected API hosts and reject unexpected outbound destinations.
  • Run the CLI with ordinary user privileges and avoid granting it broader filesystem or administrative access.
  • Where feasible, sandbox the CLI so it can access only its required configuration, selected upload files, and SOLO.ro network endpoints.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:19
Finding

SOLO.ro Password and Reusable Session Cookies Stored in Plaintext JSON Files

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 19-22, 39-45, and 145-150
Vulnerability Type: Insecure plaintext storage of authentication secrets
Risk Level: Medium

Vulnerable Code Snippets:

markdown
- Config file location: `~/.config/solo-cli/config.json` (created on first run)
- Use `--config` or `-c` to specify a custom config path
- Credentials are stored locally; never passed as command arguments
- Session cookies are cached to `~/.config/solo-cli/cookies.json` for faster subsequent logins
markdown
Config file structure:
```json
{
  "username": "your_email@solo.ro",
  "password": "your_password",
  "company_id": "12345",
  "page_size": 100,
  "user_agent": "Mozilla/5.0 ..."
}
text

```markdown
## Authentication flow
1. On startup, loads cookies from `~/.config/solo-cli/cookies.json`
2. Validates cookies with a test API call
3. If valid, uses cached session
4. If invalid/missing, logs in with credentials from config
5. Saves new cookies for next session

Technical Analysis

The documented configuration embeds the user's SOLO.ro password directly in a JSON file and caches reusable authentication cookies in another predictable JSON file. Although avoiding command-line arguments reduces exposure through process listings and shell history, the Skill does not require owner-only file permissions, encryption at rest, operating-system credential storage, short-lived sessions, or secret redaction.

Plaintext secrets in predictable filesystem locations may be read by other local users when permissions are weak, malware operating under the user's account, backup software, synchronization utilities, diagnostic archives, or accidentally published home-directory content. A reusable session cookie may permit account access without knowing the password until the server invalidates or expires the session.

The optional --config mechanism also permits creden ...[truncated 1680 chars]

Remediation
View remediation

Remediation Suggestions

  • Store passwords in the operating system's credential manager, such as macOS Keychain, rather than in JSON configuration.
  • Prefer an authorization flow using revocable, narrowly scoped tokens instead of retaining the user's primary password.
  • Avoid persistent password storage where interactive or device-based authentication is available.
  • If local secret files remain necessary, create them with owner-only permissions and explicitly verify mode 0600 and a private parent directory.
  • Refuse to use secret files that are group-readable, world-readable, or located in insecure directories.
  • Minimize cookie lifetime and scope, rotate session state, and provide a command that securely logs out and removes cached cookies.
  • Never include credentials, cookies, authorization headers, or configuration contents in logs, errors, telemetry, or diagnostic output.
  • Warn users against placing custom configuration files in cloud-synchronized, shared, temporary, or version-controlled directories.
  • Document immediate remediation after exposure: revoke active sessions, delete cached cookies, and rotate the SOLO.ro password.
  • Apply least privilege to the account and require explicit user confirmation before destructive operations such as queue deletion.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (3)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The skill documents a destructive command (solo-cli queue delete <ID>) and even shows examples, but provides no warning, confirmation guidance, or safer review workflow before deletion. In an agent setting, this increases the chance that a model translates a vague user request into a data-destructive action that removes queued accounting documents and may disrupt bookkeeping or evidence retention.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill instructs users to place SOLO.ro credentials directly in ~/.config/solo-cli/config.json and says credentials are stored locally, but it does not warn about plaintext-at-rest risk, file-permission hardening, or safer secret handling. Because this skill targets financial/accounting data, compromise of that local config or cached session cookies could expose sensitive business records and allow unauthorized actions in the account.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
87% confidence
Finding

The help text documents a destructive operation (queue delete <id>) without any warning, confirmation behavior, or recovery note. In an accounting context, users may delete queued expense items by mistake, potentially causing loss of bookkeeping data or interrupting invoice/expense processing workflows.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.