Remove password from PDF
ReviewAudited by ClawScan on May 1, 2026.
Overview
The skill appears to do what it advertises, but it sends your PDF, its password, and an API key to a third-party API, so only use it for files you are comfortable uploading.
Before installing or using this skill, confirm you trust Cross-Service-Solutions with the PDF contents and password, verify the API endpoint, use a revocable API key, and avoid using it for highly sensitive documents unless third-party upload is acceptable.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
The third-party service receives the protected PDF and the password needed to open it, and the result is returned as a download URL.
The script sends the PDF file and current PDF password, with an authorization header, to an external provider API. This is disclosed and purpose-aligned, but it is a sensitive data boundary users should notice.
DEFAULT_BASE_URL = "https://api.xss-cross-service-solutions.com/solutions/solutions" ... requests.post(url, headers=headers, files=files, data=data, timeout=timeout_s)
Use only with documents you are comfortable uploading to this provider, verify the provider and endpoint, and treat the returned download URL as sensitive.
If mishandled, the API key could be used to access the user's Solutions API account or quota.
The skill requires a bearer API key for the external service. This is expected for the integration and the artifact tells the agent not to echo or log it, but it is still a sensitive credential.
The API requires an API key used as a Bearer token: - `Authorization: Bearer <API_KEY>` ... **Rule:** never echo or log the API key.
Use a revocable, least-privilege API key if available, avoid pasting it into shared chats or logs, and rotate it if exposed.
Dependency installation could vary over time if the user installs from requirements.txt.
The dependency is declared with a lower bound rather than an exact pinned version or lockfile. This is common and not suspicious by itself, but future installs may resolve to different package versions.
requests>=2.32.0
Prefer a pinned dependency or lockfile for reproducible installs, especially in sensitive document-handling workflows.