Back to skill

Security audit

Paperless

Security checks for vulnerabilities and agentic risk

Overview

The skill is purpose-aligned for managing Paperless-NGX documents, but its setup encourages sensitive token use over plaintext HTTP and an unpinned global CLI install.

Review before installing. Use HTTPS for any non-local Paperless server, create a least-privilege/revocable API token, avoid exposing the token in shell history or shared config, and consider installing a pinned ppls version in an isolated project or container instead of globally.

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:5
Finding
Unpinned Third-Party CLI Installed Globally## Vulnerability Details **File Location**: `SKILL.md`, lines 5–15 **Vulnerability Type**: Supply-chain exposure through an unpinned globally installed npm dependency **Risk Level**: Medium ```yaml metadata: {"clawdbot":{"requires":{"bins":["ppls"],"env":["PPLS_HOSTNAME","PPLS_TOKEN"]},"install":[{"id":"node","kind":"node","package":"@nickchristensen/ppls","bins":["ppls"],"label":"Install ppls CLI (npm/bun)"}]}} --- # Paperless-NGX CLI Search and manage documents in Paperless-NGX using `ppls`. ## Setup ```bash npm install -g @nickchristensen/ppls ``` ### Technical Analysis The Skill requires installation and execution of `@nickchristensen/ppls` without pinning an audited version or specifying an integrity hash. The use of `npm install -g` installs the package globally and may execute npm lifecycle scripts with the privileges of the installing user. Because the package version is not constrained, the code executed by future installations can differ from the version originally reviewed. A compromised maintainer account, malicious package release, or upstream dependency compromise could introduce arbitrary code. The installed CLI subsequently operates in an environment that contains `PPLS_HOSTNAME` and `PPLS_TOKEN`, giving compromised code an opportunity to access Paperless credentials and document data. No evidence in the reviewed project establishes that the current package is malicious. The vulnerability is the absence of dependency pinning, integrity verification, and isolation around a security-sensitive third-party executable. ### Attack Path 1. An attacker compromises the npm package, a maintainer account, or a transitive dependency and publishes a malicious release. 2. A user or automated Agent follows the Skill instructions and runs `npm install -g @nickchristensen/ppls`. 3. npm resolves the unconstrained package to the attacker-controlled release. 4. Malicious package code executes during installation t ...[truncated 928 chars]
Remediation
## Remediation Suggestions - Pin the dependency to an exact version that has undergone security review, rather than allowing npm to select the latest release. - Lock and verify the complete transitive dependency graph using an appropriate lockfile. - Verify package provenance and integrity using registry signatures, trusted publishing attestations, and cryptographic integrity hashes where supported. - Avoid global installation. Run the CLI from a project-local, locked dependency or an isolated container with narrowly scoped filesystem and network access. - Disable npm lifecycle scripts during installation when they are not required, and review any scripts before allowing them. - Review or vendor the exact CLI source corresponding to the pinned release. - Provide the CLI with a least-privilege Paperless token and expose credentials only for the duration of the command. - Add automated dependency monitoring and require review before upgrading the pinned package.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:14
Finding
API Token Configuration Demonstrated with a Plaintext HTTP Endpoint## Vulnerability Details **File Location**: `SKILL.md`, lines 14–17 **Vulnerability Type**: Plaintext transmission of sensitive authentication material **Risk Level**: High ```bash npm install -g @nickchristensen/ppls ppls config set hostname http://your-paperless-host ppls config set token your-api-token ``` ### Technical Analysis The setup instructions configure the Paperless hostname with an `http://` URL while separately configuring an API token. If this example is followed for a non-loopback service, subsequent authenticated requests may traverse the network without TLS confidentiality or server authentication. An on-path attacker could observe HTTP headers and request content, potentially capturing the API token and sensitive document information. The attacker could also modify requests or responses in transit. The risk applies when plaintext HTTP is used over an untrusted or shared network; the documentation does not restrict the example to a loopback-only development environment. ### Attack Path 1. A user follows the documented setup and configures a remote Paperless endpoint using `http://`. 2. The user invokes `ppls` to search, view, download, upload, or update documents. 3. The CLI sends authenticated HTTP requests across a network controlled or observable by an attacker, such as public Wi-Fi, a compromised local network, or a malicious intermediary. 4. The attacker captures the API token or session-bearing request data and may inspect document metadata or OCR content. 5. The attacker replays the captured token against the Paperless API. 6. The attacker performs any operation authorized by that token, including retrieving documents or changing document data. ### Impact Assessment Exploitation can expose the Paperless API token, document metadata, OCR content, and downloaded or uploaded document data. A captured token permits unauthorized API access within its assigned scope. Depending on the token's perm ...[truncated 239 chars]
Remediation
## Remediation Suggestions - Replace the example endpoint with an HTTPS URL: ```bash ppls config set hostname https://your-paperless-host ``` - Explicitly require TLS for all non-loopback Paperless connections. - Permit plaintext HTTP only for clearly documented, loopback-only development scenarios such as `http://127.0.0.1`. - Validate server certificates and hostnames; do not recommend disabling TLS verification. - Configure HTTP-to-HTTPS redirects at the server, while ensuring credentials are never sent in an initial plaintext request. - Use short-lived or revocable, least-privilege API tokens and rotate any token that may have been transmitted over plaintext HTTP. - Store the token using a protected credential mechanism and prevent it from appearing in logs, shell history, or diagnostic output.
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

Low
Confidence
81% confidence
Finding
The setup section tells users to set a Paperless API token, but does not warn that this is a sensitive credential or advise safe handling. For markdown skills, omission of warnings about privacy-sensitive behavior and credentials can leave users unaware of the risk.

Missing User Warnings

Low
Confidence
84% confidence
Finding
This markdown file includes commands that save documents to paths like ~/Downloads, which affects local user data. The section provides no explicit warning or disclosure that files will be written to disk or may overwrite user-managed locations.

Static analysis

No suspicious patterns detected.