Is crossservicesolutions/change-pdf-permissions safe?
https://github.com/openclaw/skills/tree/main/skills/crossservicesolutions/change-pdf-permissions
The change-pdf-permissions skill performs its stated function — modifying PDF permission flags via the Cross-Service Solutions API — and exhibits no malicious behavior during installation: the clone is clean, canary files are intact, and no unauthorized network connections occurred. However, its core operation unconditionally transmits user PDF documents to a third-party external server with unknown data retention and privacy practices, and its broad 'files' tool permission combined with extension-only path validation creates a viable document exfiltration surface if an agent is manipulated into processing a sensitive file. The provider's 'xss' domain abbreviation is additionally notable for a skill positioned in the document-security category.
Category Scores
Findings (7)
HIGH User PDFs unconditionally uploaded to third-party external API -30 ▶
The skill's stated and actual purpose is to transmit user PDF documents to api.xss-cross-service-solutions.com. Any document processed leaves the user's environment entirely. The data retention policy, encryption practices, and legal jurisdiction of Cross-Service Solutions are not disclosed in the skill. For users processing confidential documents, this is a material privacy risk that is not surfaced prominently at install time.
MEDIUM Broad 'files' tool permission combined with extension-only validation -12 ▶
The SKILL.md declares 'files' as an allowed tool, granting the agent filesystem read/write access. The Python script's is_pdf_file() validates only the file extension (.pdf suffix), not path safety or file content. An agent with this skill active can be directed to upload any file with a .pdf extension — including files intentionally named to exploit this, e.g., secrets.pdf — to the external API endpoint.
MEDIUM Provider domain uses 'xss' abbreviation matching Cross-Site Scripting acronym -12 ▶
The provider abbreviates 'Cross-Service Solutions' as 'xss' resulting in the domain xss-cross-service-solutions.com. This is the same widely-recognized abbreviation for Cross-Site Scripting, a serious web vulnerability class. While possibly coincidental, using a security-negative acronym in a domain for a document-security skill warrants scrutiny — it may cause analyst confusion or represent deliberate obfuscation to complicate reputation lookups.
LOW File path validation uses extension-only check without path sanitization -18 ▶
The is_pdf_file() helper only checks whether the supplied path string ends with '.pdf'. There is no realpath normalization, no check against an allowed directory prefix, and no content-type validation of the opened file. If an agent is manipulated into passing an attacker-controlled path ending in .pdf, the file at that path will be opened and its binary content uploaded to the third-party API.
LOW Document exfiltration attack surface via legitimate skill invocation -38 ▶
A sophisticated attacker who can influence the task descriptions given to an agent with this skill active could instruct the agent to 'change permissions on /path/to/sensitive.pdf', causing it to upload the document to the external API. The skill provides no restrictions on which PDF files are acceptable targets, no allowlist of paths, and no confirmation step before upload. The skill is not itself malicious but creates a reliable exfiltration primitive when combined with social engineering or prompt injection via task inputs.
INFO Clean installation — no unexpected network connections or filesystem changes -5 ▶
The git clone connected only to GitHub (140.82.121.4:443), as expected. No connections to the skill's own API endpoints were observed during installation. The filesystem baseline diff shows exactly the expected skill files and no modifications outside the skill directory. Process execution log contains only standard git operations.
INFO Canary file reads attributable to monitoring framework, not skill -12 ▶
inotifywait and auditd logs record access to canary files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, gcloud credentials) at two points: 11:19:10 (before the git clone command at 11:19:15) and 11:19:34 (post-install). Both access windows align with Oathe's pre/post install canary baseline checks. The Python script was not executed during the audit, making skill-originated reads impossible. All canary files are reported intact.