Back to skill

Security audit

Android Node

Security checks for vulnerabilities and agentic risk

Overview

The skill appears purpose-aligned, but its install and network setup require careful review before use.

Review this skill before installing. Avoid the remote curl-to-bash flow; use only inspected local setup code, verify downloaded binaries, and run the phone node only on a trusted isolated network. Do not send sensitive prompts unless traffic is protected by an authenticated encrypted channel or trusted overlay network.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Findings (4)

T03 · Remote Payload Retrieval and Execution

Error
Location
SKILL.md:18
Finding
Unverified Remote Installation Script Is Piped Directly to Bash<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:18-22`; `setup.sh:5-6` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: Critical ### Vulnerable Code `SKILL.md:18-22`: ```bash ### On the phone (run in Termux) ```bash curl -s https://albionwakes.com/phone_setup.sh | bash bash ~/start_node.sh ``` ``` `setup.sh:5-6`: ```bash # Usage: paste this URL in Termux browser, or: # curl -s http://albionwakes.com/phone_setup.sh | bash ``` ### Technical Analysis The documented installation process downloads shell source from `albionwakes.com` and streams it directly into Bash. The payload is neither pinned to a specific release nor checked against a cryptographic signature or checksum. Consequently, the code executed by users can differ from the bundled and audited `setup.sh`. The packaged script also advertises an HTTP version of this command. Although that occurrence is a comment containing usage instructions rather than code executed automatically, users following it would receive no transport authentication or integrity protection. A network-positioned attacker could replace the response before Bash processes it. This behavior is not required to provision the node: the repository already contains a local setup script that can be inspected before execution. ### Attack Path 1. A user follows the installation command from `SKILL.md` or the usage comment in `setup.sh`. 2. An attacker compromises the hosting domain, DNS, web server, deployment account, or network path. Plain HTTP additionally permits direct in-transit modification. 3. The attacker replaces `phone_setup.sh` with arbitrary shell commands. 4. `curl` streams the attacker-controlled response directly into Bash. 5. The payload executes immediately with the permissions of the Termux user. ### Impact Assessment An attacker can execute arbitrary commands in the Termux environment and access everything available to that application user. Potential impact incl ...[truncated 538 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove all `curl | bash` and `wget | shell` installation instructions. 2. Prefer executing the packaged, reviewable script: ```bash bash ./setup.sh ``` 3. If downloading is unavoidable: - Publish immutable, versioned release artifacts. - Require HTTPS. - Download the script to a file rather than piping it into a shell. - Publish and verify a SHA-256 digest or cryptographic signature before execution. - Display the source and require an explicit user action before running it. 4. Remove the plain-HTTP URL from `setup.sh`. 5. Ensure the documentation refers to exactly the same version of the script that was audited. 6. Configure downloads to fail visibly and securely, such as with `curl --fail --show-error --location`. ]]>

T08 · Insecure Dependencies

Error
Location
setup.sh:15
Finding
Mutable Ollama Executable Is Downloaded and Run Without Integrity Verification<![CDATA[ ## Vulnerability Details **File Location**: `setup.sh:15-25`, `setup.sh:33-34` **Vulnerability Type**: Unsafe third-party executable dependency **Risk Level**: High ### Vulnerable Code `setup.sh:15-25`: ```bash ARCH=$(uname -m) if [ "$ARCH" = "aarch64" ]; then OLLAMA_URL="https://github.com/ollama/ollama/releases/latest/download/ollama-linux-arm64" else OLLAMA_URL="https://github.com/ollama/ollama/releases/latest/download/ollama-linux-amd64" fi mkdir -p $HOME/bin wget -q -O $HOME/bin/ollama "$OLLAMA_URL" chmod +x $HOME/bin/ollama export PATH="$HOME/bin:$PATH" ``` `setup.sh:33-34`: ```bash echo "Pulling default model (qwen2.5:0.5b — 394MB)..." $HOME/bin/ollama pull qwen2.5:0.5b ``` The same downloaded executable is later launched by the generated `start_node.sh`: ```bash ollama serve ``` ### Technical Analysis The installer obtains a native executable through a mutable `releases/latest` URL, marks it executable, and subsequently runs it. HTTPS protects the ordinary network connection, but the script does not verify an expected artifact digest or trusted release signature. Because `latest` can resolve to a different binary over time, the effective executable is not the specific artifact reviewed when the Skill was audited. A compromised upstream repository, release-publishing account, release asset, or delivery chain could therefore turn setup into arbitrary native-code execution. The architecture logic also treats every architecture other than `aarch64` as AMD64. This is primarily a reliability issue, but explicit allowlisting would produce safer failure behavior. ### Attack Path 1. An attacker compromises the upstream project, its release credentials, or the release artifact distribution path. 2. The mutable `latest` release URL resolves to an attacker-controlled executable. 3. `wget` writes the executable to `$HOME/bin/ollama`. 4. The installer applies executable permission without verifying a checksum or signature. 5. The inst ...[truncated 847 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin a specific, reviewed Ollama release instead of using `releases/latest`. 2. Maintain an architecture-specific allowlist and fail for unsupported architectures. 3. Publish expected SHA-256 hashes in the repository and verify the downloaded artifact before making it executable: ```bash echo "$EXPECTED_SHA256 $HOME/bin/ollama" | sha256sum -c - ``` 4. Prefer a trusted cryptographic release signature when supported, and validate it against a pinned signing key. 5. Abort installation on any download, signature, or digest failure. 6. Download to a temporary file with restrictive permissions and atomically move it into `$HOME/bin` only after successful verification. 7. Record the installed version and verified digest so users can audit and reproduce the installation. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
setup.sh:38
Finding
Ollama Service Is Exposed on All Interfaces Without Access Controls<![CDATA[ ## Vulnerability Details **File Location**: `setup.sh:38-44` **Vulnerability Type**: Unauthenticated network service exposure **Risk Level**: High ### Vulnerable Code ```bash # Write a startup script cat > $HOME/start_node.sh << 'EOF' #!/data/data/com.termux/files/usr/bin/bash export PATH="$HOME/bin:$PATH" export OLLAMA_HOST=0.0.0.0:11434 echo "Starting Ollama node on port 11434..." ollama serve EOF ``` ### Technical Analysis `OLLAMA_HOST=0.0.0.0:11434` binds the Ollama service to every available IPv4 interface. The configuration provides no authentication, TLS, source allowlist, firewall rule, or authenticated reverse proxy. LAN accessibility is part of the declared node functionality, but exposing the service on all interfaces is broader than the minimum necessary. Its actual reachability depends on Android, Termux, router, and firewall configuration, but any host capable of reaching port 11434 can attempt to use the API. ### Attack Path 1. The user launches `~/start_node.sh`. 2. Ollama listens on port 11434 across all available interfaces. 3. An attacker on the same Wi-Fi network—or another network with a route or forwarded port to the phone—discovers the open service. 4. The attacker sends requests directly to Ollama's unauthenticated API. 5. The attacker consumes inference resources, enumerates exposed API information, or invokes other operations supported by the installed Ollama version. ### Impact Assessment A reachable attacker may: - Consume phone CPU, memory, battery, and thermal capacity through inference requests. - Cause denial of service or degraded availability for legitimate jobs. - Query available API endpoints and models. - Submit attacker-selected prompts or workloads. - Exploit any separate vulnerability present in the exposed Ollama version. This finding exposes the Ollama service rather than the Android operating system directly. The ultimate process privileges are those of Termux, while network abuse is limited to fu ...[truncated 76 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Place the node behind an authenticated and encrypted overlay network such as WireGuard or Tailscale. 2. Where possible, bind only to a specifically trusted interface or address rather than `0.0.0.0`. 3. Add an authenticated reverse proxy in front of Ollama and reject unauthenticated requests. 4. Use host or network firewall rules to allow only the intended server's IP address. 5. Do not expose port 11434 through router port forwarding or public Wi-Fi. 6. Add request limits, concurrency limits, and monitoring to reduce resource-exhaustion risk. 7. Clearly document that the service has no built-in trust boundary in the current configuration and must only be used on an isolated network. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
phone_nodes.py:76
Finding
Inference Prompts and Responses Are Transmitted Over Plaintext HTTP<![CDATA[ ## Vulnerability Details **File Location**: `phone_nodes.py:76-85`, `phone_nodes.py:96-100` **Vulnerability Type**: Plaintext transmission of potentially sensitive inference data **Risk Level**: Medium ### Vulnerable Code `phone_nodes.py:76-85`: ```python try: r = requests.post(url, json={ 'model': model, 'messages': msgs, 'stream': False, 'options': {'temperature': 0.7, 'num_predict': 1024}, }, timeout=CALL_TIMEOUT) r.raise_for_status() return r.json()['message']['content'].strip() except Exception as e: with _lock: _healthy[node['url']] = False ``` `phone_nodes.py:96-100`: ```python def register(name: str, ip: str, model: str = 'qwen2.5:0.5b', port: int = 11434): """Add or update a phone node in the registry.""" nodes = _load_nodes() url = f'http://{ip}:{port}' existing = next((n for n in nodes if n['url'] == url), None) ``` The request target is formed earlier from the registered plaintext URL: ```python url = node['url'] + '/api/chat' ``` ### Technical Analysis Every registered node URL is constructed with the `http://` scheme. The `call` function then sends the complete message list—including user messages and an optional system override—to the node without transport encryption or server authentication. An attacker with visibility or control over the local network path can inspect prompts and responses. An active attacker can also impersonate the phone node, alter responses, or redirect traffic through network-level mechanisms such as ARP spoofing, rogue access points, or DNS/routing manipulation where applicable. Because the module accepts arbitrary registered IP values and does not authenticate the endpoint, the server also has no cryptographic assurance that it is communicating with the intended phone. ### Attack Path 1. A phone node is registered, creating an `http://<ip>:11434` endpoint. 2. The router calls `phone_nodes.call()` with conversation messages. 3. The mo ...[truncated 915 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Add HTTPS support and require certificate verification. 2. Use certificates or public keys pinned to each registered node where practical. 3. Alternatively, carry all traffic over an authenticated encrypted network such as WireGuard or Tailscale. 4. Add node authentication, such as mutually authenticated TLS or a securely provisioned API credential. 5. Reject plaintext HTTP by default; require an explicit, documented insecure-development option if legacy LAN operation must remain available. 6. Avoid sending secrets or highly sensitive data until authenticated encryption is enabled. 7. Validate registered endpoints and present a clear warning when a plaintext URL is configured. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • YARA SignaturesMalware Match, Webshell Match, Cryptominer Match
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (11)

External Script Fetching

High
Category
Supply Chain
Content
### On the phone (run in Termux)
```bash
curl -s https://albionwakes.com/phone_setup.sh | bash
bash ~/start_node.sh
```
Confidence
99% confidence
Finding
Fetching and executing an external script from albionwakes.com creates a supply-chain risk: if the server, DNS, TLS termination, or hosting account is compromised, arbitrary code will run on the target phone. Because the phone is being turned into a network-reachable inference worker, compromise could also be used to pivot into the local Wi‑Fi environment or tamper with model-serving behavior.

Chaining Abuse

High
Category
Tool Misuse
Content
### On the phone (run in Termux)
```bash
curl -s https://albionwakes.com/phone_setup.sh | bash
bash ~/start_node.sh
```
Confidence
99% confidence
Finding
The use of '| bash' is a classic command-chaining anti-pattern that removes any opportunity for the user or tooling to inspect the downloaded content before execution. This makes transient compromise especially dangerous, since a single modified response from the remote endpoint results in immediate arbitrary shell execution.

External Script Fetching

High
Category
Supply Chain
Content
# After this runs, Pi can route inference jobs to this phone.
#
# Usage: paste this URL in Termux browser, or:
#   curl -s http://albionwakes.com/phone_setup.sh | bash

set -e
Confidence
98% confidence
Finding
The usage line fetches a script from a remote domain and executes it immediately in the shell, which is a classic arbitrary code execution risk. The danger is increased because the URL uses plain HTTP rather than HTTPS, allowing tampering in transit as well as server-side compromise to deliver malicious code.

Chaining Abuse

High
Category
Tool Misuse
Content
# After this runs, Pi can route inference jobs to this phone.
#
# Usage: paste this URL in Termux browser, or:
#   curl -s http://albionwakes.com/phone_setup.sh | bash

set -e
Confidence
97% confidence
Finding
Piping network-fetched content directly into bash bypasses review and turns any upstream compromise or network interception into immediate shell execution. Because this setup script performs installation and persistence-related actions, the resulting blast radius on the device is substantial.

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

High
Category
YARA Match
Content
"aarch64" ]; then
    OLLAMA_URL="https://github.com/ollama/ollama/releases/latest/download/ollama-linux-arm64"
else
    OLLAMA_URL="https://github.com/ollama/ollama/releases/latest/download/ollama-linux-amd64"
fi

mkdir -p $HOME/bin
wget -q -O $HOME/bin/ollama "$OLLAMA_URL"
chmod +x $HOME/bin/ollama
export PATH="$HOME/bin:$PATH"

# Persist PATH
grep -q 'albion-node' $HOME/.bashrc 2>/dev/null || echo '# albion-node' >> $HOME/.bashrc
grep -q '$HOME/bin' $HOME/.bashrc 2>/dev/null || echo 'export PATH="$HOME/bin:$PATH"' >> $HOME/.bashrc

echo "Pulling default model (qwen2.5:0.5b — 394MB)..."
$HOME/bin/ollama pull qwen2.5:0.5b

# Write a startup script
cat > $HOME/start_node.sh << 'EOF'
#!/data/data/com.termux/files/usr/bin/bash
export PATH="$HOME/bin:$PATH"
export OLLAMA_HOST=0.0.0.0:11434
echo "Starting Ollama node on port 11434..."
ollama serve
EOF
chmod +x $HOME/start_node.sh

echo ""
echo "=== Done ==="
echo ""
echo "To start the node:"
echo "  bash ~/start_node.sh"
echo ""
echo "T
Confidence
75% confidence
Finding
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).

Missing User Warnings

Medium
Confidence
98% confidence
Finding
The skill instructs users to execute a remotely hosted shell script directly via curl-to-bash, which gives the remote server immediate code execution on the Android Termux environment without inspection, pinning, or integrity verification. In this context, the script provisions an inference node and could install backdoors, exfiltrate local data, or expose the device and adjacent network resources.

External Transmission

Medium
Category
Data Exfiltration
Content
if system_override:
            msgs = [{'role': 'system', 'content': system_override}] + [m for m in msgs if m.get('role') != 'system']
        try:
            r = requests.post(url, json={
                'model': model, 'messages': msgs, 'stream': False,
                'options': {'temperature': 0.7, 'num_predict': 1024},
            }, timeout=CALL_TIMEOUT)
Confidence
92% confidence
Finding
The module sends full chat messages to arbitrary URLs stored in the local node registry over plain HTTP, with no authentication, encryption, or trust validation of the destination. If an attacker can modify the registry, control the network, or register a malicious node, they can intercept sensitive prompts/responses or impersonate a healthy inference endpoint.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The code sends the full `messages` payload, and optionally a system override, over HTTP to configured phone nodes via `requests.post`. While network transmission is core functionality here, this file provides no user-facing warning in comments, docstrings, or logs that conversational content will be sent to external devices on the local network.

Intent-Code Divergence

Medium
Confidence
95% confidence
Finding
The script explicitly instructs users to execute a remotely hosted script directly via curl-to-bash, eliminating any opportunity to inspect the content before execution. In this context, that remote script performs package installation, downloads a binary, alters shell startup files, and prepares a network-reachable service, so compromise of the hosting site or traffic path could immediately lead to arbitrary code execution on the device.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The script downloads and runs substantial third-party software, pulls a model, and creates a startup script that binds the service to 0.0.0.0, making it network-accessible, yet provides no meaningful safety warning about exposure or trust assumptions. In a mobile/Termux context, exposing a local inference service to the network can unintentionally widen the attack surface and enable unauthorized access from the local network.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
The script silently appends PATH changes to ~/.bashrc, creating persistent environment modification without clear prior consent. While not inherently malicious here, silent persistence reduces transparency and can have unintended side effects or normalize unsafe installation behavior.

Static analysis

No suspicious patterns detected.