wreckit

• Outcome: Review
• Latest audit: May 29, 2026, 9:22 PM
• Version:
  2.3.1

Overview

This is a legitimate code-verification skill, but it grants broad project execution and write authority with unsafe scoping, including sandbox-bypass guidance and automatic repository mutations.

Install only if you intend this skill to run project commands and write verification artifacts into repositories. Use it on trusted projects or inside a sandbox/container, review exact commands before execution, avoid the sandbox-bypass and full-environment guidance, do not expose broad API keys or secrets, and require explicit approval before commits, generated files, CI workflow creation, or dashboard use.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (28)

Context-Inappropriate Capability

Medium

• Confidence: 98% confidence
• Finding: The documentation recommends using a sandbox-bypass flag and inheriting all shell environment variables, which materially weakens isolation. In a skill that runs project code, tests, scanners, and auxiliary scripts, this can expose secrets from the environment and allow untrusted repository code or dependencies to run with fewer protections.

Context-Inappropriate Capability

Medium

• Confidence: 94% confidence
• Finding: The skill instructs users to store and use API credentials for CLI authentication even though the core stated purpose is local code verification. Encouraging credential storage in a tool that also executes shell commands and potentially untrusted project workflows raises the risk of accidental credential exposure or misuse.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The AUDIT-only template explicitly says 'no changes' but later instructs the orchestrator to write a proof bundle into the target project directory. That is a real integrity/safety issue because users may choose audit mode expecting read-only behavior, while the prompt causes filesystem modifications without clear disclosure or consent.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The collect-loop logic hard-codes an 11-worker set even though the document elsewhere says some workers are mode-conditional. In modes where design/CI/differential are skipped, an orchestrator following this literally can wait forever or incorrectly mark non-spawned workers as timed out, producing incomplete or misleading verification outcomes and potentially blocking or downgrading valid runs.

Intent-Code Divergence

Low

• Confidence: 88% confidence
• Finding: The failure-handling table says a worker times out at 5 minutes, while the collect-loop rules say to continue waiting until 10 minutes before marking `TIMED_OUT`. This inconsistency can cause different implementations to make different trust decisions, yielding premature failures or inconsistent proof bundles.

Context-Inappropriate Capability

Medium

• Confidence: 94% confidence
• Finding: In the fallback path, the script reads a test command from detected project metadata and executes it with `bash -c`. Because that command is derived from project-controlled content, a malicious or compromised project can cause arbitrary shell execution when the benchmark runner is invoked, which exceeds the narrow expectation of a perf-only helper and increases risk in automated agent workflows.

Intent-Code Divergence

High

• Confidence: 99% confidence
• Finding: The command is executed inside command substitution with `|| true`, so the substitution itself succeeds and `$?` captures the status of `true` rather than the gate command. This causes telemetry to record exit code 0 even when a verification gate fails, undermining the proof bundle and potentially allowing broken or unsafe code to be reported as passing.

Vague Triggers

Medium

• Confidence: 84% confidence
• Finding: The trigger phrases are very broad, covering common requests like 'audit this project,' 'fix this bug,' and 'build X with tests.' Because this skill can execute shell commands, write proof artifacts, and potentially perform expansive verification actions, broad invocation criteria increase the likelihood of accidental activation in situations where the user did not intend such behavior.

Missing User Warnings

Medium

• Confidence: 88% confidence
• Finding: The description advertises proof-bundle output and audit functionality without warning that the skill writes files, may start local services, and can run impactful verification steps. In the context of a code-verification skill, those side effects are significant because users may expect passive analysis rather than filesystem modifications or service execution.

Missing User Warnings

High

• Confidence: 97% confidence
• Finding: The Codex CLI notes normalize reduced sandbox protections and environment inheritance without a corresponding warning in the skill description. Given that this skill is designed to run many verification actions against local codebases, omitting a prominent warning makes the guidance especially dangerous because it can lead users to run untrusted code with access to secrets and the host environment.

Missing User Warnings

Medium

• Confidence: 99% confidence
• Finding: The dashboard builds HTML with template literals from untrusted fields such as repo, mode, gate names/details, and findings, then assigns the result to innerHTML. Because data is sourced from /api/status, localStorage, and inline JSON fallback, an attacker who can influence any of those sources can inject markup or script and achieve DOM XSS in the dashboard context.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The documentation explicitly states that, when no CI config is found, the script generates a starter `.github/workflows/wreckit-audit.yml` file, but it does not warn that this modifies the target repository. In an agent skill that may be run autonomously during audits or verification, silently creating project files can cause unintended repository changes, CI execution on future pushes, and user surprise or policy violations.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: These instructions direct writing a proof bundle into the project directory but do not warn the user that the skill will create or modify files. In a verification/audit context, silent writes can taint working trees, break CI expectations, or alter evidence in repositories that users expected to remain untouched.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The AUDIT-only template combines a 'no changes' assurance with an instruction to write a proof bundle to the audited path, which is contradictory and likely to mislead operators. In security-sensitive audits, this can contaminate the target repository, invalidate assumptions about non-invasive assessment, and cause unauthorized writes in environments where audit access was expected to be read-only.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The skill instructs the architect worker to write `IMPLEMENTATION_PLAN.md` into the project root without an explicit upfront warning or consent boundary. In an agent setting, silent file creation/modification can unexpectedly alter user repositories, trigger automations, or contaminate working trees during what may be perceived as a read-only planning step.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The implementer instructions explicitly perform `git add -A && git commit -m ...` with no explicit warning or confirmation. Automatic commits are a high-risk repository mutation because they permanently record changes, may include unintended files, can trigger hooks or CI, and can interfere with the user's workflow or audit trail.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The orchestrator directs many workers to run local scripts and project commands across the repository without a clear upfront warning that code will be executed. Running project-local or adjacent scripts in an agent context is dangerous because repositories and local script paths are untrusted inputs; execution can trigger arbitrary code, data exfiltration, destructive side effects, or environment compromise.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: This script executes a dynamically supplied test command via `eval` and writes captured output to disk automatically. Because `TEST_CMD` can come from a user argument or project-derived metadata (`detect-stack.sh` output), an attacker controlling the project or invocation can trigger arbitrary shell command execution; the silent snapshot writes also increase risk by persisting potentially sensitive command output without consent.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The script extracts a test command from project metadata and executes it via `bash -c`, which allows arbitrary shell commands embedded in repository-controlled config to run. In the context of a code-audit/verification skill that may be pointed at untrusted projects, this becomes dangerous because simply requesting coverage can trigger attacker-supplied command execution without notice or consent.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The script conditionally runs `npx --yes madge --circular --json .`, which invokes an external package runner and may fetch/execute code from the network if `madge` is not already available locally. In a security-analysis skill that claims no external tools are required, this undisclosed execution expands the trust boundary and can lead to unexpected third-party code execution, supply-chain risk, and nondeterministic behavior on the analyzed project.

Missing User Warnings

Medium

• Confidence: 98% confidence
• Finding: The script extracts a test command from project metadata and executes it via `bash -c`, which allows arbitrary shell syntax embedded in that command to run. In this skill context, the agent is intended to scan untrusted projects automatically, so running a discovered command without explicit warning, consent, or validation can execute attacker-controlled code during analysis.

Missing User Warnings

Medium

• Confidence: 98% confidence
• Finding: The script executes a user-supplied or auto-detected test command with eval, which allows shell metacharacters, command substitution, and chained commands to run with the script's privileges. In the skill context, this is more dangerous because the skill is designed to run against arbitrary projects, so untrusted repository content or caller input can influence the command and trigger arbitrary code execution.

Missing User Warnings

Medium

• Confidence: 84% confidence
• Finding: The script auto-creates a performance baseline file inside the project whenever none exists, without confirmation or a dry-run safeguard. In an agentic or CI setting, this can silently modify repository state and normalize unreviewed performance data, which may mask regressions or create unintended persistent changes.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The script executes the detected test command via `bash -c` without an explicit warning or consent boundary, so running a benchmark may unexpectedly launch arbitrary subprocesses defined by the project. In the context of an AI verification skill, this is more dangerous because users may expect analysis/benchmarking but not unrestricted project-controlled command execution.

Missing User Warnings

Medium

• Confidence: 86% confidence
• Finding: The script writes new files into the target project automatically without an explicit opt-in, confirmation, or dry-run mode. In an agent skill context, this is more dangerous because a caller expecting a read-only audit may unknowingly have their repository modified, which can pollute worktrees, affect CI, or be leveraged for persistence/confusion in automated workflows.

VirusTotal

64/64 vendors flagged this skill as clean.