T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:26- Finding
Mutable Remote Installation Script Executed Directly by Bash
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill’s purpose is coherent, but it recommends running mutable external code and optionally keeping a peer-sync server running persistently.
Review this before installing. Prefer downloading or cloning a pinned release, inspecting the installer, and verifying checksums or signatures before running anything. Do not enable the launchd service or peer auto-approval unless you understand what reports and node metadata will be reachable, have restricted network access, and know how to disable the service later.
SKILL.md:26Mutable Remote Installation Script Executed Directly by Bash
SKILL.md:125Persistent Auto-Restarting MYR Network Service
SKILL.md:40Unpinned Repository and npm Dependency Installation
The skill recommends executing a remote script directly with curl piped to bash without a strong warning or integrity-verification step. This is dangerous because any compromise of the upstream repository, network path, or referenced script would immediately lead to arbitrary code execution on the user's machine.
Piping curl output into bash is a classic command-chaining abuse pattern because it combines network retrieval with immediate execution in a single unreviewed step. This eliminates opportunities for integrity inspection and makes any upstream compromise translate directly into code execution.
curl -fsSL https://raw.githubusercontent.com/JordanGreenhall/myr-system/main/install.sh | bash
This clones the repo, installs dependencies, generates your keypair, prompts for a node ID, runs the five-command ping test, and adds MYR_HOME to your shell. Node is operational when it completes.
The trigger list contains very broad phrases such as "MYR", "what did we learn about", and "peer sync" that could match ordinary conversation and unintentionally activate this skill. Because the skill includes installation, networking, persistence, and data-sharing instructions, accidental invocation raises the chance of risky actions being suggested in unrelated contexts.
The live peer-sync section encourages exposing an HTTP service and sharing reports with peers, but does not prominently warn about the privacy and confidentiality implications of networked synchronization. Users may enable sharing without understanding that operational insights, metadata, node identity, and report contents could be disclosed to other systems.
The skill provides instructions to install the server as a persistent launchd agent, causing the network service to start automatically and remain resident. Persistence is security-relevant because it increases exposure duration and can leave a sharing service active beyond the user's immediate intent.
Create ~/Library/LaunchAgents/com.myr.server.plist:
<?xml version="1.0" encoding="UTF-8"?>
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
The explicit launchctl load command activates the persistent auto-start service, which means the HTTP sync server will continue running across sessions. In the context of a networked data-sharing service, this can unintentionally maintain exposure to remote peers and increase the window for misuse or attack.
mkdir -p $MYR_HOME/logs
launchctl load ~/Library/LaunchAgents/com.myr.server.plist
Verify:
The explicit launchctl load command activates the persistent auto-start service, which means the HTTP sync server will continue running across sessions. In the context of a networked data-sharing service, this can unintentionally maintain exposure to remote peers and increase the window for misuse or attack.
mkdir -p $MYR_HOME/logs
launchctl load ~/Library/LaunchAgents/com.myr.server.plist
Verify:
The skill introduces an auto-approve capability that allows the system to trust remote peers based on automated checks alone. Even with fingerprint consistency checks, this reduces human verification and can enable unintended trust relationships if discovery data, environment trust assumptions, or verification logic are flawed.
When adding a peer with `myr peer add --url <url>`, MYR fetches the peer's discovery document and sends an introduce request. In v1.2.0, the announce body includes `fingerprint`, `node_uuid`, and `protocol_version` fields for in-band verification.
### Auto-approve verified peers
Set `auto_approve_verified_peers: true` in your node config (`~/.myr/config.json` or `config.json`) to automatically trust peers that pass 3-way fingerprint verification:
This configuration guidance explicitly tells users to set auto_approve_verified_peers to true, enabling automated trust decisions for remote peers. In a networked synchronization system, automatic trust can expand the blast radius of verification mistakes or environmental compromise by admitting malicious or misidentified peers without operator review.
Set auto_approve_verified_peers: true in your node config (~/.myr/config.json or config.json) to automatically trust peers that pass 3-way fingerprint verification:
{
The JSON example operationalizes autonomous trust by giving a ready-to-copy configuration that enables peer auto-approval. Copy-pasteable insecure examples increase real-world adoption of risky defaults and make it more likely users will enable trust automation without understanding the consequences.
{
"auto_approve_verified_peers": true,
"auto_approve_min_protocol_version": "1.2.0"
}
The minimum protocol version field is presented as if version gating is sufficient for safe automatic approval, which may overstate the protection provided by protocol checks. A compliant or spoofed protocol version does not prove the peer is benign, so this can create false confidence in autonomous trust decisions.
{
"auto_approve_verified_peers": true,
"auto_approve_min_protocol_version": "1.2.0"
}
The documentation states that peers passing automated verification are immediately trusted, which is a direct autonomous authorization action. Immediate trust can permit report access or synchronization before a human validates the peer relationship, increasing the risk of unauthorized data exchange.
When enabled:
- Peers announcing with protocol version ≥ `auto_approve_min_protocol_version` (default `1.2.0`) that pass 3-way verification are immediately trusted.
- A reciprocal announce is sent automatically so both sides can establish trust in a single round-trip.
- The `auto_approved` flag is recorded in the peer record for audit.
The mention that an auto_approved flag is recorded for audit is not itself dangerous; it is an auditability feature rather than the risky behavior. The underlying concern is the auto-approval mechanism, not the existence of an audit field.
When enabled:
- Peers announcing with protocol version ≥ `auto_approve_min_protocol_version` (default `1.2.0`) that pass 3-way verification are immediately trusted.
- A reciprocal announce is sent automatically so both sides can establish trust in a single round-trip.
- The `auto_approved` flag is recorded in the peer record for audit.
**Security note:** Only enable auto-approve on nodes where you trust the network environment. On untrusted networks, keep manual approval (`auto_approve_verified_peers: false`, the default) and verify fingerprints out-of-band.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- A reciprocal announce is sent automatically so both sides can establish trust in a single round-trip.
- The `auto_approved` flag is recorded in the peer record for audit.
**Security note:** Only enable auto-approve on nodes where you trust the network environment. On untrusted networks, keep manual approval (`auto_approve_verified_peers: false`, the default) and verify fingerprints out-of-band.
---
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- A reciprocal announce is sent automatically so both sides can establish trust in a single round-trip.
- The `auto_approved` flag is recorded in the peer record for audit.
**Security note:** Only enable auto-approve on nodes where you trust the network environment. On untrusted networks, keep manual approval (`auto_approve_verified_peers: false`, the default) and verify fingerprints out-of-band.
---
Fetching and executing an external script directly from a remote URL delegates trust to mutable third-party content at runtime. If the script or hosting source is compromised, users would execute attacker-controlled code immediately with their local shell privileges.
curl -fsSL https://raw.githubusercontent.com/JordanGreenhall/myr-system/main/install.sh | bash
This clones the repo, installs dependencies, generates your keypair, prompts for a node ID, runs the five-command ping test, and adds MYR_HOME to your shell. Node is operational when it completes.
No suspicious patterns detected.