Store Mcp Connect

• Outcome: Review
• Latest audit: Sep 16, 2026 · 6:48 AM UTC
• Version: 0.2.0

Overview

The skill is coherent and not malicious, but it asks users to connect an AI agent to high-impact store controls while giving credential setup examples that can expose bearer tokens.

Install only if you intend to let an AI agent manage your store. Use a narrowly scoped, revocable token, prefer HTTPS or a local SSH/VPN tunnel, avoid placing real tokens in project files or shell history, and use an unprivileged SSH account instead of root for forwarding.

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

Error

• Location: SKILL.md:48

Finding

Bearer Token Exposure over an Unencrypted Remote MCP Connection

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:48
Vulnerability Type: Plaintext transmission of authentication credentials
Risk Level: High

Vulnerable Code Snippet:

markdown

| **Native install (VPS)** | `http://<vps-ip>:5102/platform/v1/mcp/sse` |

Technical Analysis

The documented VPS endpoint uses plaintext HTTP even though the MCP connection authenticates with a bearer token. HTTP does not provide transport encryption, server authentication, or integrity protection.

When an agent connects to this endpoint, the bearer token and MCP traffic may be visible to any party capable of monitoring the network path. An active attacker could also alter responses or impersonate the MCP endpoint. Possession of the bearer token is sufficient to authenticate within its assigned scopes.

Attack Path

1. A user configures the AI agent with the documented remote HTTP endpoint.
2. The agent sends an authorization bearer token to the VPS over plaintext HTTP.
3. An attacker on the local network, hosting network, proxy path, or another observable network segment captures the request.
4. The attacker extracts the bearer token.
5. The attacker submits authenticated requests to the store API or MCP endpoint.
6. The attacker exercises every store-management permission granted to the compromised token.

Impact Assessment

Depending on token scopes, an attacker may gain access to store products, orders, customer conversations, profile settings, notifications, and financial account information. Write-capable scopes may permit product modification or deletion, fraudulent buyer messages, order fulfillment changes, refunds, or store-profile manipulation.

The compromise remains effective until the exposed token expires or is revoked.

Remediation

View remediation

Remediation Suggestions

• Remove direct remote HTTP endpoints from the recommended configurations.
• Require HTTPS with a valid, trusted certificate for all non-loopback MCP and API connections.
• If HTTPS is unavailable, require an authenticated SSH or VPN tunnel and connect through a loopback address.
• Configure clients to reject invalid certificates rather than disabling certificate validation.
• Document immediate token revocation and rotation procedures for suspected transport exposure.
• Consider issuing narrowly scoped, short-lived tokens so compromise does not grant unrestricted or durable access.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:134

Finding

Bearer Tokens Exposed through Command-Line Arguments and Shell History

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:134, SKILL.md:186, and SKILL.md:225
Vulnerability Type: Insecure command-line secret handling
Risk Level: Medium

Vulnerable Code Snippets:

bash

codex mcp add mobazha-store --transport sse \
  --url "https://shop.example.com/platform/v1/mcp/sse" \
  --header "Authorization: Bearer <your-token>"

bash

docker exec -it <container> mobazha-mcp --gateway-url http://localhost:5102 --token <token>

bash

curl -H "Authorization: Bearer <token>" http://localhost:5102/v1/profiles

Technical Analysis

The instructions encourage users to substitute a real bearer token directly into command-line arguments. Secrets supplied this way can be retained in shell history, terminal transcripts, command auditing systems, diagnostic logs, or process metadata.

On systems where process arguments are visible to other local accounts or monitoring software, the token may also be observable while the command is running. This practice conflicts with the credential-safety guidance in the same file.

Attack Path

1. A user replaces the placeholder with a valid store token and executes one of the documented commands.
2. The command, including the token, is written to shell history, captured by terminal logging, or exposed through process inspection.
3. A local user, support operator, malware process, log collector, or party with access to backed-up history files retrieves the token.
4. The attacker uses the token against the MCP or store API endpoint.
5. The attacker performs operations allowed by the token until it expires or is revoked.

Impact Assessment

The attacker obtains the same effective store privileges as the compromised bearer token. The scope may include reading sensitive commercial and customer data or executing destructive store-management actions. Exposure can persist beyond command completion becaus ...[truncated 74 chars]

Remediation

View remediation

Remediation Suggestions

• Do not pass bearer tokens through command-line arguments.
• Prefer a secrets manager, protected environment injection, or standard input where the relevant client supports it.
• For curl, use a permission-restricted configuration file or retrieve the token from a secrets manager without entering it into interactive shell history.
• For the stdio tool, use MOBAZHA_TOKEN through a protected runtime secret facility rather than --token.
• Configure shell-history suppression only as defense in depth; it should not replace secure secret injection.
• Warn users to revoke tokens already entered into shared terminals, scripts, tickets, or logged command sessions.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:103

Finding

Persistent Plaintext Bearer Tokens in Agent Configuration Files

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:103, SKILL.md:120, SKILL.md:148, and SKILL.md:206
Vulnerability Type: Insecure persistent credential storage
Risk Level: Medium

Vulnerable Code Snippets:

json

"headers": {
  "Authorization": "Bearer <your-token>"
}

json

"env": {
  "MOBAZHA_TOKEN": "<your-token>"
}

Technical Analysis

The Claude Code, Cursor, OpenCode, and stdio examples instruct users to insert a bearer token directly into JSON configuration. Once replaced with a real value, the token is stored as plaintext.

Project-level configurations are particularly prone to accidental version-control commits, sharing, indexing, backup collection, and disclosure through support bundles. User-level configuration files can likewise be exposed if permissions are overly broad or a workstation account is compromised. Although the document advises users not to commit tokens and to add affected files to .gitignore, the primary examples still normalize direct plaintext storage.

Attack Path

1. A user places a valid bearer token into an MCP configuration file.
2. The file is committed to a repository, copied into an archive, synchronized through cloud storage, included in a support bundle, or left readable by another local account.
3. An attacker obtains the configuration file and extracts the token.
4. The attacker discovers or infers the associated store endpoint from the same configuration.
5. The attacker authenticates to the endpoint and invokes operations within the token's scopes.

Impact Assessment

Disclosure grants the attacker the token's store-management permissions. A repository disclosure can expose the credential to every repository reader and potentially to automated crawlers. Removing a token from the latest revision is insufficient if it remains in version-control history, caches, forks, logs, or backups.

Remediation

View remediation

Remediation Suggestions

• Use agent-supported secret references or operating-system credential stores instead of literal token values.
• Keep secrets outside project directories and inject them only at runtime.
• Apply restrictive file permissions to any unavoidable secret-bearing configuration.
• Provide .gitignore entries as part of setup rather than only suggesting them.
• Add secret scanning to pre-commit hooks and CI pipelines.
• Use narrowly scoped, short-lived tokens and rotate them regularly.
• If a token is committed, revoke it immediately and remove it from repository history, forks, caches, and build artifacts.

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:84

Finding

Unnecessary Use of the Root Account for SSH Port Forwarding

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:84
Vulnerability Type: Violation of least privilege
Risk Level: Medium

Vulnerable Code Snippet:

bash

ssh -L 5102:localhost:5102 root@<vps-ip>

Technical Analysis

Establishing a local SSH port forward does not normally require a remote root account. The example encourages users to enable or use direct root SSH access for a task that can be completed by an unprivileged account.

Root credentials or keys have substantially greater value than a dedicated forwarding account. If the workstation, private key, SSH agent, or session is compromised, the resulting access may provide unrestricted control of the VPS rather than only the connectivity required for the MCP tunnel.

Attack Path

1. A user follows the example and configures direct root SSH access to the VPS.
2. The user authenticates with a root password, root private key, or forwarded SSH agent.
3. An attacker compromises the client workstation, steals the credential, abuses agent forwarding, or takes control of the active session.
4. The attacker reconnects as root or operates through the hijacked root session.
5. The attacker obtains unrestricted administrative control of the host and its store deployment.

Impact Assessment

Successful exploitation can provide full VPS privileges, exceeding the store API permissions involved in the original task. An attacker with root access can read or alter store data, extract application secrets, modify binaries and configuration, intercept tokens, stop services, erase logs, or compromise other workloads hosted on the same server.

Remediation

View remediation

Remediation Suggestions

• Replace the root account with a dedicated unprivileged SSH account.
• Restrict the account to port forwarding with controls such as AllowTcpForwarding local, PermitOpen localhost:5102, and prohibition of interactive shells where operationally suitable.
• Disable direct root SSH login using PermitRootLogin no.
• Require key-based authentication and protect private keys with passphrases and secure storage.
• Avoid SSH agent forwarding unless it is strictly necessary.
• Monitor and rate-limit SSH authentication attempts and review forwarding-account logs.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (1)

External Transmission

Medium

• Category: Data Exfiltration
• Confidence: 60% confidence

Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · SKILL.md (reported line 66)May include surrounding context.

Open your store's admin panel in a browser and generate a token via Settings > API, or via curl:

bash

curl -X POST https://shop.example.com/platform/v1/auth/tokens \
  -H "Content-Type: application/json" \
  -d '{"username": "admin", "password": "<your-admin-password>"}'

Static analysis

No suspicious patterns detected.