Native Install

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

Overview

The skill is for installing Mobazha, but it asks users to run mutable remote shell scripts that install, auto-start, auto-update, and purge local data.

Review this carefully before installing. Prefer a signed, versioned release or a downloaded installer whose checksum/signature you can verify before execution. Use --no-start for initial installation if available, understand what service and auto-update components will run, and back up store data before any purge operation.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:13

Finding

Mutable Remote Installer Is Executed Directly by Bash

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:13-20
Vulnerability Type: Remote payload retrieval and execution
Risk Level: High

markdown

## Quick Install

> **Security note**: The install commands below download and execute a shell script from `get.mobazha.org`. Before running, you can review the script with `curl -sSL https://get.mobazha.org/install | less`. Only proceed if the user confirms they trust the source.

### Linux & macOS

```bash
curl -sSL https://get.mobazha.org/install | bash

text

### Technical Analysis

The command sends the current response from `https://get.mobazha.org/install` directly to Bash. The effective installer is not included in the audited project and can change after the Skill has been reviewed. The command does not pin an installer version, verify an independently published hash, or validate a cryptographic signature before execution.

Although the documentation recommends reviewing the script, the executable command does not enforce that review. Binary checksum validation reportedly performed inside the installer cannot establish trust in the installer itself because the remote script controls both the download and verification process.

### Attack Path

1. An attacker compromises the installer domain, hosting account, publication pipeline, DNS resolution, or another component of the delivery channel.
2. The attacker modifies the response returned by `https://get.mobazha.org/install`.
3. A user or agent follows the documented installation command.
4. `curl` retrieves the modified response and passes it directly to Bash.
5. The attacker-controlled commands execute with all privileges available to the invoking account.
6. The payload may modify user files, access credentials, register services, download additional components, or establish network access.

### Impact Assessment

Successful exploitation provides arbitrary command execution under the invoking use
...[truncated 498 chars]

Remediation

View remediation

Remediation Suggestions

• Do not pipe network responses directly into a shell.
• Publish a versioned installer as an immutable release artifact.
• Download the installer to a local file without executing it.
• Provide an expected SHA-256 digest through an independent, trusted channel and verify it before execution.
• Prefer a detached digital signature verified against a documented, pinned public key.
• Display the verified installer to the user and require explicit confirmation before execution.
• Prefer signed operating-system packages or signed release binaries over a general-purpose shell installer.
• Run installation with ordinary user privileges and use --no-start by default.
• Pin downloaded application binaries and launcher components to explicit versions, and verify each artifact independently.

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:86

Finding

Remote Uninstall Script Can Perform Destructive Purge Operations

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:86-98
Vulnerability Type: Remote payload retrieval and execution with destructive file operations
Risk Level: High

markdown

## Uninstall

Remove the binary and service (keeps your store data):

```bash
curl -sSL https://get.mobazha.org/install | bash -s -- --uninstall

Remove everything including data:

bash

curl -sSL https://get.mobazha.org/install | bash -s -- --uninstall --purge

text

### Technical Analysis

Both removal procedures retrieve a mutable remote script and immediately execute it. The `--purge` operation is explicitly intended to delete application data, but the project contains no local uninstaller implementation that would allow reviewers to confirm the deletion targets, path validation, symlink handling, or safeguards against deleting unrelated files.

Passing `--uninstall` or `--purge` does not constrain what the downloaded shell program can do. A compromised or defective script can ignore those arguments and execute arbitrary commands. This creates both a remote-code-execution risk and a heightened data-loss risk.

### Attack Path

1. A user requests removal or complete purging of Mobazha.
2. Before the command is run, the remote installer endpoint or its publication process is compromised or unintentionally changed.
3. The documented command downloads the current script and executes it with Bash.
4. The remote script receives the uninstall flags but remains free to perform arbitrary actions.
5. A malicious script can delete unrelated user files, steal data before deletion, retain persistence, or install a replacement payload.
6. Alternatively, unsafe path or symlink handling in a defective legitimate script could cause deletion outside the intended Mobazha directories.

### Impact Assessment

Exploitation can produce arbitrary command execution with the invoking user's permissions. The purge workflow additionally cr
...[truncated 338 chars]

Remediation

View remediation

Remediation Suggestions

• Provide an auditable local uninstaller rather than downloading fresh code during removal.
• If a downloaded uninstaller is unavoidable, pin its version and verify an independently published hash and cryptographic signature before execution.
• Enumerate every service, binary, configuration directory, and data directory that will be removed.
• Resolve and validate canonical paths before deletion and reject empty, root, home-directory, or unexpected path values.
• Defend against symlink traversal and avoid broad wildcard or recursively constructed deletion commands.
• Present exact deletion targets and require a separate, explicit confirmation immediately before --purge.
• Create or recommend a backup before destructive removal.
• Keep service removal, binary removal, and data purging as separate operations with independent confirmation.
• Test the uninstaller under a least-privileged account and fail safely when a target is outside the documented application directories.

T06 · System Persistence

Warning

• Location: SKILL.md:31

Finding

Installer Enables Persistent Service and Auto-Update Components by Default

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:31-40
Vulnerability Type: System persistence
Risk Level: Medium

markdown

## What the Installer Does

1. Detects your OS and architecture (linux/darwin, amd64/arm64)
2. Downloads the matching binary from GitHub Releases
3. Verifies the SHA-256 checksum
4. Places binaries in `~/.local/bin/` (or custom `--dir`)
5. Downloads the launcher binary (crash recovery + auto-update) if available
6. Registers and starts as a background service (unless `--no-start` is passed)

Technical Analysis

The default installation workflow downloads an additional launcher with auto-update functionality and registers an automatically started background service. On Linux, the documentation states that systemd is used, preferably in user mode; on macOS, a launchd LaunchAgent is registered. These mechanisms survive completion of the Skill run and can execute across later login sessions.

Persistence is functionally related to operating a continuously available store, and it is disclosed in the documentation. Nevertheless, automatically starting a service and installing an auto-update channel exceed the minimum privileges and system changes required merely to install a native binary. The project does not include the launcher, update implementation, signing policy, update endpoint, verification key, or rollback-protection design, so the ongoing update trust boundary cannot be audited.

Attack Path

1. The user runs the documented default installation command without --no-start.
2. The installer downloads the launcher and creates a systemd user service or macOS LaunchAgent.
3. The launcher and store continue to start in later sessions without another installation command.
4. If the launcher, update source, publication credentials, or update-verification process is later compromised, a modified binary may be delivered.
5. The persistent service executes the modified compon ...[truncated 798 chars]

Remediation

View remediation

Remediation Suggestions

• Make download-only installation the default behavior, equivalent to --no-start.
• Separate binary installation, service registration, service startup, and automatic updates into explicit opt-in steps.
• Explain the exact systemd unit or LaunchAgent path, executable path, environment, permissions, and removal procedure before registration.
• Provide service definitions in the audited package or as independently verifiable signed artifacts.
• Run the service as an unprivileged, dedicated account where practical and restrict filesystem and network access.
• Require cryptographically signed updates validated against a pinned public key.
• Pin update versions, reject downgrade attempts, and provide rollback protection and an update audit log.
• Allow users to disable automatic updates while retaining manual, verified update functionality.
• Bind the web service to localhost by default unless the user explicitly enables remote access.
• Document P2P exposure, authentication requirements, and firewall implications before starting the service.

SkillSpector

Vulnerability Patterns

• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• YARA Signatures: Malware Match, Webshell Match, Cryptominer Match
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration

Findings (7)

External Script Fetching

High

• Category: Supply Chain
• Confidence: 98% confidence

Finding

The skill instructs users to fetch and immediately execute a remote installer via curl ... | bash, which gives arbitrary code from get.mobazha.org direct execution on the host. Even though the text advises users they may review the script first, the primary documented path is still unsafe-by-default and can lead to full host compromise if the server, DNS, TLS trust chain, or upstream content is malicious or tampered with.

Content

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

Linux & macOS

bash

curl -sSL https://get.mobazha.org/install | bash

This downloads the mobazha binary (and the mobazha-launcher for auto-update) to ~/.local/bin/ and starts the store as a background service.

Chaining Abuse

High

• Category: Tool Misuse
• Confidence: 98% confidence

Finding

The pipe into bash is the core chaining-abuse issue: it converts a network fetch directly into shell execution with no stable review boundary. In an agent skill context, this is more dangerous because an automated assistant may reproduce the exact command for users, amplifying unsafe execution on developer or production hosts.

Content

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

Linux & macOS

bash

curl -sSL https://get.mobazha.org/install | bash

This downloads the mobazha binary (and the mobazha-launcher for auto-update) to ~/.local/bin/ and starts the store as a background service.

External Script Fetching

High

• Category: Supply Chain
• Confidence: 97% confidence

Finding

The uninstall command again retrieves a remote script and executes it immediately, now with destructive flags. This creates the same arbitrary-code-execution risk as the install path, with added potential for data or service removal if the fetched script is malicious or altered.

Content

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

Remove the binary and service (keeps your store data):

bash

curl -sSL https://get.mobazha.org/install | bash -s -- --uninstall

Remove everything including data:

External Script Fetching

High

• Category: Supply Chain
• Confidence: 98% confidence

Finding

The purge command pipes a remotely fetched script into bash with flags that remove both software and data. This is especially dangerous because users are primed to run a destructive operation, so a compromised installer source could execute arbitrary commands while appearing consistent with expected behavior.

Content

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

Remove everything including data:

bash

curl -sSL https://get.mobazha.org/install | bash -s -- --uninstall --purge

Platform Notes

External Script Fetching

High

• Category: Supply Chain
• Confidence: 95% confidence

Finding

The macOS note explicitly normalizes curl | bash and notes that it bypasses Gatekeeper. That context makes the behavior more dangerous because it encourages users to circumvent a platform security control while executing unaudited network-delivered shell code.

Content

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

md

### macOS

- Installs via `curl | bash`, which bypasses Gatekeeper (no Apple Developer signing required)
- The launcher registers as a launchd LaunchAgent for auto-start on login
- Supports both Apple Silicon (arm64) and Intel (amd64)

YARA rule 'backdoor_persistence': Backdoor persistence with malicious payloads (shell commands, SSH key injection, hidden root users) [malware]

High

• Category: YARA Match
• Confidence: 75% confidence

Finding

YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).

Content

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

/adminfor VPS) 2. Complete the **Setup Wizard** — set admin password, store name, visibility, region/currency (seestore-onboardingskill for the full walkthrough) 3. Add products and start selling 4. (Optional) Connect your AI agent to the store via MCP — seestore-mcp-connect` skill

Troubleshooting

Binary not found after install

Ensure ~/.local/bin is in your PATH:

bash

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc && source ~/.bashrc

Permission denied

The installer needs write access to the install directory. Use --dir to specify a writable location, or run with appropriate permissions.

macOS "unverified developer" warning

This shouldn't happen with curl | bash install. If running a downloaded binary directly, use:

bash

xattr -d com.apple.quarantine ./mobazha

Check service logs

bash

# Linux
journalctl --user -u mobazha -f

# macOS
tail -f ~/Library/Logs/Mobazha/mobazha.log

External Script Fetching

High

• Category: Supply Chain
• Confidence: 90% confidence

Finding

Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

Content

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

macOS "unverified developer" warning

This shouldn't happen with curl | bash install. If running a downloaded binary directly, use:

bash

xattr -d com.apple.quarantine ./mobazha

Static analysis

No suspicious patterns detected.