ClawHub
Back to skill

Security audit

Overleaf CLI (olcli)

Security checks for vulnerabilities and agentic risk

Overview

The skill has a coherent Overleaf CLI purpose, but it should be reviewed carefully because it asks users to handle a live Overleaf session cookie without adequate safety guidance.

Install only if you trust the `olcli` upstream package and are comfortable granting it access to your Overleaf projects. Treat `overleaf_session2` like a password: avoid putting it in shell history, shared terminals, logs, screenshots, project directories, or source control, and revoke the browser session if it may have leaked.

A.I.G

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
scripts/install.sh:13
Finding

Unpinned Third-Party CLI Installation

Content
View full analysis

Vulnerability Details

File Location: scripts/install.sh:13-23; also documented in SKILL.md:14-21
Vulnerability Type: Unpinned third-party executable installation
Risk Level: Medium

Complete Code Snippet (scripts/install.sh:13-23):

bash
if command -v brew &> /dev/null; then
    echo "Installing olcli via Homebrew..."
    brew tap aloth/tap
    brew install olcli
    echo "✓ Installed olcli $(olcli --version)"
    exit 0
fi

# Fall back to npm
if command -v npm &> /dev/null; then
    echo "Installing olcli via npm..."
    npm install -g @aloth/olcli

Related Documentation (SKILL.md:14-21):

bash
# Homebrew (recommended)
brew tap aloth/tap && brew install olcli

# npm
npm install -g @aloth/olcli

Technical Analysis

Both installation paths retrieve an unspecified current release of the third-party olcli package. The project does not pin an exact package version, Homebrew tap revision, artifact checksum, or cryptographic signature. It also contains no vendored CLI implementation against which the installed executable can be verified.

The Homebrew path adds the external aloth/tap repository and installs its mutable formula. The npm fallback performs a global installation of the mutable @aloth/olcli package. Package installation may execute package-manager hooks or install executables that subsequently run with the invoking user's permissions. Consequently, the effective code installed by this script can change after this Skill has been reviewed.

This is a supply-chain weakness rather than evidence that the current upstream package is malicious.

Attack Path

  1. An attacker compromises an upstream maintainer account, package registry account, Homebrew tap, release process, or transitive dependency.
  2. The attacker publishes a malicious release while retaining the expected olcli or @aloth/olcli package identity.
  3. A use ...[truncated 1078 chars]
Remediation
View remediation

Remediation Suggestions

  1. Pin npm installation to an explicitly reviewed version, such as @aloth/olcli@<reviewed-version>.
  2. Pin or otherwise verify the Homebrew tap and formula against a reviewed commit or immutable release artifact.
  3. Validate downloaded artifacts with publisher-provided cryptographic signatures or hardcoded checksums obtained through a trusted channel.
  4. Document the exact reviewed package version and trusted upstream source in SKILL.md.
  5. Prefer a project-local installation over npm install -g to reduce host-wide exposure.
  6. Disable unnecessary package lifecycle scripts where compatible with the package and installation workflow.
  7. Add automated dependency monitoring and require security review before updating pinned versions.
  8. Display the resolved version before installation and fail closed if it does not match the approved version.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:25
Finding

Overleaf Session Cookie Exposed Through Command-Line Authentication

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:25-34
Vulnerability Type: Sensitive bearer credential passed as a command-line argument
Risk Level: Medium

Complete Code Snippet (SKILL.md:25-34):

markdown
## Authentication

Get your session cookie from Overleaf:

1. Log into [overleaf.com](https://www.overleaf.com)
2. Open DevTools (F12) → Application → Cookies
3. Copy the value of `overleaf_session2`

```bash
olcli auth --cookie "YOUR_SESSION_COOKIE"
text

### Technical Analysis

The `overleaf_session2` value is an authenticated bearer credential. Anyone who acquires a valid value may be able to impersonate the corresponding session within its validity period and granted permissions.

The documented workflow places this sensitive value directly in a command-line argument. Depending on the operating system, shell, auditing configuration, and execution environment, the value may be retained in shell history, exposed temporarily through process listings, captured by terminal or command telemetry, or included in diagnostic records.

In addition, `references/API.md:17-20` states that the CLI may obtain credentials from a current-directory `.olauth` file or `~/.config/olcli-nodejs/config.json`, but the project does not document restrictive file permissions, source-control exclusions, or secure secret-storage requirements. A project-local credential file is particularly susceptible to accidental inclusion in source control or archives.

### Attack Path

1. A user copies a valid `overleaf_session2` cookie from the browser.
2. The user runs `olcli auth --cookie "<cookie>"` as documented.
3. The command, including the cookie, is retained in shell history or observed through process inspection, endpoint telemetry, terminal logging, backups, or command auditing.
4. Alternatively, a credential stored in `.olauth` is accidentally committed, archived, or made readable to another local account.
5.
...[truncated 891 chars]
Remediation
View remediation

Remediation Suggestions

  1. Replace command-line credential input with an interactive hidden prompt that does not echo or persist the cookie.
  2. Support credential delivery through protected standard input or an operating-system credential manager.
  3. Avoid printing, logging, or returning the cookie in error messages and diagnostic output.
  4. If file-based storage is necessary, create credential files with owner-only permissions, such as mode 0600, and reject files with unsafe ownership or permissions.
  5. Prefer a user-level configuration directory over a project-local .olauth file.
  6. Add .olauth and other credential-bearing configuration files to source-control exclusion guidance and provide an appropriate .gitignore entry.
  7. Warn users that the cookie is a bearer credential and must not be pasted into shared terminals, scripts, issue reports, logs, or chat messages.
  8. Document immediate session revocation and cookie rotation procedures for suspected exposure.
  9. Where supported, use a narrowly scoped, revocable API token instead of a full browser session cookie.

SkillSpector

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 (2)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill instructs users to extract and pass a live Overleaf session cookie directly on the command line without warning that this cookie is effectively an authenticated bearer token. Command-line arguments may be exposed via shell history, process listings, logs, or screenshots, which can enable account takeover if the cookie is captured.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
94% confidence
Finding

The documentation instructs users to manually extract a live authenticated session cookie and store it in environment variables or local files, but it does not warn that this cookie grants account access equivalent to a login session. That omission increases the chance the credential will be mishandled, leaked through shell history, dotfiles, backups, or shared directories, leading to unauthorized access to the user's Overleaf account and projects.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.