Back to skill

Security audit

Reckit

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly a real code-verification toolkit, but it asks users to weaken sandbox protections and includes unsafe execution, mutation, and dashboard behaviors that need review before use.

Install only if you are comfortable running it in a disposable, sandboxed workspace. Do not follow the sandbox-bypass or inherit-all environment guidance; avoid using it on repositories with secrets or production data, review any generated .wreckit files before sharing, and do not run the dashboard on sensitive projects until the XSS and CORS issues are fixed.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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 (5)

T01 · Skill Instruction Hijacking

Error
Location
SKILL.md:184
Finding
Instructions Direct Agents to Disable Sandbox and Approval Protections<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:184-188` **Vulnerability Type**: Safety-control bypass through Skill instructions **Risk Level**: Critical ### Vulnerable Code ```markdown ## Codex CLI Notes (2026-02-22) When using Codex CLI to build/run projects: - `--full-auto` sandbox blocks `npm install` network access (ENOTFOUND registry.npmjs.org) - Fix: use `--dangerously-bypass-approvals-and-sandbox` flag instead - Auth: `echo "$OPENAI_API_KEY" | codex login --with-api-key` stores credentials to `~/.codex/auth.json` ``` ### Technical Analysis The Skill explicitly recommends `--dangerously-bypass-approvals-and-sandbox` as the solution when sandbox restrictions prevent network access. This changes the security boundary of the entire verification process rather than narrowly enabling a required operation. Reckit executes project-controlled build systems, package managers, test suites, compiler plugins, shell scripts, and dependency lifecycle hooks. Running those operations outside the sandbox and without approval checks gives untrusted repository code the same filesystem, process, network, and environment access as the user running the Agent. The adjacent authentication instruction also places Codex credentials in the normal user profile. Although the shown command does not itself transmit the key to an attacker, removing sandbox protections increases the chance that subsequently executed project code can access credentials and other user files. This exceeds the minimum privileges necessary for code verification. Dependency checking and test execution should instead occur in a disposable, restricted environment. ### Attack Path 1. An attacker supplies or contributes to a repository that will be audited. 2. The repository contains a malicious package lifecycle hook, compiler plugin, build script, test, or executable wrapper. 3. A dependency or build operation fails because the normal sandbox blocks network access. 4. The Agent follows ...[truncated 1034 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the recommendation to use `--dangerously-bypass-approvals-and-sandbox`. 2. Require explicit user authorization before enabling any network-dependent gate. 3. Run builds, tests, package managers, and mutation tools in disposable containers or isolated virtual machines. 4. Mount the audited repository read-only except for a dedicated temporary worktree. 5. Do not expose host credentials or unrelated environment variables to the verification environment. 6. Permit outbound access only to explicitly approved registries and only for dependency metadata when possible. 7. Disable package lifecycle scripts unless they are specifically required and reviewed. 8. Document that blocked network operations should result in a skipped or incomplete gate, not removal of safety controls. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
assets/dashboard/index.html:328
Finding
Stored DOM Cross-Site Scripting in the Local Dashboard<![CDATA[ ## Vulnerability Details **File Location**: `assets/dashboard/index.html:328-350, 366-390, 423` **Vulnerability Type**: Unescaped data inserted into `innerHTML` **Risk Level**: High ### Vulnerable Code ```javascript const DATA_PATH = '/api/status'; // served by dashboard server function renderGate(gate) { return ` <div class="gate"> <div class="gate-icon gate-${gate.status}">${GATE_ICONS[gate.status]}</div> <span class="gate-name">${gate.name}</span> <span class="gate-detail">${gate.detail || ''}</span> <span class="gate-time">${gate.duration || ''}</span> </div> `; } function renderFindings(findings) { if (!findings || !findings.length) return ''; return findings.map(f => ` <div class="finding"> <span class="finding-sev sev-${f.severity}">${f.severity}</span> <span>${f.message}</span> </div> `).join(''); } ``` ```javascript const iterDots = (run.iterations || []).map(i => `<div class="iter-dot ${i.status === 'fail' ? 'fail' : i.status === 'current' ? 'current' : ''}"></div>` ).join(''); return ` <div class="card" onclick="this.classList.toggle('expanded')"> <div class="card-header"> <div> <span class="card-title">${run.repo}</span> <span class="mode-tag">${run.mode}</span> <div class="card-meta">${run.language} · ${run.framework || 'no framework'} · ${run.branch || 'main'}</div> </div> <span class="badge badge-${badgeClass}">${(run.decision || 'running').toUpperCase()}</span> </div> <div class="gates"> ${run.gates.map(renderGate).join('')} </div> <div class="progress-bar"> <div class="progress-fill progress-fill-${progressClass}" style="width:${pct}%"></div> </div> <div class="card-footer"> <div class="iterations">${iterDots} <span>${run.iteration || 0}/${run.maxIterations || 50} iterations</span></div> <span class="click-hint">click for details</span> </div> <div class="findings" ...[truncated 2105 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace HTML-string rendering with DOM construction and assign all untrusted values through `textContent`. 2. If HTML templating must remain, apply context-sensitive escaping for text, attributes, class names, and style values. 3. Validate `/api/status` against a strict schema before rendering it. 4. Restrict status, mode, decision, and severity fields to enumerated values. 5. Reject unexpected keys and non-string values. 6. Remove inline event handlers such as `onclick` and register listeners through `addEventListener`. 7. Add a restrictive Content Security Policy, for example disallowing inline script and limiting connections to the local origin. 8. Treat every watched project and every `.wreckit/dashboard.json` file as untrusted input. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
assets/dashboard/server.mjs:83
Finding
Wildcard CORS Exposes Local Audit Results to Arbitrary Websites<![CDATA[ ## Vulnerability Details **File Location**: `assets/dashboard/server.mjs:83-94, 108-114` **Vulnerability Type**: Cross-origin disclosure from a loopback service **Risk Level**: Medium ### Vulnerable Code ```javascript const server = createServer(async (req, res) => { const url = new URL(req.url, `http://localhost:${PORT}`); // CORS res.setHeader('Access-Control-Allow-Origin', '*'); if (url.pathname === '/api/status') { const status = await getStatus(); res.writeHead(200, { 'Content-Type': 'application/json' }); res.end(JSON.stringify(status)); return; } ``` ```javascript server.listen(PORT, '127.0.0.1', () => { console.log(`🔨 wreckit dashboard → http://localhost:${PORT}`); console.log(` API endpoint → http://localhost:${PORT}/api/status`); if (watchDir) console.log(` Watching: ${resolve(watchDir)}`); else if (projectsArg) console.log(` Projects: ${projectsArg}`); else console.log(` Auto-scanning: ~/Projects/*/. wreckit/`); }); ``` ### Technical Analysis Binding the service to `127.0.0.1` prevents direct access from other network hosts, but it does not prevent websites loaded in the user's browser from making requests to loopback addresses. `Access-Control-Allow-Origin: *` explicitly permits JavaScript from any web origin to read `/api/status`. The endpoint has no authentication, origin allowlist, anti-DNS-rebinding control, or session-specific token. The server returns parsed dashboard objects without projecting them onto a minimal response schema. Consequently, any additional fields present in a dashboard file may also be returned. ### Attack Path 1. The user starts the Reckit dashboard on its default loopback port. 2. The user visits an attacker-controlled website. 3. JavaScript on that website sends a request to `http://127.0.0.1:3939/api/status`. 4. The local server returns `Access-Control-Allow-Origin: *`. 5. The browser permits the attacker page to read the JSON response. 6. The page transmi ...[truncated 561 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove `Access-Control-Allow-Origin: *`. 2. For normal dashboard operation, use same-origin requests and omit CORS headers entirely. 3. Reject requests containing an unapproved `Origin` header. 4. Generate a cryptographically random startup token and require it for API access. 5. Validate the `Host` header against the expected loopback host and port to reduce DNS-rebinding exposure. 6. Return only a strict allowlisted response schema rather than arbitrary parsed fields. 7. Add security headers such as `Content-Security-Policy`, `X-Content-Type-Options: nosniff`, and `Cache-Control: no-store`. 8. Consider selecting a random available loopback port for each run. ]]>

T08 · Insecure Dependencies

Error
Location
scripts/design-review.sh:91
Finding
Audit Gate Automatically Downloads and Executes an Unpinned Package<![CDATA[ ## Vulnerability Details **File Location**: `scripts/design-review.sh:91-102` **Vulnerability Type**: Unpinned supply-chain execution through `npx --yes` **Risk Level**: High ### Vulnerable Code ```bash # ─── JS/TS: try madge first ──────────────────────────────────────────────────── MADGE_OUTPUT="" USED_MADGE=false if [ "$LANGUAGE" = "ts" ] && command -v npx >/dev/null 2>&1; then echo "Attempting madge analysis..." >&2 if MADGE_OUTPUT=$(npx --yes madge --circular --json . 2>/dev/null); then USED_MADGE=true echo "madge succeeded" >&2 else echo "madge failed or not available, using manual scan" >&2 fi fi ``` ### Technical Analysis `npx --yes madge` can download and execute a package when it is not already installed locally. The invocation: - Does not pin an exact package version. - Does not require the package to be present in the audited project's lockfile. - Automatically accepts installation without user confirmation. - Executes package code with the current user's permissions. - Runs from inside the audited project directory. The script already implements a manual dependency-graph fallback, so remote package retrieval is not necessary for the declared design-review operation. The effective code executed by this audit gate can change after Skill review because the registry can return a later release. A compromised publisher account, package takeover, registry compromise, or malicious future release would therefore create a code-execution path. ### Attack Path 1. A TypeScript project is audited. 2. `design-review.sh` detects that `npx` is installed. 3. The expected `madge` package is not installed locally. 4. `npx --yes madge` retrieves the current package and dependencies from the configured registry. 5. A compromised or malicious release executes during package startup or dependency loading. 6. The package accesses the audited repository, environment variables, user files, or network using the audit process's privileges ...[truncated 573 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace `npx --yes` with `npx --no-install` so only an already installed dependency can execute. 2. Pin the tool to an exact reviewed version in the Skill's own lockfile. 3. Verify package integrity using the package-manager lockfile and integrity hashes. 4. Do not automatically install tooling during an audit. 5. Ask for explicit user approval before any package download. 6. Prefer the existing manual scanner when the reviewed local dependency is unavailable. 7. Run third-party analysis tools in a disposable container with no host credentials and restricted outbound network access. 8. Record the exact tool version and integrity information in the proof bundle. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
scripts/mutation-test.sh:281
Finding
Mutation Testing Overwrites Source Files Using Predictable Temporary Paths Without Reliable Cleanup<![CDATA[ ## Vulnerability Details **File Location**: `scripts/mutation-test.sh:281-328` **Vulnerability Type**: Unsafe temporary-file handling and non-transactional source modification **Risk Level**: High ### Vulnerable Code ```bash # Use temp files for counters (avoids subshell issues) RESULTS_FILE=$(mktemp) KILLED=0 SURVIVED=0 TOTAL=0 MAX_MUTATIONS=20 ``` ```bash for file in $SRC_FILES; do [ "$TOTAL" -ge "$MAX_MUTATIONS" ] && break LINE_COUNT=$(wc -l < "$file" | tr -d ' ') [ "$LINE_COUNT" -lt 5 ] && continue CANDIDATES=$(grep -nE '(===|!==|>=|<=|&&|\|\|| true| false|return )' "$file" 2>/dev/null | head -5 || true) [ -z "$CANDIDATES" ] && continue cp "$file" "/tmp/wreckit-backup-$$" while IFS= read -r candidate; do [ "$TOTAL" -ge "$MAX_MUTATIONS" ] && break LINENUM=$(echo "$candidate" | cut -d: -f1) ORIGINAL=$(sed -n "${LINENUM}p" "$file") MUTATED=$(mutate_line "$ORIGINAL") [ "$ORIGINAL" = "$MUTATED" ] && continue # Apply mutation via awk awk -v ln="$LINENUM" -v rep="$MUTATED" 'NR==ln{print rep;next}{print}' "$file" > "/tmp/wreckit-mutated-$$" cp "/tmp/wreckit-mutated-$$" "$file" TOTAL=$((TOTAL + 1)) if eval "$TEST_CMD" >/dev/null 2>&1; then SURVIVED=$((SURVIVED + 1)) echo " SURVIVED: ${file}:${LINENUM}" >> "$RESULTS_FILE" else KILLED=$((KILLED + 1)) echo " KILLED: ${file}:${LINENUM}" >> "$RESULTS_FILE" fi cp "/tmp/wreckit-backup-$$" "$file" done <<< "$CANDIDATES" cp "/tmp/wreckit-backup-$$" "$file" rm -f "/tmp/wreckit-backup-$$" "/tmp/wreckit-mutated-$$" done ``` ### Technical Analysis The fallback mutation engine modifies audited source files in place. It attempts to restore each file afterward, but it does not install an `EXIT`, `INT`, `TERM`, or `HUP` trap. A crash, timeout, failed command under `set -e`, forced termination, or machine interruption after the mutation is copied into place can leave the repository in a modified state. The backup ...[truncated 2087 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Never mutate the user's working tree directly. 2. Create a disposable Git worktree, filesystem copy, container layer, or sandbox snapshot for mutation testing. 3. Create a private temporary directory with `mktemp -d`, verify creation succeeded, and restrict it to mode `0700`. 4. Install cleanup and restoration handlers using `trap` for `EXIT`, `INT`, `TERM`, and `HUP`. 5. Restore files atomically and verify their hashes against pre-mutation hashes before returning. 6. Replace whitespace-delimited file lists with null-delimited processing using `find -print0` and `while IFS= read -r -d ''`. 7. Avoid `eval`; represent approved test commands as executable-and-argument arrays. 8. In AUDIT mode, require a clean working tree or perform all mutation operations outside the original project directory. 9. After mutation testing, verify that `git diff --exit-code` shows no changes and report a hard error if restoration was incomplete. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (112)

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The description presents a broad, fully featured code verification engine with parallel workers and multiple advanced verification stages. The supplied code chunk is only a behavior-capture helper script. It detects the language/test command, runs tests if available, stores test output, extracts rough signatures and API/CLI indicators with ripgrep, and writes results under .wreckit/behavior-snapshots. That is related to software verification workflows, but it is not the declared primary capability and lacks the major advertised functions such as parallel verification, mutation testing, type checking, cross-verification, or shipping verdict generation. Therefore the description materially overstates and misrepresents what this specific code chunk actually does.

Tp4

High
Category
MCP Tool Poisoning
Confidence
96% confidence
Finding
The declared description presents a broad, self-contained code verification system for validating generated or modified code, with capabilities like mutation testing, type checking, parallel verification workers, and proof-bundle generation. The supplied code chunk is much narrower: it checks declared dependencies against npm, PyPI, crates.io, and partially inspects Swift/CocoaPods dependencies using external commands and HTTP requests. Its Swift support is limited to a small hardcoded advisory list and outdated dependency reporting, not general Swift code verification. While dependency auditing could be a supporting part of a larger verification tool, this chunk’s actual behavior is materially different from the declared primary purpose and explicitly contradicts the 'no external tools required' claim.

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The declared description presents a comprehensive code verification engine that directly verifies code quality and correctness, including mutation testing, type checking, parallel worker orchestration, and proof-bundle generation. The supplied code instead only inspects repository CI configuration files, assigns a heuristic score, and optionally creates a starter GitHub Actions workflow. While CI support could be a supporting feature of a larger verification tool, this specific code chunk's primary behavior is CI integration assessment/generation, not code verification. That is a material difference in purpose and capability, so this should be flagged as a mismatch.

Tp4

High
Category
MCP Tool Poisoning
Confidence
96% confidence
Finding
The declared description promises a broad, end-to-end code verification engine with multiple verification stages and proof-bundle output. The supplied code chunk is much narrower: it is a helper script for collecting coverage/test-runner output. While coverage collection can be a supporting part of a verification system, this chunk by itself does not match the declared primary purpose and lacks the headline capabilities described. There is no evidence of parallel workers, mutation testing, type analysis, proof bundle generation, or final verification verdicts. Therefore the description materially overstates what this code chunk actually does.

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The declared description promises a broad, self-contained verification engine with extensive testing/analysis capabilities and proof-bundle output. This code chunk only implements a small scaffold script for cross-verification in BUILD mode. Its behavior is limited to preparing a temporary workspace with tests/spec docs, printing an AI regeneration prompt, and optionally comparing two files using line counts and JavaScript/TypeScript export-symbol matching. That is materially narrower than the declared purpose and omits most of the advertised verification functionality. While the script is related to 'cross-verify,' the overall description substantially overstates what this code actually does.

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The description claims a broad, self-contained code verification system that performs multiple verification gates (including type-checking, mutation testing, cross-verification, regression proof, and proof-bundle output) across many scenarios. The supplied code chunk does not do those things. It is a single shell script focused specifically on architectural/dependency analysis: language detection, import scanning, circular dependency detection, fan-in analysis for god modules, orphan file heuristics, and monorepo/library calibration. While this could be one supporting gate within a larger verification suite, the chunk itself materially underdelivers relative to the declared purpose and lacks several central claimed capabilities. Therefore the description does not accurately represent what this code chunk actually does.

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The declared description promises a comprehensive verification engine that actively validates code quality and correctness using multiple verification techniques and emits a proof bundle. The supplied code chunk does something much narrower: it heuristically identifies the project's tech stack and suggests build/type-check/test commands in JSON. While this may be a supporting component of a larger verification system, by itself it does not implement the primary described behavior. Therefore the description materially overstates the functionality present in this code chunk.

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The description promises a full 'bulletproof' verification engine with multiple verification modes, including parallel workers, type-checking, mutation testing, and proof-bundle generation. The supplied code chunk instead implements one specific scanner for differential/metamorphic testing heuristics. It runs an existing test suite if detected and searches the filesystem for oracles, snapshots, reference implementations, and common code patterns, then outputs JSON. That behavior is related to verification, so the domain is adjacent, but the primary purpose and scope are materially narrower than declared. Key advertised capabilities are absent from this code chunk, making the description inaccurate for the supplied code.

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The declared description presents a broad, self-contained verification engine with parallel workers, mutation testing, type checking, cross-verification, and proof-bundle production. The supplied code chunk is much narrower: it is a single shell script for dynamic analysis that detects language, invokes external tooling like go/cargo/python3/grep, performs a few runtime or static heuristic checks, and outputs a JSON report. While this script could plausibly be one component of a larger verification suite, taken as supplied it does not substantiate several central declared capabilities, and it contradicts the claim that the agent is the engine with no external tools required.

Tp4

High
Category
MCP Tool Poisoning
Confidence
94% confidence
Finding
The declared description presents a general-purpose, self-contained verification engine with multiple coordinated audit capabilities across many ecosystems. The supplied code chunk is much narrower: it is a single shell script for Stryker-based mutation testing in JavaScript/TypeScript projects. It requires external tooling (`npx`, Stryker, Node ecosystem setup), does not spawn workers, does not type-check or cross-verify, does not demonstrate language/framework agnosticism, and does not create the described `.wreckit/` proof bundle. While mutation testing and a verdict are aligned with part of the description, the actual code only implements one small subset of the advertised functionality, making the description materially misleading for this chunk.

Tp4

High
Category
MCP Tool Poisoning
Confidence
90% confidence
Finding
The description presents a broad, self-contained verification system with multiple coordinated verification stages and artifact generation. The supplied code chunk is much narrower: it is a mutation-testing script. While mutation testing and verdict output align with part of the claim, the code does not show the advertised parallel worker orchestration, type-checking, slop-scanning, cross-verification, or proof bundle creation. Swift support is present, but only as a heuristic estimated mutation analysis rather than full verification. This is a material description/behavior mismatch because the declared primary purpose is substantially broader than the actual implemented behavior in the provided code chunk.

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The declared description promises a broad code verification engine focused on correctness and quality gates such as type-checking, mutation testing, cross-verification, and proof-bundle generation across many development workflows. The supplied code chunk does not implement those general verification capabilities. Instead, it is a narrowly scoped performance benchmark runner. Its primary function is to detect benchmarking setups, execute benchmarks, compare current timing results to a saved baseline, flag regressions, and write/report baseline data. While performance benchmarking could be considered adjacent to verification and it does use the .wreckit directory plus a verdict concept, this code materially differs from the declared primary purpose and adds a specific undeclared capability: benchmark/baseline performance regression analysis.

Tp4

High
Category
MCP Tool Poisoning
Confidence
99% confidence
Finding
The declared description promises a comprehensive code verification/auditing engine with testing and proof-bundle generation. The provided code instead implements a project classifier: it reads package.json, checks for app/library/monorepo indicators, examines git shallow status, commit count, project age, and test-file presence, computes heuristic scores, and emits a JSON classification plus calibration profile. While the calibration output may support a larger verification system, this code chunk itself does not carry out the declared verification tasks and has a materially different primary purpose.

Tp4

High
Category
MCP Tool Poisoning
Confidence
95% confidence
Finding
The description presents the skill as a full verification engine that actively runs multiple code-quality and testing checks in parallel, language/framework agnostic, and suitable for building, migrating, fixing, and auditing code. The supplied code chunk does not execute any such checks. It only consumes an input JSON array of gate results, computes a verdict using scoring/heuristics, reads optional local metadata (.wreckit/project-type.json or env-specified profile file, plus git rev-parse), and writes a proof bundle. Producing a proof bundle and verdict is consistent with part of the description, but the primary claimed capability—actually performing verification—is absent in this code. Therefore the description materially overstates what this code chunk does.

Tp4

High
Category
MCP Tool Poisoning
Confidence
96% confidence
Finding
The description claims a broad, bulletproof verification engine with multiple verification modes and parallel workers, covering tasks like type checking, mutation testing, regression-proof verification, and full proof-bundle generation. The supplied code chunk does something much narrower: it scans for property-based testing frameworks in Python/JS/TS/Rust/Go, counts and optionally runs property/fuzz tests, generates template stubs if none exist, and emits a JSON summary. While this behavior is loosely related to code verification, it is only one small component of the declared system and lacks most of the headline capabilities. That makes the description materially overstated relative to this code chunk.

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding
The declared description presents a full-featured verification system for codebases, including testing, mutation analysis, cross-verification, and proof-bundle output. The supplied code does none of that. It only inspects IMPLEMENTATION_PLAN.md for existence, task formatting, completion markers, empty descriptions, and use of the word 'and', then outputs a small JSON summary. This is a materially different and much narrower purpose than the declared skill behavior, so the description does not accurately represent the code chunk.

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The declared description presents a broad, verification-focused system for building, rewriting, fixing, and auditing code with strong correctness guarantees, including parallel workers, type checking, mutation testing, cross-verification, and proof-bundle output. The supplied code chunk does not implement those capabilities. Instead, it is a focused adversarial security scanner implemented as a shell script that uses grep/regex heuristics and small git checks to find security issues and outputs structured JSON. While security/code audit is adjacent to the declared auditing theme and the PASS/WARN/FAIL verdict is somewhat similar to a gate result, the primary purpose and implemented capabilities are materially narrower and different from the description. Therefore this is a description-behavior mismatch.

Tp4

High
Category
MCP Tool Poisoning
Confidence
94% confidence
Finding
The description presents a large, self-contained verification system with multiple verification modes and no need for external tools. The supplied code chunk instead implements one specific analyzer: regex complexity/ReDoS detection over project files, with JSON reporting and exit status. It optionally uses an external binary (`recheck`), which directly conflicts with the 'no external tools required' claim. While this script could plausibly be one component of a larger verification suite, taken on its own it does not match the declared primary purpose or capabilities such as spawning parallel workers, type-checking, mutation testing, broad code verification, or producing a `.wreckit/` proof bundle.

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The supplied code chunk implements only a narrow regression-testing helper: it runs tests, normalizes results from several runners, saves a baseline, and compares current results to identify regressions/newly passing tests. That is consistent with one small part of a verification pipeline, but it does not itself perform or orchestrate the broad capabilities promised in the description, such as parallel worker spawning, mutation testing, type checking, slop scanning, or comprehensive proof-bundle generation with overall Ship/Caution/Blocked verdicts. The primary purpose of this code is materially narrower than the declared skill description, so the description does not accurately represent what this code chunk actually does.

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The description presents a broad end-to-end verification system, but the provided code chunk implements just one limited component: a heuristic static scan for code-quality 'slop' patterns. While 'slop-scan' is mentioned in the description, the chunk does not demonstrate the larger claimed capabilities such as orchestrating workers, language/toolchain verification, mutation testing, or producing the advertised proof bundle and final shipping verdict. This is therefore a material description-versus-behavior mismatch, with the code representing only a small subset of the declared functionality.

Tp4

High
Category
MCP Tool Poisoning
Confidence
96% confidence
Finding
The supplied code chunk is narrowly focused on type checking. It detects the stack, chooses a type-check command, includes Swift/iOS-specific handling, executes the checker/build, parses errors and warnings, and outputs JSON. This aligns with only one small part of the declared description: type checking and Swift support. The broader declared purpose describes a full verification system with multiple verification modes, parallel workers, mutation testing, cross-verification, proof bundle generation, and shipping verdicts. None of those broader capabilities appear in this code chunk. Therefore the description materially overstates what this code actually does.

Ae1

High
Category
analysis-evasion
Content
- `scripts/differential-test.sh [path]` — oracle comparison, golden tests (BUILD/REBUILD) → JSON
Confidence
100% confidence
Finding
Referenced artifact was not completely inspected

Ae1

High
Category
analysis-evasion
Content
- `scripts/differential-test.sh [path]` — oracle comparison, golden tests (BUILD/REBUILD) → JSON
Confidence
100% confidence
Finding
Referenced artifact was not completely inspected

Agent Config Directory Access

High
Category
Agent Snooping
Content
- `--full-auto` sandbox blocks `npm install` network access (ENOTFOUND registry.npmjs.org)
- Fix: use `--dangerously-bypass-approvals-and-sandbox` flag instead
- Auth: `echo "$OPENAI_API_KEY" | codex login --with-api-key` stores credentials to `~/.codex/auth.json`
- Config: `~/.codex/config.toml` with `model = "gpt-5.2-codex"` and `[shell_environment_policy] inherit = "all"`
- `gpt-5.3-codex` is Copilot/VS Code only — not available via direct API. Use `gpt-5.2-codex`.
Confidence
97% confidence
Finding
The skill explicitly instructs use of `~/.codex/config.toml` with `[shell_environment_policy] inherit = "all"`, which encourages broad inheritance of host environment variables by subprocesses. In a security-sensitive agent skill that runs shell commands and spawns workers, this can expose secrets, tokens, cloud credentials, and other sensitive environment state to child processes and logs.

Context Leakage

High
Category
Data Exfiltration
Content
## Process

**Before touching anything:**
1. Record all inputs → outputs from existing codebase (API calls, function returns, CLI outputs)
2. Save as golden fixtures in `.wreckit/golden/`

**After rebuilding:**
Confidence
94% confidence
Finding
The instruction to record 'all inputs → outputs' from the existing codebase, including API calls, function returns, and CLI outputs, can capture secrets, personal data, auth tokens, and other sensitive runtime context into `.wreckit/golden/`. Because this skill is designed to automate verification and rebuild workflows, users may apply it broadly to production-like systems, making uncontrolled behavior capture especially likely to exfiltrate or persist sensitive data.

Static analysis

Detected: suspicious.dynamic_code_execution

Dynamic code execution detected.

Critical
Code
suspicious.dynamic_code_execution
Location
scripts/red-team.sh:89