Back to skill

Security audit

Pywayne Bin Gettool

Security checks for vulnerabilities and agentic risk

Overview

This skill is meant to fetch and install C++ libraries, but it documents building and sudo-installing code from configurable repositories without clear safety gates.

Install only if you are comfortable with an agent fetching C++ source code and potentially running build or install commands. Avoid --global-install-flag unless you have manually verified the repository and installation scripts, prefer pinned trusted sources, and run builds in a contained non-privileged environment.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Findings (1)

T03 · Remote Payload Retrieval and Execution

Error
Location
SKILL.md:79
Finding
Mutable Remote Repository Content Can Be Executed with Elevated Privileges<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 79–104 **Vulnerability Type**: Remote payload retrieval and execution through a configurable repository **Risk Level**: High ### Vulnerable Code ```bash After fetching, execute the tool's installation script (if configured): ```bash gettool pcl -i gettool pcl -i --global-install-flag true # Use sudo make install ``` ### 7. Fetch Specific Version Check out a specific version/tag/branch (only works for tools that are submodules): ```bash gettool fmt -v 9.1.0 ``` ### 8. Manage Repository URL ```bash # Show current URL gettool --get-url # Set custom URL gettool --set-url <URL> # Reset to default URL gettool --reset-url ``` ``` ### Technical Analysis The documented workflow allows the source repository to be changed to a user-supplied URL and then permits fetched content to be built or installed. The installation mode executes a tool-specific installation script, while `--global-install-flag true` enables `sudo make install`. No controls are documented for: - Restricting repositories to trusted hosts or an approved allowlist. - Pinning downloads to immutable commit hashes. - Verifying cryptographic signatures or expected checksums. - Reviewing fetched build and installation scripts before execution. - Isolating builds in a sandbox. - Preventing downloaded installation logic from executing with root privileges. Consequently, the effective executable payload can change after this Skill has been reviewed. An attacker-controlled or compromised repository could provide malicious `CMakeLists.txt`, Makefiles, source-level build hooks, or installation scripts. Invoking the documented build or installation operations would then execute those instructions locally. Although version selection is supported, tags and branches are mutable references unless resolved and verified against an immutable commit. Version selection alone therefore does not establish source integrity. ### Attack Path ...[truncated 1508 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. **Restrict remote sources** - Permit only explicitly approved HTTPS repository hosts and paths. - Reject local paths, insecure protocols, unexpected redirects, and arbitrary repository URLs. - Require a separate, explicit administrative action to modify the trusted repository configuration. 2. **Pin and verify fetched content** - Resolve every dependency to an immutable commit hash. - Maintain expected hashes or signed manifests for approved tools. - Verify Git commit or tag signatures against trusted keys before building. - Treat branches and unsigned tags as untrusted mutable references. 3. **Remove automatic privileged installation** - Do not invoke `sudo` from downloaded build or installation logic. - Stage installation artifacts in an unprivileged temporary destination. - Display the resulting file manifest and require explicit user approval before a separate trusted component performs system-wide installation. 4. **Sandbox build and installation steps** - Run downloaded build logic in an isolated container or restricted worker. - Use an unprivileged account with a read-only host filesystem. - Disable unnecessary network access during builds. - Do not expose SSH keys, API tokens, package-manager credentials, or unrelated source directories. 5. **Validate installation behavior** - Require installation scripts and build files to pass manual or automated review before execution. - Enforce destination-path restrictions and reject writes outside the approved staging directory. - Record the source URL, immutable revision, verification result, executed commands, and installed files in an audit log. 6. **Add explicit safety prompts** - Warn that build systems and installation scripts are executable code. - Require confirmation that identifies the exact trusted repository and immutable revision. - Require additional confirmation before any system-wide operation. ] ...[truncated 2 chars]
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (4)

Vague Triggers

Medium
Confidence
95% confidence
Finding
The skill description is broad enough to trigger on common words like fetch, get, download, clone, or install for many C++-related requests. That can cause the agent to invoke a skill that performs network retrieval, building, or installation when the user may have intended a safer informational response, increasing the chance of unintended code acquisition and execution.

Missing User Warnings

Medium
Confidence
97% confidence
Finding
The skill explicitly supports building from source and running installation scripts, but it does not prominently warn that these actions can execute untrusted third-party code and modify the local system. In a tool-fetching skill, that omission is dangerous because users or higher-level agents may treat build/install as routine file operations rather than code execution with side effects.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
```bash
gettool pcl -i
gettool pcl -i --global-install-flag true  # Use sudo make install
```

### 7. Fetch Specific Version
Confidence
97% confidence
Finding
The documented `--global-install-flag true` path indicates support for `sudo make install`, which elevates execution of third-party build/install logic to root privileges. Because this skill fetches external code and may run repository-provided installation scripts, combining remote content with privileged execution creates a strong path to full system compromise if the source or script is malicious or tampered with.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
| `-c` / `--clean` | Copy only src/include directories |
| `-v <version>` | Checkout specific version (submodules only) |
| `-i` / `--install` | Run installation script (if installable) |
| `--global-install-flag` | Set to `true` for sudo make install |
| `-l` / `--list` | List all supported tools |
| `--get-url` | Show current repository URL |
| `--set-url <URL>` | Set repository URL |
Confidence
96% confidence
Finding
The command reference advertises a flag specifically for `sudo make install`, normalizing root-level installation as a standard feature. In the context of fetching and installing third-party tools, this increases the likelihood that an agent or user will perform privileged execution on unreviewed code, amplifying any compromise from user-level impact to full host takeover.

Static analysis

No suspicious patterns detected.