Security audit
Security checks for vulnerabilities and agentic risk
This skill is a plausible VPS store installer, but it asks users to run an unverified remote installer as root and enables persistent automatic updates.
Review carefully before installing. Only run this on a disposable or well-backed-up VPS if you trust Mobazha's installer source, and prefer a pinned, checksum- or signature-verified installer. Use a domain with HTTPS or a secure SSH tunnel for first admin setup, and check how to disable or audit the hourly updater before using it for real store or payment data.
SKILL.md:43Unpinned Remote Installer Is Executed with Root Privileges
SKILL.md:75Installer Establishes a Persistent Hourly Auto-Update Mechanism
SKILL.md:88Initial Administrative Onboarding Is Offered over Plaintext HTTP
This is a textbook external-script-fetching vulnerability: curl retrieves code from a remote domain and immediately executes it. Because the script is not pinned, signed, hashed, or reviewed in the documented flow, any compromise of the delivery path becomes arbitrary code execution on the user's server.
Zero-config (most common):
curl -sSL https://get.mobazha.org/standalone | sudo bash
With a pre-configured domain (enables auto-TLS via Let's Encrypt):
The pipe operator chains network retrieval directly into privileged execution, removing any inspection boundary between untrusted input and root-level command execution. This is dangerous because it compresses compromise and execution into a single step that is hard for users or tooling to audit.
Zero-config (most common):
curl -sSL https://get.mobazha.org/standalone | sudo bash
With a pre-configured domain (enables auto-TLS via Let's Encrypt):
The domain-enabled command still fetches and executes untrusted remote content inline. The nearby warning suggesting users can review the script is helpful but insufficient because the actual prescribed command bypasses review and integrity verification entirely.
With a pre-configured domain (enables auto-TLS via Let's Encrypt):
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com
Privacy mode with Tor:
This chained command combines remote content ingestion with privileged shell execution while also accepting a domain parameter. The command structure itself is the issue: it treats untrusted network data as executable shell input without a trust-verification boundary.
With a pre-configured domain (enables auto-TLS via Let's Encrypt):
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com
Privacy mode with Tor:
Fetching and executing a Tor-install variant from a remote endpoint preserves the same supply-chain and delivery-path risks as the base installer. In a skill that requests SSH/root access to a VPS, this is especially dangerous because compromise yields full control of an internet-facing host.
Privacy mode with Tor:
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --overlay tor
Using testnets (for trying things out without real money):
The Tor overlay example uses the same dangerous chaining pattern, where a remote response stream is fed straight to sudo bash. Because the skill is meant for autonomous or semi-automated setup on user infrastructure, this pattern materially increases the risk of supply-chain compromise turning into full-host takeover.
Privacy mode with Tor:
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --overlay tor
Using testnets (for trying things out without real money):
The testnet example still performs immediate execution of remote code, so the environment label does not materially lower the vulnerability. Attackers can exploit development or test infrastructure just as effectively, especially when it is exposed on a public VPS.
Using testnets (for trying things out without real money):
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --testnet
Flags can be combined:
This testnet installation still abuses command chaining by transforming downloaded bytes into root-executed commands in one shell pipeline. The 'testnet' context does not mitigate host-level compromise or subsequent abuse of the VPS.
Using testnets (for trying things out without real money):
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --testnet
Flags can be combined:
This combined-flags example normalizes a one-liner that both fetches and executes arbitrary remote code under elevated privileges. The convenience-focused presentation increases the chance users will run it without scrutiny, making the skill context more dangerous.
Flags can be combined:
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com --overlay tor --testnet
This final combined example is especially risky because it packages multiple options into a convenience one-liner that preserves the insecure retrieval-to-root-execution chain. In practice, such examples are likely to be copied verbatim, increasing the probability of unsafe deployment.
Flags can be combined:
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com --overlay tor --testnet
The document's primary installation pattern fetches a script from an external URL and executes it immediately, preventing inspection and bypassing integrity controls. In a server-deployment skill, this is particularly dangerous because a single upstream compromise can yield arbitrary root code execution on production VPS instances.
# Standalone Installer Flags Reference
Source: `curl -sSL https://get.mobazha.org/standalone | sudo bash [options]`
## Available Flags
The shell pipeline chains network retrieval directly into privileged execution, eliminating any opportunity for the user or tooling to validate the content in between. This chaining is dangerous because it amplifies any upstream compromise into immediate root-level code execution on the target host.
# Standalone Installer Flags Reference
Source: `curl -sSL https://get.mobazha.org/standalone | sudo bash [options]`
## Available Flags
This basic install example normalizes fetching executable content from the internet and running it instantly. Because the target is a self-hosted store on a Linux VPS, exploitation could lead to full takeover of the storefront, data theft, malware installation, and lateral movement from the server.
# Basic install — HTTP on IP
curl -sSL https://get.mobazha.org/standalone | sudo bash
# With domain — HTTPS auto-TLS
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com
This command uses a pipeline to stream remote script content straight into sudo bash, which is a classic chaining-abuse pattern. The danger is heightened in deployment documentation because users are likely to copy-paste it exactly, giving attackers a low-friction path to compromise servers if the source is tampered with.
# Basic install — HTTP on IP
curl -sSL https://get.mobazha.org/standalone | sudo bash
# With domain — HTTPS auto-TLS
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com
The domain-enabled example still executes unverified remote code from an external endpoint, with no integrity validation or provenance check. Since domain/TLS configuration is part of the install path, a malicious installer could also abuse certificate, DNS, or reverse-proxy setup to intercept traffic or persist control.
curl -sSL https://get.mobazha.org/standalone | sudo bash
# With domain — HTTPS auto-TLS
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com
# Privacy mode
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --overlay tor
The pipeline on this line still streams untrusted external content directly into a privileged shell. The presence of configuration flags does not mitigate the risk; instead, it encourages repeated reuse of the unsafe pattern across different deployment scenarios.
curl -sSL https://get.mobazha.org/standalone | sudo bash
# With domain — HTTPS auto-TLS
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com
# Privacy mode
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --overlay tor
This privacy mode example repeats the external-script execution pattern, exposing users to arbitrary code from the remote source. The context of configuring overlay networking can make host compromise harder to detect and easier for an attacker to hide once the installer is abused.
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com
# Privacy mode
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --overlay tor
# Combined
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com --overlay tor --testnet
This example continues to chain fetch and execution with root privileges, leaving no control point for integrity verification. Because it is part of a self-hosted infrastructure setup, a successful exploit can yield persistent compromise of a public-facing VPS and any associated service credentials.
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com
# Privacy mode
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --overlay tor
# Combined
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com --overlay tor --testnet
The combined example continues the unsafe pattern of executing a remote script directly from an external URL. Because this installation configures a public-facing commerce service, compromise can affect availability, customer data, wallet/payment integrations, and long-term server integrity.
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --overlay tor
# Combined
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com --overlay tor --testnet
# Custom install directory
INSTALL_DIR=/srv/mobazha curl -sSL https://get.mobazha.org/standalone | sudo bash
The combined install command preserves the chaining-abuse issue by piping remote content straight into a root shell. This is especially risky in a multi-option deployment example because it presents the unsafe pattern as the standard method for more complex, likely production-grade installs.
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --overlay tor
# Combined
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com --overlay tor --testnet
# Custom install directory
INSTALL_DIR=/srv/mobazha curl -sSL https://get.mobazha.org/standalone | sudo bash
This example combines an environment variable with immediate execution of a remotely fetched script, preserving the same supply-chain risk. If the external source is compromised, attackers gain arbitrary execution during installation and may exploit environment-driven behavior to place files or persistence in attacker-chosen locations.
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com --overlay tor --testnet
INSTALL_DIR=/srv/mobazha curl -sSL https://get.mobazha.org/standalone | sudo bash
## Post-Install Locations
This line combines environment-variable injection with a pipeline from remote fetch to privileged execution, increasing opacity and risk. The chained form makes it easy for attackers controlling the remote script to exploit both immediate execution and installer parameters for deeper host compromise.
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com --overlay tor --testnet
INSTALL_DIR=/srv/mobazha curl -sSL https://get.mobazha.org/standalone | sudo bash
## Post-Install Locations
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
## Prerequisites
- A Linux VPS (Ubuntu 22.04+ or Debian 12+) with 2+ CPU cores, 2+ GB RAM, 20+ GB SSD
- Root or sudo access
- (Optional) A domain name pointed to the VPS IP
### Recommended VPS Providers
The skill instructs users to download a remote script and execute it immediately with sudo via bash. This creates a direct remote-code-execution path as root if the upstream server, DNS, TLS trust chain, or script content is compromised, and the damage is amplified because the command is designed for unattended execution.
Zero-config (most common):
curl -sSL https://get.mobazha.org/standalone | sudo bash
With a pre-configured domain (enables auto-TLS via Let's Encrypt):
This variant still executes a remote script as root, only with a domain argument appended. User-supplied parameters do not reduce the underlying risk that arbitrary code from an external host is being run with full system privileges.
With a pre-configured domain (enables auto-TLS via Let's Encrypt):
curl -sSL https://get.mobazha.org/standalone | sudo bash -s -- --domain shop.example.com
Privacy mode with Tor:
No suspicious patterns detected.