EvoMap Auto Publish v3.0

• Outcome: Review
• Latest audit: Sep 11, 2026 · 2:40 PM UTC
• Version: 3.0.0

Overview

This skill is an auto-publisher that also creates and stores a remote publishing identity, sends host metadata, and asks for broader remote capabilities than its stated publishing purpose needs.

Review this before installing if you are comfortable letting it register a node with EvoMap, publish asset metadata, and store a bearer credential in plaintext files. Prefer running it only in a controlled skill directory, protect .node_secret with owner-only permissions, and avoid using it until the publisher narrows capabilities to publish-only and documents all outbound data.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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 (4)

T09 · Insecure Skill Coding Practices

Warning

• Location: publish-asset-v2.js:60

Finding

Node bearer secret stored without restrictive file permissions

Content

View full analysis

Vulnerability Details

File Location: publish-asset-v2.js:60-63
Vulnerability Type: Plaintext credential storage with unsafe default permissions
Risk Level: Medium

Vulnerable Code

js

const saveNodeSecret = (secret) => {
  const secretFile = path.join(__dirname, '.node_secret');
  fs.writeFileSync(secretFile, secret);
};

Technical Analysis

The node bearer credential is stored in plaintext through fs.writeFileSync without an explicit restrictive file mode. For a newly created file, Node.js uses a default mode subject to the process umask. In environments with a permissive umask, the resulting .node_secret file may be readable by other local users or processes.

The implementation also does not verify whether .node_secret is a symbolic link before writing. If an attacker can modify the Skill directory, this may permit an unintended file overwrite, although such an attacker already requires local write access to that directory.

Sending this secret to the declared EvoMap publishing endpoint as an Authorization token is necessary for the advertised functionality. The vulnerability concerns its local storage rather than confirmed network exfiltration.

Attack Path

1. A user runs publish-asset-v2.js.
2. The Skill registers the node and receives a node_secret from EvoMap.
3. The secret is written to .node_secret using default filesystem permissions.
4. Another local account or process with file-read access obtains the credential.
5. The attacker submits authenticated requests to the EvoMap API using the stolen bearer secret.
6. The attacker may impersonate the registered node and publish assets under its identity.

Impact Assessment

Exploitation can expose the node's authentication credential. The attacker obtains the API privileges assigned to that node, principally the ability to authenticate and publish assets. The issue does not directly grant operating-system priv ...[truncated 52 chars]

Remediation

View remediation

Remediation Suggestions

• Create the secret file with owner-only permissions:

  js

  fs.writeFileSync(secretFile, secret, {
    mode: 0o600,
    flag: 'w'
  });
  fs.chmodSync(secretFile, 0o600);
  

• Inspect the destination with lstatSync and reject symbolic links before writing.
• Store the credential in an operating-system credential manager where available.
• Avoid placing the secret in shared, archived, or source-controlled directories.
• Add .node_secret and .node_id to .gitignore.
• Document the credential's scope, rotation policy, and revocation procedure.

T09 · Insecure Skill Coding Practices

Warning

• Location: publish-llm-optimizer.js:37

Finding

Node bearer secret stored without restrictive file permissions in the LLM optimizer publisher

Content

View full analysis

Vulnerability Details

File Location: publish-llm-optimizer.js:37-39
Vulnerability Type: Plaintext credential storage with unsafe default permissions
Risk Level: Medium

Vulnerable Code

js

const saveNodeSecret = (secret) => {
  fs.writeFileSync(path.join(__dirname, '.node_secret'), secret);
};

Technical Analysis

The returned EvoMap bearer secret is written to a plaintext file without specifying an owner-only mode. Its effective permissions therefore depend on the process umask and filesystem configuration. In a multi-user or shared execution environment, other local principals may be able to read and reuse the secret.

No symlink validation is performed before the write. An attacker with write access to the Skill directory could potentially redirect the operation to another file. The code does not transmit the secret to an undeclared destination; its subsequent use as an Authorization credential for EvoMap is consistent with the publishing function.

Attack Path

1. A user executes publish-llm-optimizer.js.
2. The script registers with EvoMap and receives a node bearer secret.
3. The script saves that secret to .node_secret with default permissions.
4. A local attacker or compromised process reads the file.
5. The attacker reuses the bearer credential in requests to EvoMap.
6. Requests made with the stolen credential are attributed to the victim's node.

Impact Assessment

A successful attacker can assume the API authority granted to the registered node, including authenticated asset publication. The scope is limited to the permissions associated with that bearer credential; no direct host-level privilege escalation is demonstrated.

Remediation

View remediation

Remediation Suggestions

• Write the file with mode 0o600 and enforce that mode on existing files:

  js

  const secretFile = path.join(__dirname, '.node_secret');
  fs.writeFileSync(secretFile, secret, {
    mode: 0o600,
    flag: 'w'
  });
  fs.chmodSync(secretFile, 0o600);
  

• Reject symbolic links and unexpected file types before writing.
• Prefer a platform credential store rather than plaintext storage.
• Ensure the secret file is excluded from source control, backups, logs, and package publication.
• Provide a mechanism to revoke and rotate a potentially exposed secret.

T05 · Unauthorized Access and Privilege Escalation

Note

• Location: publish-asset-v2.js:75

Finding

Node registration advertises unnecessary task and swarm capabilities

Content

View full analysis

Vulnerability Details

File Location: publish-asset-v2.js:75-81
Vulnerability Type: Violation of least-privilege registration
Risk Level: Low

Vulnerable Code

js

payload: {
  capabilities: { tasks: true, publish: true, swarm: true },
  env_fingerprint: { platform: process.platform, arch: process.arch },
  rotate_secret: true
}

Technical Analysis

The declared function of the Skill is asset publication. Nevertheless, node registration advertises support for task handling and swarm participation in addition to publishing. No corresponding task or swarm implementation is present in the reviewed project.

Advertising unsupported and unnecessary capabilities exceeds the minimum declaration needed for a publishing-only client. Depending on how the remote service interprets capability registration, the node could be considered eligible for broader coordination workflows. The registration also sends the operating-system platform and architecture, which is unnecessary host metadata unless explicitly required by the protocol.

The code does not establish that EvoMap grants additional operating-system privileges. The risk is an unnecessarily broad remote-service role and avoidable metadata disclosure.

Attack Path

1. The user runs the publishing script without an existing valid secret.
2. The script automatically registers with EvoMap.
3. Registration claims tasks, publish, and swarm capabilities.
4. The service records the node as supporting roles beyond publication.
5. If the service uses these declarations for routing or authorization, the node may be exposed to task or swarm interactions that the user did not request.

Impact Assessment

The potential impact is expansion of the node's remote-service role beyond the Skill's stated purpose and disclosure of platform and architecture metadata. No evidence shows that local system permissions are elevated or that remote tasks are a ...[truncated 31 chars]

Remediation

View remediation

Remediation Suggestions

• Register only the capability required by the Skill:

  js

  capabilities: { publish: true }
  

• Remove the environment fingerprint unless the protocol makes it mandatory.
• If fingerprinting is mandatory, document the exact transmitted fields and obtain explicit user consent.
• Do not automatically enable future capabilities; require separate opt-in configuration for task or swarm functionality.
• Ensure the server independently validates authorization rather than trusting self-declared capabilities.

T05 · Unauthorized Access and Privilege Escalation

Note

• Location: publish-llm-optimizer.js:50

Finding

LLM optimizer publisher advertises unnecessary task and swarm capabilities

Content

View full analysis

Vulnerability Details

File Location: publish-llm-optimizer.js:50-56
Vulnerability Type: Violation of least-privilege registration
Risk Level: Low

Vulnerable Code

js

payload: {
  capabilities: { tasks: true, publish: true, swarm: true },
  env_fingerprint: { platform: process.platform, arch: process.arch },
  rotate_secret: true
}

Technical Analysis

This script is documented as publishing a predefined LLM optimization asset. Its registration request nevertheless claims task and swarm capabilities that are not needed for asset publication and are not implemented elsewhere in the project.

The request also discloses the host platform and CPU architecture. Although limited, this metadata can assist remote fingerprinting and is not clearly necessary for the publishing operation. Whether the capability declaration results in additional authority depends on EvoMap's server-side implementation.

The OpenAI API request shown elsewhere in this file is contained inside the published code_snippet string. It is not evaluated by the script, and the audit found no execution or transmission of the local OPENAI_API_KEY.

Attack Path

1. The user runs publish-llm-optimizer.js without a valid cached node secret.
2. The script automatically sends a registration request to EvoMap.
3. The request advertises task and swarm support in addition to publication.
4. EvoMap may classify the node as eligible for broader coordination functions.
5. This unnecessarily expands the node's declared remote-service exposure and reveals host fingerprint information.

Impact Assessment

The direct impact is limited to excessive capability declaration and disclosure of platform and architecture. If the server grants or routes functionality based on these declarations, the node could receive a broader remote role than intended. The reviewed code does not fetch or execute remote tasks and does not demonstrate ...[truncated 27 chars]

Remediation

View remediation

Remediation Suggestions

• Limit registration to { publish: true }.
• Remove tasks and swarm unless separately implemented and explicitly enabled by the user.
• Omit environment fingerprint data unless required for protocol interoperability.
• Clearly disclose all registration metadata and remote capabilities in the documentation.
• Require explicit consent before enabling any remote coordination role beyond asset publication.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (18)

Context-Inappropriate Capability

High

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

Finding

During registration, the client claims capabilities for tasks, publish, and swarm even though the stated purpose is asset publishing. Overstating capabilities can cause the remote service to treat this node as eligible for broader orchestration or tasking, unnecessarily enlarging the attack surface and potentially authorizing workflows the operator did not intend.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

High

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

Finding

The embedded asset code snippet performs an external call to OpenAI and reads OPENAI_API_KEY even though the surrounding tool is presented as an auto-publisher. This creates a risky capability mismatch: downstream consumers may treat the published asset as benign metadata while it contains code that can exfiltrate prompts or consume paid API credentials when copied or executed.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The README instructs users to write a long-lived authentication secret to a local plaintext file (.node_secret) but provides no warning about its sensitivity, file permissions, exclusion from version control, or safe storage practices. This increases the chance of accidental disclosure through local compromise, backups, logs, screenshots, or committing the file to a repository, which could allow unauthorized publishing as that node.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The README states that mutating endpoints require Authorization: Bearer <node_secret> and that registration/secret handling is automatic, but it does not warn users that credentials will be transmitted over the network or explain the trust boundary involved. In context, this is more dangerous because the skill is an auto-publishing tool that encourages routine automated use, so users may hand over bearer credentials to remote services without understanding exposure risks, endpoint validation needs, or the consequences of compromise.

Content

No source excerpt is available for this finding.

Undeclared Tool Scope

Medium

• Category: MCP Least Privilege
• Confidence: 93% confidence

Finding

The skill advertises capabilities that involve environment access and network communication, but the manifest does not declare any tool scope such as permissions or allowed-tools. This creates an execution-transparency problem: users and platforms cannot easily assess or constrain what the skill may access before running it, which is especially risky for a publishing tool that can transmit data and use credentials.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The documentation states that the skill performs automated publishing and uses Authorization Bearer authentication, but it does not clearly warn that running it may send asset contents, node identifiers, and authentication material to a remote Hub. That omission can lead users to run the skill without informed consent, increasing the chance of unintended data disclosure or credential exposure.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

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

Finding

User-facing logs and operational messages throughout the file are written in Chinese, which effectively forces one language for interaction. The file does not offer an opt-in language selection or explain that the skill is intentionally region- or locale-specific.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

Medium

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

Finding

The script does more than 'auto-publish': it provisions a persistent node identity, registers that identity with a remote hub, and stores authentication material locally. This expands the trust boundary and creates persistent remote association and credential lifecycle behavior that a user may not expect from a publishing utility, increasing the risk of unintended enrollment and long-lived access.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The code writes the node secret directly to a local .node_secret file without permission hardening, secure storage, or prominent disclosure to the user. If the working directory is shared, backed up, committed, or readable by other local users/processes, the bearer token can be stolen and reused to impersonate the node against the remote hub.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

Medium

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

Finding

The script does more than a simple auto-publish function: it creates persistent local node identity, stores a node secret on disk, and collects host fingerprint data for remote transmission. In an agent-skill context, this expands the trust boundary and introduces undisclosed credential persistence and device-identifying telemetry that could be misused if the remote service is untrusted or compromised.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The code persists node identifiers and secrets in local dotfiles without any user-facing warning, consent flow, or evident file-permission hardening. In a skill environment, silent credential persistence can expose secrets to other local users, backups, repository commits, or later malware on the host.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The registration payload sends environment fingerprint data and later publishes extensive asset metadata to a remote hub without clear upfront disclosure of the exact transmitted fields. Undisclosed telemetry is particularly concerning in agent skills because users may execute them expecting local automation, not host profiling and remote metadata export.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Medium

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

Finding

The documentation and asset text repeatedly describe 'semantic cache' and 'streaming response parsing' as implemented features. In the code snippet, generateSemanticKey uses a simple lowercase SHA-256 hash rather than semantic similarity or embeddings, and callLLM performs a normal JSON completion request with no streaming or incremental parsing logic, directly contradicting those claims.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Medium

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

Finding

The capsule content asserts that the solution 'Includes real-time cost dashboard and automatic cache invalidation.' The provided implementation contains no dashboard generation, telemetry UI, reporting endpoint, or related code, so the documentation actively overstates what the code does.

Content

No source excerpt is available for this finding.

External Transmission

Medium

• Category: Data Exfiltration
• Confidence: 93% confidence

Finding

The hardcoded OpenAI endpoint confirms transmission of data to a third-party service outside the stated publishing workflow. Even if embedded in a code snippet, publishing such code as part of a trusted skill can facilitate covert data export or credential misuse when consumers reuse or execute it.

Content

Scanner excerpt · publish-llm-optimizer.js (reported line 227)May include surrounding context.

js

async callLLM(prompt, options) {
    // Placeholder for actual LLM call
    return global.fetch ? await global.fetch('https://api.openai.com/v1/chat/completions', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json', 'Authorization': 'Bearer ' + process.env.OPENAI_API_KEY },
      body: JSON.stringify({ model: 'gpt-4', messages: [{ role: 'user', content: prompt }] })

External Transmission

Medium

• Category: Data Exfiltration
• Confidence: 93% confidence

Finding

The hardcoded OpenAI endpoint confirms transmission of data to a third-party service outside the stated publishing workflow. Even if embedded in a code snippet, publishing such code as part of a trusted skill can facilitate covert data export or credential misuse when consumers reuse or execute it.

Content

Scanner excerpt · publish-llm-optimizer.js (reported line 227)May include surrounding context.

js

async callLLM(prompt, options) {
    // Placeholder for actual LLM call
    return global.fetch ? await global.fetch('https://api.openai.com/v1/chat/completions', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json', 'Authorization': 'Bearer ' + process.env.OPENAI_API_KEY },
      body: JSON.stringify({ model: 'gpt-4', messages: [{ role: 'user', content: prompt }] })

Natural-Language Policy Violations

Low

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

Finding

Natural-language policy violations apply to all file types, including markdown. The content uses Chinese for the description and operational guidance, and there is no opt-in, alternative language, or explicit justification that the skill is intended only for Chinese-speaking users or a China-specific context.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

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

Finding

The natural-language description is written entirely in Chinese and does not indicate that users can choose another language or locale. Under the stated policy, forcing a specific language without opt-in can be a locale-policy violation when no justification is provided.

Content

No source excerpt is available for this finding.