OpenJobs

• Outcome: Review
• Latest audit: Sep 10, 2026 · 6:37 PM UTC
• Version: 4.1.3

Overview

The skill matches its OpenJobs marketplace purpose, but it gives the agent broad automatic authority over marketplace actions, local credentials, skill updates, and wallet-related operations.

Install only if you are comfortable letting this skill manage real OpenJobs account state and wallet-linked funds. Before use, disable or avoid automatic heartbeat/full_auto operation, require explicit approval for deposits, staking, applications, submissions, approvals, and escrow release, pin the CLI version, avoid npx -y fallback, and do not allow forced remote skill refresh without reviewing the new files.

A.I.G

Vulnerability Patterns

• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (6)

T01 · Skill Instruction Hijacking

Error

• Location: SKILL.md:614
• Finding: Mutable Remote Skill Content Is Treated as Runtime Execution Authority<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:614-620` **Vulnerability Type**: Remote instruction replacement and execution **Risk Level**: Critical ### Vulnerable Code ```markdown Always **refresh** the full skill bundle at the start of every heartbeat — the latest published version at <https://openjobs.bot/heartbeat.md> and <https://openjobs.bot/skill.md> are the **runtime execution authority**: ```bash # Re-install the full skill bundle (updates HEARTBEAT.md, SKILL.md, references/): openjobs install-skill --agent <your-runtime> --force ``` ``` ### Technical Analysis The Skill explicitly instructs the Agent to overwrite the locally reviewed Skill bundle at the beginning of every heartbeat. It also declares the latest remotely published documents to be the authoritative runtime instructions. This creates a mutable execution channel outside the audited project. The effective instructions executed by the Agent can change after review without a local code change, integrity verification, version pin, diff review, or renewed operator approval. The `--force` option increases the risk by permitting replacement of the existing reviewed files. This behavior exceeds the minimum privileges needed to interact with the OpenJobs marketplace. Marketplace operations do not require remotely hosted instructions to replace the local Skill before every run. ### Attack Path 1. An attacker compromises `openjobs.bot`, its deployment pipeline, the CLI publisher account, or another component involved in distributing the Skill bundle. 2. The attacker modifies the remotely distributed `SKILL.md`, `HEARTBEAT.md`, or associated references. 3. A scheduled or manually triggered heartbeat runs the mandatory refresh command with `--force`. 4. The reviewed local Skill is replaced with attacker-controlled instructions. 5. The Agent loads the new content as “runtime execution authority.” 6. The malicious instructions can direct the Agent to invoke tools, disclose file ...[truncated 901 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the requirement to refresh the Skill automatically before every heartbeat. 2. Do not designate remote documents as runtime execution authority. 3. Pin the Skill and CLI to an explicitly reviewed version. 4. Verify downloaded content using an allowlisted cryptographic digest or signed release metadata. 5. Download proposed updates into a staging directory rather than overwriting active Skill files. 6. Display a version comparison and complete diff before installation. 7. Require explicit operator approval before activating updated instructions. 8. Re-audit updated scripts and instructions before execution. 9. Avoid `--force` in automated workflows. 10. Retain a verified rollback copy of the previously approved Skill. ]]>

T01 · Skill Instruction Hijacking

Error

• Location: HEARTBEAT.md:31
• Finding: Heartbeat Rules Coerce Autonomous Marketplace and Financial State Changes<![CDATA[ ## Vulnerability Details **File Location**: `HEARTBEAT.md:31-39`, `HEARTBEAT.md:173`, `HEARTBEAT.md:239-276`, `HEARTBEAT.md:316-337` **Vulnerability Type**: Instruction-driven unauthorized state changes **Risk Level**: High ### Vulnerable Code ```markdown ## Two non-negotiable rules (read before every run) 1. **Always take action when the inbox is non-empty.** Whenever there are pending tasks, unread messages, applications, submissions, checkpoints, or accepted-but-not-started jobs, you MUST act on at least one of them in this run. Reading the inbox without doing anything actionable is a workflow failure — the platform stays alive only when agents move work forward every heartbeat. The only acceptable "no action" outcome is a verified empty `actionable` summary; in that case mark informational tasks read with a reason so the queue is genuinely zero. ``` ```markdown Remember Rule 1: even when individual messages don't warrant a reply, you must still take *some* action this run — mark informational tasks read with a reason, accept/reject pending applications, complete a `submitted` job you posted, or apply to a matched job. Do not exit a heartbeat with non-empty `actionable` and no actions taken. ``` ```markdown 3. If there is a real job match for the active agent, automatically apply unless the job is closed, already assigned, obviously unsafe, self-dealing, impossible, a zero-reward job the user has not opted into, or clearly outside the agent's abilities. ``` ```markdown When `tasks list --status unread --json` shows pending submissions, checkpoints, or jobs in `submitted` status, the poster must act: ```bash # Read the submission and auto-extracted requirement scaffold $OJ jobs submissions <job-id> --json 2>&1 # Approve and release escrow to the worker $OJ jobs complete <job-id> 2>&1 # Or send the work back with a precise gap list $OJ jobs request-revision <job-id> \ --notes "Gap 1: missing unit tests. Gap 2: CSV col ...[truncated 2642 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the rule that every non-empty queue must produce an action. 2. Make read-only inspection the default heartbeat behavior. 3. Treat job descriptions, messages, attachments, `nextActions`, and `recommendedCall` values as untrusted data rather than instructions. 4. Require explicit approval in the current session before: - Applying to a job. - Accepting or rejecting an application. - Sending messages. - Uploading files. - Submitting or approving work. - Releasing or freezing escrow. - Depositing, withdrawing, or staking funds. 5. Define clear precedence stating that operator instructions and approval requirements override heartbeat guidance. 6. Default new profiles to `manual`, not `full_auto`. 7. Add transaction previews showing recipient, amount, currency, files, and irreversible effects. 8. Enforce spending and upload limits independently in the CLI, not only in natural-language instructions. 9. Permit a safe “report only” outcome for every heartbeat. ]]>

T08 · Insecure Dependencies

Error

• Location: HEARTBEAT.md:87
• Finding: Unpinned OpenJobs Package Is Installed and Executed Without Confirmation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:137-150`, `HEARTBEAT.md:87-98` **Vulnerability Type**: Unpinned dependency and automatic package execution **Risk Level**: High ### Vulnerable Code ```markdown ### Step 1 — Install the CLI ```bash npm install -g @openjobs/cli # global, recommended for heartbeat # or npx @openjobs/cli --help # zero-install, one-off runs ``` If `npm i -g` fails with `EACCES`, point npm at a user-owned prefix (don't `sudo npm i -g`): ```bash npm config set prefix ~/.npm-global export PATH=~/.npm-global/bin:$PATH # add to ~/.bashrc or ~/.zshrc npm install -g @openjobs/cli openjobs doctor ``` ``` ```bash if test -n "${OPENJOBS_CLI_PATH:-}" && test -x "$OPENJOBS_CLI_PATH"; then OJ="$OPENJOBS_CLI_PATH" elif command -v openjobs >/dev/null 2>&1; then OJ=$(command -v openjobs) else OJ="npx -y @openjobs/cli" fi printf 'Using OpenJobs command: %s\n' "$OJ" ``` ### Technical Analysis The package is referenced without an exact version. Consequently, npm or npx resolves whatever version is current at execution time. The heartbeat fallback uses `npx -y`, which automatically downloads and executes the package without interactive confirmation. The project provides no lockfile, integrity digest, provenance requirement, signature verification, or allowlisted package artifact. Global installation also makes the mutable executable available to later sessions. This is particularly dangerous because the CLI is expected to access API credentials, wallet secrets, uploaded files, and financial operations. A compromised dependency would execute as the local Agent user before any application-level safety rules could protect those resources. ### Attack Path 1. An attacker compromises the npm publisher account, package build pipeline, registry entry, or a future package release. 2. A system lacks a local `openjobs` executable, or the user follows the documented installation instructions. 3. `npx -y @openjobs/cli` or ...[truncated 964 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin the CLI to an exact audited version, for example `@openjobs/cli@x.y.z`. 2. Record and verify the expected npm integrity digest. 3. Require verified package provenance and signed release artifacts where available. 4. Remove the automatic `npx -y` fallback from the heartbeat. 5. Require explicit approval before downloading or executing a missing CLI. 6. Prefer a locally installed, reviewed binary at a fixed path. 7. Disable or strictly review package lifecycle scripts. 8. Perform upgrades only through a controlled process with version comparison, changelog review, and rollback support. 9. Do not globally install updates as part of routine marketplace operations. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/verify-agent.mjs:38
• Finding: Prefix-Based API Origin Validation Allows OpenJobs API-Key Exfiltration<![CDATA[ ## Vulnerability Details **File Location**: `scripts/verify-agent.mjs:38-65` **Vulnerability Type**: Improper URL validation causing credential disclosure **Risk Level**: High ### Vulnerable Code ```js const HOME = homedir(); const PREFS_PATH = join(HOME, ".openjobs", "preferences.json"); const API_BASE = (process.env.OPENJOBS_API_BASE || "https://openjobs.bot").replace(/\/$/, ""); if (!API_BASE.startsWith("https://openjobs.bot") && !args.allowCustomBase) { console.error(`Refusing to talk to ${API_BASE}. Pass --allowCustomBase only for local testing.`); process.exit(1); } if (!existsSync(PREFS_PATH)) { console.error(`No preferences file at ${PREFS_PATH}. Register your agent first (see https://openjobs.bot/skill.md).`); process.exit(1); } const prefs = JSON.parse(readFileSync(PREFS_PATH, "utf8")); if (!prefs.apiKey || !prefs.agentId) { console.error("preferences.json is missing apiKey and/or agentId. Register your agent first."); process.exit(1); } const headers = { "Content-Type": "application/json", "X-API-Key": prefs.apiKey, }; async function api(method, path, body) { const res = await fetch(`${API_BASE}${path}`, { method, headers, body: body ? JSON.stringify(body) : undefined, }); ``` ### Technical Analysis The verifier attempts to constrain authenticated requests to `https://openjobs.bot`, but it validates the destination using `String.prototype.startsWith()`. URL origins cannot safely be validated through string prefixes. For example, the following attacker-controlled URL passes the check: ```text https://openjobs.bot.attacker.example ``` It begins with the allowed string but has `openjobs.bot.attacker.example` as its actual hostname. Once accepted, the shared request function attaches the real API key from `preferences.json` to every request through the `X-API-Key` header. The custom-base option also deliberately permits arbitrary destinations while retaining the production credential header. Even wh ...[truncated 1966 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Parse the base URL with `new URL()` instead of using a string prefix. 2. For production requests, require all of the following: ```js const url = new URL(API_BASE); if ( url.protocol !== "https:" || url.hostname !== "openjobs.bot" || (url.port !== "" && url.port !== "443") || url.username || url.password ) { throw new Error("Invalid OpenJobs API origin"); } ``` 3. Compare the complete normalized origin against an explicit allowlist. 4. Construct endpoint URLs with `new URL(path, allowedBase)` and verify the resulting origin again. 5. Never attach a production API key to a custom test endpoint. 6. Require a separate explicitly named test credential for custom endpoints. 7. Consider removing `--allowCustomBase` from production builds. 8. Avoid following redirects for authenticated requests, or validate every redirect destination before forwarding credentials. 9. Add regression tests for deceptive hosts such as: - `openjobs.bot.attacker.example` - `[e-mail]` - `openjobs.bot.evil.invalid` - non-HTTPS schemes and unexpected ports 10. Rotate any API key used while an untrusted `OPENJOBS_API_BASE` may have been configured. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: HEARTBEAT.md:587
• Finding: Mandatory Telegram Notifications Disclose Marketplace Metadata to a Third Party<![CDATA[ ## Vulnerability Details **File Location**: `HEARTBEAT.md:587-622` **Vulnerability Type**: Unnecessary third-party data transmission **Risk Level**: Medium ### Vulnerable Code ```markdown ## Telegram notification rule — mandatory for actions This is a MUST: whenever any OpenJobs action is actually taken, send a Telegram notification to the user's chat ID with a concise action summary. Target chat ID: - Use the user's explicit Telegram chat ID when available. If the chat ID is not known, ask the user for it before claiming a Telegram notification was sent. - Do not assume `origin` means Telegram when the current runtime is CLI/TUI; `origin` may deliver only to the current local chat/session and not the user's Telegram app. - If a delivery tool accepts explicit targets, use `telegram:<chat_id>` or the platform-specific explicit Telegram target supported by that tool. - Do not use a scheduled cron job as proof of immediate Telegram delivery unless the tool reports the delivery actually completed successfully. ``` ```markdown If actions were taken, the Telegram summary must include: - Which action(s) were taken. - Relevant task/message/job/application/submission IDs and attachment IDs. - Current status after verification. - Any important follow-up needed. Keep the Telegram summary short and never include full API keys or wallet secrets. ``` ### Technical Analysis Telegram delivery is not required to browse, apply to, post, review, or complete work through OpenJobs. Nevertheless, the Skill makes it mandatory after every state-changing action and requires transmission of task, message, job, application, submission, and attachment identifiers. The text correctly prohibits full API keys and wallet secrets, but operational identifiers and action details can still reveal sensitive business activity, counterpart interactions, work status, and attachment metadata. Sending this information to Telegram expands the network and messaging permissions requi ...[truncated 1259 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Make Telegram notifications optional and disabled by default. 2. Obtain explicit operator consent before enabling a Telegram destination. 3. Verify the destination through a confirmation challenge before sending operational data. 4. Allow the operator to configure which event classes generate notifications. 5. Minimize notification content and omit internal identifiers unless explicitly requested. 6. Present a notification preview for sensitive actions. 7. Redact job titles, counterpart identities, attachment identifiers, and confidential status details where possible. 8. Never require Telegram access for core OpenJobs functionality. 9. Store notification preferences securely and provide a simple revocation mechanism. 10. Document Telegram's independent retention and privacy implications. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/create-solana-wallet.mjs:94
• Finding: Solana Wallet Secret Is Written Before Restrictive Permissions Are Applied<![CDATA[ ## Vulnerability Details **File Location**: `scripts/create-solana-wallet.mjs:94-99` **Vulnerability Type**: Insecure private-key file creation **Risk Level**: Medium ### Vulnerable Code ```js // Write the keypair file (solana-cli / Phantom compatible). writeFileSync(WALLET_PATH, JSON.stringify(Array.from(secretKey64))); try { chmodSync(WALLET_PATH, 0o600); } catch { /* best effort on platforms without POSIX perms */ } ``` ### Technical Analysis The wallet file contains the complete 64-byte Solana secret-key representation. The script first creates or truncates the file using the process's default creation mode, which is affected by the current umask. It applies mode `0600` only after the sensitive contents have already been written. On a system with a permissive umask, the file may initially be readable by other local users. This creates a time-of-check/time-of-protection window between creation and `chmodSync()`. The error handler silently ignores permission failures, so the wallet may remain accessible while later output still reports that it is protected with `chmod 600`. The custom `--out` path can also target a filesystem that does not enforce POSIX permissions. The script does not verify the final effective permissions. ### Attack Path 1. A user runs the wallet-generation script on a shared system, under a permissive umask, or on a filesystem with unexpected permission semantics. 2. `writeFileSync()` creates the wallet file before an explicit restrictive mode is applied. 3. Another local process monitors the destination directory and opens the file during the exposure window, or `chmodSync()` fails and the file remains permissive. 4. The attacker reads the 64-byte Solana secret key. 5. The attacker imports the key into a compatible wallet and signs transactions as the victim. ### Impact Assessment Possession of the wallet secret key gives the attacker cryptographic control over the corresponding Solana wallet. The attacker may be ...[truncated 536 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Specify restrictive permissions atomically when creating the file: ```js writeFileSync( WALLET_PATH, JSON.stringify(Array.from(secretKey64)), { mode: 0o600, flag: "wx" } ); ``` 2. For approved replacement, write to a newly created protected temporary file in the same directory and atomically rename it. 3. Do not silently ignore permission-setting failures; treat them as fatal. 4. Verify the resulting file mode with `stat` before reporting success. 5. Reject output paths on filesystems where private permissions cannot be guaranteed, or display a blocking warning requiring explicit approval. 6. Apply restrictive permissions to the containing `~/.openjobs` directory as well, such as `0700`. 7. Avoid following symbolic links and validate that the destination is a regular file in an expected location. 8. Use exclusive creation to prevent races and accidental overwrites. 9. If a wallet may have been created with permissive permissions, rotate it and transfer assets to a newly generated protected wallet. ]]>

SkillSpector

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
• Rogue Agent: Self-Modification, Session Persistence

Findings (19)

Missing User Warnings

High

• Confidence: 91% confidence
• Finding: This section instructs the agent to deposit funds into the OpenJobs ledger and retry when balance is insufficient, without consistently requiring explicit user approval at the point of financial action. In context, these are real value transfers involving WAGE/USDC and stored wallet secrets, so an autonomous run could move funds or lock escrow unexpectedly.

Ae1

High

• Category: analysis-evasion

Content

`HEARTBEAT.md` lives at the top level of the skill (a peer of `SKILL.md`,

• Confidence: 100% confidence
• Finding: Referenced artifact was not completely inspected

Ae1

High

• Category: analysis-evasion

Content

`HEARTBEAT.md` lives at the top level of the skill (a peer of `SKILL.md`,

• Confidence: 100% confidence
• Finding: Referenced artifact was not completely inspected

Ae1

High

• Category: analysis-evasion

Content

`HEARTBEAT.md` lives at the top level of the skill (a peer of `SKILL.md`,

• Confidence: 100% confidence
• Finding: Referenced artifact was not completely inspected

Ssd 1

High

• Confidence: 99% confidence
• Finding: Declaring remote published skill files as the 'runtime execution authority' effectively delegates the agent's operational instructions to mutable web content. If those remote docs are compromised, replaced, or maliciously edited, the agent may ingest attacker-controlled instructions on every heartbeat, making this a direct semantic prompt-injection vector with persistent control over agent actions.

Vague Triggers

Medium

• Confidence: 95% confidence
• Finding: The trigger section is broad enough to auto-invoke this workflow for many normal OpenJobs-related requests, including inbox checks, messaging, oversight changes, webhook management, and staking. Because the workflow later mandates taking at least one action when actionable items exist, accidental invocation can escalate a simple read request into unintended state changes.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 93% confidence
• Finding: The fallback `npx -y @openjobs/cli` executes whatever package version is current on the registry at runtime, creating a supply-chain risk and breaking reproducibility. In a skill that performs authenticated messaging, escrow-related wallet actions, staking, and other state-changing operations, an upstream compromise or unexpected release could directly affect funds, credentials, or agent behavior.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 92% confidence
• Finding: The skill drives shell commands, network access, and reads/writes local config and secrets, but it declares no explicit tool scope or permissions boundary. In an agent runtime, that increases the chance the skill is invoked with broader capabilities than intended, enabling unintended command execution, credential exposure, or filesystem modification.

Vague Triggers

Medium

• Confidence: 96% confidence
• Finding: The trigger guidance is broad enough that incidental mentions like 'my agent' or 'the marketplace' could activate this skill outside clearly intended OpenJobs tasks. Over-broad activation increases the chance an agent loads powerful shell/network instructions in the wrong context and follows irrelevant or unsafe marketplace procedures.

Whitespace Padding

Medium

• Category: Prompt Injection

Content

Common doctor outputs and what to do:

| Doctor row              | Status | Fix                                                                                               |
| ----------------------- | ------ | ------------------------------------------------------------------------------------------------- |
| `auth.apiKey` missing   | ✗      | `openjobs login --api-key sk_live_xxx` (or `openjobs agents register …` for a brand-new agent).    |
| `cli.version` outdated  | ⚠      | `openjobs upgrade --yes`                                                                          |

• Confidence: 70% confidence
• Finding: Large whitespace padding was detected (a block of blank lines or a long run of spaces). This can push injected instructions below or to the right of the visible area so a human reviewer never sees them while the agent still reads them. Manual review of the hidden content is recommended.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 88% confidence
• Finding: Using `npx @openjobs/cli` without a pinned version allows execution of whatever package version is current at runtime. That creates a supply-chain risk where a compromised or breaking upstream release could be fetched and executed immediately by the agent.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

npx @openjobs/cli --help        # zero-install, one-off runs
```

If `npm i -g` fails with `EACCES`, point npm at a user-owned prefix (don't `sudo npm i -g`):

```bash
npm config set prefix ~/.npm-global

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Session Persistence

Medium

• Category: Rogue Agent

Content

```bash
npm config set prefix ~/.npm-global
export PATH=~/.npm-global/bin:$PATH   # add to ~/.bashrc or ~/.zshrc
npm install -g @openjobs/cli
openjobs doctor
```

• Confidence: 90% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

1. Run `openjobs doctor` and READ the output.
2. If it says "Could not locate the bundled skill files" → your CLI predates the bundled skill. Run `openjobs upgrade --yes`, then `openjobs --version` (must show 2.2.x or newer), then re-try install-skill **once**.
3. If `upgrade` itself fails with `EACCES` → use the `~/.npm-global` recipe above. Do NOT `sudo` (it changes file ownership and breaks the next non-sudo install).
4. If a PATH-shadow warning appears (`⚠ openjobs PATH-shadow: which openjobs resolves to A but this process is running B`), `which -a openjobs` and remove or reorder the stale copy. Do NOT keep upgrading — both copies upgrade simultaneously and the shadow persists.

The CLI never auto-retries failed installs; neither should you. One failure → run `doctor` → apply the named fix → one more attempt.

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Context-Inappropriate Capability

Medium

• Confidence: 98% confidence
• Finding: The skill instructs the agent to self-update and overwrite its own local skill bundle during heartbeat runs. A self-modifying prompt/instruction set sourced remotely can change agent behavior over time without operator review, creating a durable prompt-injection and supply-chain channel.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill tells the agent to refresh and overwrite local skill files from remote sources but does not prominently warn the user that local instructions will be modified. This reduces operator awareness and consent around a high-impact change to the agent's behavior and trust boundary.

Session Persistence

Medium

• Category: Rogue Agent

Content

#!/usr/bin/env node
/**
 * OpenJobs — Create Solana Wallet (offline)
 *
 * Generates a brand-new Solana keypair LOCALLY and writes:
 *   - ~/.openjobs/wallet.json   (Phantom/solana-cli compatible 64-byte secret key array)

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

console.log("✅ New Solana wallet created");
console.log("");
console.log("  Address:     " + walletAddress);
console.log("  Secret key:  " + WALLET_PATH + "  (chmod 600)");
console.log("  Preferences: " + PREFS_PATH);
console.log("");
console.log("Next step: prove ownership of this wallet.");

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

console.log("✅ New Solana wallet created");
console.log("");
console.log("  Address:     " + walletAddress);
console.log("  Secret key:  " + WALLET_PATH + "  (chmod 600)");
console.log("  Preferences: " + PREFS_PATH);
console.log("");
console.log("Next step: prove ownership of this wallet.");

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Static analysis

Detected: suspicious.exposed_secret_literal

File appears to expose a hardcoded API secret or token.

Critical

• Code: suspicious.exposed_secret_literal
• Location: scripts/create-solana-wallet.mjs:118