Nexus Safe

• Outcome: Review
• Latest audit: Sep 10, 2026 · 11:10 PM UTC
• Version: 0.1.6

Overview

This local SRE skill is mostly coherent and local-only, but its service-restart path can report failed restarts as successful, which is risky for an operations tool.

Review the restart behavior before installing or enabling recovery. Keep restarts disabled unless you have explicit allowlists, use an isolated Python environment with a pinned psutil version, and treat recovery audit entries as unreliable until failed docker/pm2 restarts are reported as failures.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:20

Finding

Unpinned Third-Party Dependency Installation

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:20-22 and README.md:20-22
Vulnerability Type: Unpinned dependency resolution without integrity verification
Risk Level: Medium

Vulnerable Code

markdown

## 🚀 Installation
1. `pip install psutil`
2. Ensure `docker` and `pm2` are installed and in your PATH.

Technical Analysis

The installation instructions direct users to install psutil without specifying a reviewed version or cryptographic hashes. Consequently, the installed code depends on the package version and package-index configuration present at installation time rather than the version assessed during this audit.

Although no malicious dependency is embedded in the project, this practice exposes installation to supply-chain risks. A compromised package release, package repository, mirror, or local pip configuration could cause uncontrolled package code to be processed under the privileges of the user performing the installation.

The same unsafe instruction is duplicated in both SKILL.md and README.md.

Attack Path

1. An attacker compromises a configured Python package index, mirror, relevant package release, or package-resolution configuration.
2. The user follows the documented pip install psutil instruction.
3. Pip resolves a package version that was not pinned or reviewed with this project.
4. Malicious package installation or build logic executes with the installing user's privileges.
5. The attacker may access or modify resources available to that user.

Impact Assessment

Successful exploitation could execute code with the privileges of the user running pip. The resulting scope may include that user's files, Python environment, credentials available to the process, and other resources accessible from the installation environment. System-wide impact would require installation with elevated privileges or a separate privilege-escalation path; neither is present ...[truncated 23 chars]

Remediation

View remediation

Remediation Suggestions

1. Declare dependencies in a version-controlled requirements file using an exact, reviewed version.
2. Record cryptographic hashes for every permitted distribution and install with hash verification:

   text

   psutil==<reviewed-version> --hash=sha256:<verified-hash>
   

   bash

   python -m pip install --require-hashes -r requirements.txt
   

3. Generate the lock file from a trusted package index and review dependency updates before merging them.
4. Keep SKILL.md, README.md, and _meta.json synchronized with the locked dependency version.
5. Avoid recommending privileged or system-wide pip installation; use an isolated virtual environment.

T09 · Insecure Skill Coding Practices

Warning

• Location: monitor.py:44

Finding

Failed Service Restarts Are Recorded and Reported as Successful

Content

View full analysis

Vulnerability Details

File Location: monitor.py:44-53 and monitor.py:113-118
Vulnerability Type: Improper error handling and false success reporting
Risk Level: Medium

Vulnerable Code

python

def run_cmd(args, timeout):
    try:
        return subprocess.run(args, capture_output=True, text=True, timeout=timeout, check=True)
    except subprocess.CalledProcessError as e:
        return e
    except FileNotFoundError:
        exit_with_error(4, f"Binary not found: {args[0]}")
    except subprocess.TimeoutExpired:
        exit_with_error(5, f"Command timeout: {' '.join(args)}")

python

    run_cmd(args, T_RESTART)
    state["restarts"].append(now)
    save_state(state)
    log_audit("RECOVER", target, "SUCCESS")
    return {"status": "success", "target": target}

Technical Analysis

subprocess.run(..., check=True) raises subprocess.CalledProcessError when Docker or PM2 returns a nonzero exit status. The run_cmd function catches that exception and returns it as an ordinary value instead of propagating or explicitly reporting the failure.

In cmd_recover, the return value is ignored. The code therefore updates the restart-rate state, writes a SUCCESS audit entry, and returns a successful JSON response regardless of whether the restart command succeeded.

This creates an integrity failure in both operational output and audit records. It also causes failed attempts to consume the global restart allowance, potentially preventing subsequent legitimate recovery attempts.

Attack Path

1. Recovery is enabled and the target passes the service-discovery, allowlist, log-freshness, and rate-limit checks.
2. The invoked docker restart or pm2 restart command returns a nonzero exit status because of a runtime failure, permission denial, invalid service state, or deliberately induced service condition.
3. run_cmd catches and returns the CalledProcessError.

...[truncated 837 chars]

Remediation

View remediation

Remediation Suggestions

1. Do not convert CalledProcessError into an unchecked ordinary return value. Either allow it to propagate or return a structured result that every caller must inspect.
2. Update restart state and record SUCCESS only after confirming a zero exit status.
3. On failure, record a FAILED audit event containing a sanitized exit code and error summary, then return a nonzero process exit status.
4. Keep error output bounded and avoid placing sensitive service output in the audit log.
5. Consider verifying post-restart service state before declaring recovery successful.

Example hardening:

python

def run_cmd(args, timeout):
    try:
        return subprocess.run(
            args,
            capture_output=True,
            text=True,
            timeout=timeout,
            check=True,
        )
    except subprocess.CalledProcessError as exc:
        raise RuntimeError(
            f"{args[0]} failed with exit code {exc.returncode}"
        ) from exc

try:
    run_cmd(args, T_RESTART)
except RuntimeError as exc:
    log_audit("RECOVER", target, "FAILED", str(exc))
    exit_with_error(6, str(exc))

state["restarts"].append(now)
save_state(state)
log_audit("RECOVER", target, "SUCCESS")
return {"status": "success", "target": target}

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Behavioral AST: exec() Call, eval() Call, Dynamic Import
• 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

Findings (2)

subprocess module call

Medium

• Category: Dangerous Code Execution
• Confidence: 70% confidence

Finding

subprocess module calls execute external commands. Without careful input validation, this enables command injection.

Content

Scanner excerpt · monitor.py (reported line 46)May include surrounding context.

python

def run_cmd(args, timeout):
    try:
        return subprocess.run(args, capture_output=True, text=True, timeout=timeout, check=True)
    except subprocess.CalledProcessError as e:
        return e
    except FileNotFoundError:

Vague Triggers

Low

• Category: Not specified by scanner
• Confidence: 92% confidence

Finding

This manifest names and describes the skill but provides no explicit invocation conditions, trigger phrases, or exclusion conditions. For a manifest file, that makes activation scope ambiguous and increases the risk of unintended invocation based only on a broad description like 'local SRE agent'.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.