Red Alert (Israel)

• Outcome: Review
• Latest audit: Sep 11, 2026 · 3:13 AM UTC
• Version: 1.1.0

Overview

This emergency-alert skill is plausibly useful, but it asks for broad, persistent system access and credentials while contradicting its own OpenClaw-only claims.

Review carefully before installing. Use only in a test environment first, set all destinations explicitly, avoid entering broad Home Assistant tokens, inspect and remove any crontab entry after testing, and do not run the installer as root unless you have reviewed the Docker image and persistence behavior.

A.I.G

Vulnerability Patterns

• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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

Findings (5)

T09 · Insecure Skill Coding Practices

Error

• Location: oref_native.py:30
• Finding: Unsafe hardcoded external messaging and Home Assistant destinations<![CDATA[ ## Vulnerability Details **File Location**: `oref_native.py:30-31`, `oref_native.py:43-44`, `oref_native.py:125-130`, and `oref_native.py:175-183` **Vulnerability Type**: Unsafe hardcoded external destinations and sensitive-data transmission **Risk Level**: High ### Vulnerable Code ```python HA_URL = os.getenv("HASS_SERVER", "https://ha.right-api.com") HA_TOKEN = os.getenv("HASS_TOKEN", "") HA_TTS_SPEAKER = os.getenv("HA_TTS_SPEAKER", "media_player.home_assistant_voice_09a069_media_player") ``` ```python WHATSAPP_GROUP = os.getenv("WHATSAPP_GROUP_JID", "[e-mail]") WHATSAPP_OWNER = os.getenv("WHATSAPP_OWNER", "[phone]") ``` ```python def ha_tts(text: str): """הכרז קולית דרך רמקול Home Assistant""" try: r = requests.post( f"{HA_URL}/api/services/tts/google_translate_say", headers={"Authorization": f"Bearer {HA_TOKEN}", "Content-Type": "application/json"}, json={"entity_id": HA_TTS_SPEAKER, "message": text, "language": "iw"}, timeout=8 ) ``` ```python def dispatch(data: dict): current = data.get("current", {}) cat = str(current.get("cat", "1")) atype = ALERT_TYPES.get(cat, DEFAULT_TYPE) level = atype["level"] log.info(f"🚨 [{level}] Dispatching alert") wa_msg = build_message(data, atype) tts_text = atype["tts"] # 1️⃣ WhatsApp - קבוצת עדכונים בלבד if atype["whatsapp"]: openclaw_whatsapp(WHATSAPP_GROUP, wa_msg) # 3️⃣ רמקול HA - תמיד ha_tts(tts_text) ``` ### Technical Analysis The application uses a specific external Home Assistant domain, WhatsApp group JID, and personal telephone number as fallback values. The ownership or trustworthiness of these destinations cannot be established from the repository. When no explicit environment configuration is present, dispatched alerts are sent to the hardcoded WhatsApp group. Alert messages contain emergency type, timestamp, monitored ...[truncated 1767 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove all hardcoded personal telephone numbers, group JIDs, speaker identifiers, and external service domains. - Require `WHATSAPP_GROUP_JID` to be explicitly configured before enabling WhatsApp delivery. - Disable Home Assistant integration by default and invoke `ha_tts()` only when an explicit enable flag, URL, token, and speaker identifier are present. - Reject empty, malformed, or unexpected destinations at startup. - Consider an allowlist for Home Assistant hosts and require HTTPS for non-loopback destinations. - Display the configured recipients and endpoints and obtain explicit confirmation during installation. - Use a narrowly scoped Home Assistant token rather than an administrator token. - Remove the unused `WHATSAPP_OWNER` setting unless it is required by a documented feature. ]]>

T06 · System Persistence

Warning

• Location: install.sh:28
• Finding: Unconditional installation of reboot persistence<![CDATA[ ## Vulnerability Details **File Location**: `install.sh:28-34` and `install.sh:92-96` **Vulnerability Type**: Persistent Docker restart policy and crontab registration **Risk Level**: Medium ### Vulnerable Code ```bash if ! docker ps | grep -q oref-alerts; then docker run -d \ --name oref-alerts \ --restart unless-stopped \ -p 49000:9001 \ -e TZ="Asia/Jerusalem" \ dmatik/oref-alerts:latest ``` ```bash # ── 5. crontab ──────────────────────────────────── ENV_EXPORTS=$(cat "$ENV_FILE" | grep -v "^#" | tr '\n' ' ') CRON_CMD="@reboot $ENV_EXPORTS python3 $SCRIPT_DIR/oref_native.py >> $LOG_FILE 2>&1 &" (crontab -l 2>/dev/null | grep -v oref_native; echo "$CRON_CMD") | crontab - echo "✅ Added to crontab (auto-start on reboot)" ``` ### Technical Analysis The installer creates two persistent components without a separate opt-in decision: 1. The Docker proxy receives the `unless-stopped` restart policy. 2. The Python monitor is added to the current user's crontab with `@reboot`. Continuous operation is reasonably related to a real-time emergency alert monitor, and the persistence is disclosed in `README.md` and `SKILL.md`. It is therefore not covert persistence. However, installation is unconditional, uses two separate persistence mechanisms, and provides no uninstall procedure. This exceeds the minimum behavior needed for a one-time invocation and can surprise users who only intend to test the skill. The installer also immediately starts the monitor using `nohup`, so a failed or incomplete cleanup can leave both a current process and reboot persistence. ### Attack Path 1. The user runs `bash install.sh`. 2. Docker creates the proxy with an automatic restart policy. 3. The script starts `oref_native.py` in the background. 4. The installer rewrites the user's crontab and adds an `@reboot` command. 5. After a reboot, the Docker proxy and monitor resume without further user interaction. 6. The monitor continues ...[truncated 753 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Ask for explicit confirmation before creating any reboot persistence. - Provide installation modes such as `--run-once`, `--no-persistence`, and `--enable-service`. - Prefer one managed service mechanism rather than combining `nohup`, cron, and Docker restart behavior. - Run the monitor under a dedicated unprivileged service account. - If a service manager is used, apply filesystem, network, process, and capability restrictions. - Provide an uninstall command that removes the cron entry, stops the process, removes the container, and deletes generated secrets and logs if requested. - Clearly display all persistence changes before applying them. - Avoid recommending execution as root unless a specific operation requires it. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: install.sh:45
• Finding: Arbitrary command execution through unsafe environment-file sourcing<![CDATA[ ## Vulnerability Details **File Location**: `install.sh:45-68` and `install.sh:78-79` **Vulnerability Type**: Shell command injection through executable configuration **Risk Level**: High ### Vulnerable Code ```bash read -p "📍 Monitored areas (comma separated, e.g. הרצליה,תל אביב): " AREAS read -p "📱 WhatsApp group JID (e.g. [e-mail]): " WA_GROUP read -p "📞 3CX extension to call on alert (e.g. 12610, leave empty to disable): " CX3_EXT read -p "🔑 Home Assistant URL (leave empty to disable): " HA_URL read -p "🔑 Home Assistant Token (leave empty to disable): " HA_TOKEN CX3_ENABLED="false" [ -n "$CX3_EXT" ] && CX3_ENABLED="true" cat > "$ENV_FILE" << EOF OREF_API_URL=http://localhost:49000/current OREF_POLL_INTERVAL=5 OREF_COOLDOWN=60 MONITORED_AREAS=$AREAS WHATSAPP_GROUP_JID=$WA_GROUP CX3_API=http://localhost:3000/api/outbound-call CX3_EXTENSION=$CX3_EXT CX3_ENABLED=$CX3_ENABLED HASS_SERVER=$HA_URL HASS_TOKEN=$HA_TOKEN HA_TTS_SPEAKER=media_player.home_assistant_voice_09a069_media_player EOF ``` ```bash source "$ENV_FILE" export $(cat "$ENV_FILE" | grep -v "^#" | xargs) ``` ### Technical Analysis Interactive values are written into `.env` without shell escaping or field validation. The installer later treats that data file as executable shell syntax by using `source`. An input containing command substitution, shell separators, redirections, or additional assignments is stored in `.env`. On the next `source "$ENV_FILE"` operation, the shell parses and executes that content. For example, a value containing `$(id)` or `$(arbitrary-command)` is evaluated when the file is sourced. The subsequent `export $(cat ... | xargs)` operation is also unsafe. It performs word splitting, destroys spaces in values such as monitored-area names, and treats generated words as shell arguments. Although `source` is the primary arbitrary-execution sink, the export pipeline further weakens configuration integrity. Exploitation requires control of an installer p ...[truncated 1292 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Never execute a data configuration file with `source`. - Parse only an explicit allowlist of recognized keys. - Validate each value according to its expected type: - Numeric bounds for polling and cooldown values. - Strict JID format for WhatsApp groups. - URL parsing and allowed schemes for API endpoints. - Numeric or otherwise documented format for extensions. - Store configuration in JSON, TOML, or another format that is not executable shell syntax. - Pass an explicit environment mapping to the Python process instead of constructing shell commands. - If shell-compatible output is unavoidable, escape every value with a robust mechanism such as `printf '%q'`; do not rely on ad hoc quoting. - Remove the `export $(cat ... | xargs)` pattern. - Set restrictive permissions on configuration files containing credentials, such as mode `0600`. - Refuse to use a configuration file that is writable by unauthorized users. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: install.sh:93
• Finding: Home Assistant token and other configuration secrets copied into crontab<![CDATA[ ## Vulnerability Details **File Location**: `install.sh:58-68` and `install.sh:93-95` **Vulnerability Type**: Plaintext credential exposure in persistent command text **Risk Level**: High ### Vulnerable Code ```bash cat > "$ENV_FILE" << EOF OREF_API_URL=http://localhost:49000/current OREF_POLL_INTERVAL=5 OREF_COOLDOWN=60 MONITORED_AREAS=$AREAS WHATSAPP_GROUP_JID=$WA_GROUP CX3_API=http://localhost:3000/api/outbound-call CX3_EXTENSION=$CX3_EXT CX3_ENABLED=$CX3_ENABLED HASS_SERVER=$HA_URL HASS_TOKEN=$HA_TOKEN HA_TTS_SPEAKER=media_player.home_assistant_voice_09a069_media_player EOF ``` ```bash ENV_EXPORTS=$(cat "$ENV_FILE" | grep -v "^#" | tr '\n' ' ') CRON_CMD="@reboot $ENV_EXPORTS python3 $SCRIPT_DIR/oref_native.py >> $LOG_FILE 2>&1 &" (crontab -l 2>/dev/null | grep -v oref_native; echo "$CRON_CMD") | crontab - ``` ### Technical Analysis The installer reads every non-comment line from `.env`, joins the contents into one string, and embeds the result directly into the cron command. Consequently, `HASS_TOKEN` and any other sensitive configuration are stored in plaintext within the crontab. When the cron job runs, these values may also appear as part of the shell command line, depending on the cron and process implementation. Command lines are commonly exposed through process-inspection and diagnostic tools. The `.env` file itself is also created without an explicit restrictive `umask` or `chmod`. Embedding credentials in executable command text unnecessarily increases the number of locations from which secrets can be recovered and complicates token rotation. ### Attack Path 1. The user enters a Home Assistant token during installation. 2. The installer writes the token to `.env`. 3. `ENV_EXPORTS` incorporates the full token. 4. `CRON_CMD` places the token directly into the persistent crontab entry. 5. A user or process able to inspect the crontab, process metadata, backups, diagnostics, or copied deployment output obtains the token. 6. The recover ...[truncated 631 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not embed credentials or complete environment files into cron command strings. - Store secrets in a dedicated file readable only by the service account, with mode `0600`. - Prefer a service manager that supports protected environment files or integration with a secret manager. - Keep non-secret configuration separate from authentication credentials. - Ensure the generated configuration directory and files are not group- or world-writable. - Rotate any Home Assistant token that has already been written into an exposed crontab. - Provide a token-rotation procedure that updates only the protected secret store. - Minimize Home Assistant token permissions to the functionality strictly required for TTS. ]]>

T08 · Insecure Dependencies

Warning

• Location: install.sh:18
• Finding: Unpinned Python packages and mutable Docker image are executed during installation<![CDATA[ ## Vulnerability Details **File Location**: `install.sh:18-34` **Vulnerability Type**: Unsafe and non-reproducible third-party dependency installation **Risk Level**: Medium ### Vulnerable Code ```bash echo "📦 Checking dependencies..." command -v python3 >/dev/null || { echo "❌ python3 required"; exit 1; } command -v openclaw >/dev/null || { echo "❌ openclaw required"; exit 1; } pip3 install requests gtts 2>/dev/null | tail -1 echo "✅ Dependencies OK" # ── 2. הגדרת oref-alerts Docker proxy ──────────── echo "" echo "🐳 Starting oref-alerts API proxy..." if ! docker ps | grep -q oref-alerts; then docker run -d \ --name oref-alerts \ --restart unless-stopped \ -p 49000:9001 \ -e TZ="Asia/Jerusalem" \ dmatik/oref-alerts:latest ``` ### Technical Analysis The installer downloads Python dependencies without pinned versions or integrity hashes and starts a Docker image through the mutable `latest` tag. The effective third-party code can therefore change after this repository has been reviewed. Package installation may execute package build or installation logic with the privileges of the installer. Pulling `latest` similarly delegates future execution to whichever image the registry serves under that tag. A compromised upstream account, registry, release process, or dependency version could introduce arbitrary behavior. The included Python script imports `requests` but does not import `gtts`, making `gtts` an unnecessary dependency and avoidable expansion of the supply-chain attack surface. Error output from `pip3` is also suppressed, reducing diagnostic visibility. ### Attack Path 1. An upstream package account, Docker repository, registry, or release pipeline is compromised, or a future release becomes malicious. 2. A user runs `install.sh` after the upstream artifact has changed. 3. `pip3` downloads and installs the current unpinned package releases. 4. Docker obtains the image currently associated with ...[truncated 842 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove `gtts` unless the application actually requires it. - Pin Python dependencies to reviewed versions in a requirements file. - Use hashes with `pip --require-hashes` for reproducible dependency verification. - Install dependencies into a dedicated virtual environment instead of the global Python environment. - Pin the Docker image by an immutable digest rather than `latest`. - Document the image source, expected digest, update process, and review procedure. - Avoid suppressing installation errors; preserve enough output for security review and troubleshooting. - Consider vulnerability scanning and signature verification for the selected container image. - Perform dependency updates through an explicit, reviewed process rather than automatically accepting the newest upstream artifacts. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Rogue Agent: Self-Modification, Session Persistence
• Taint Tracking: Direct Taint Flow, Variable-Mediated Taint Flow, Credential Exfiltration Chain

Findings (34)

Tainted flow: 'CX3_API' from os.getenv (line 35, credential/environment) → requests.post (network output)

Critical

• Category: Data Flow

Content

def cx3_call(text: str):
    """חייג לשלוחה 3CX עם הודעת התרעה"""
    try:
        r = requests.post(CX3_API,
            json={"to": CX3_EXTENSION, "message": text, "language": "he"},
            timeout=10)
        if r.status_code == 200:

• Confidence: 90% confidence
• Finding: Credentials or environment variables flow to a network sink. This is a high-confidence indicator of credential exfiltration.

Tainted flow: 'HA_URL' from os.getenv (line 30, credential/environment) → requests.post (network output)

Critical

• Category: Data Flow

Content

def ha_tts(text: str):
    """הכרז קולית דרך רמקול Home Assistant"""
    try:
        r = requests.post(
            f"{HA_URL}/api/services/tts/google_translate_say",
            headers={"Authorization": f"Bearer {HA_TOKEN}", "Content-Type": "application/json"},
            json={"entity_id": HA_TTS_SPEAKER, "message": text, "language": "iw"},

• Confidence: 90% confidence
• Finding: HA_URL is fully configurable and the code sends the Home Assistant bearer token in the Authorization header to whatever endpoint that variable specifies. If an attacker can influence the environment or deployment config, they can redirect this request to an attacker-controlled server and exfiltrate the long-lived token, enabling unauthorized control of the Home Assistant instance.

Tainted flow: 'OREF_API' from os.getenv (line 24, credential/environment) → requests.get (network output)

Critical

• Category: Data Flow

Content

def check_alert():
    global last_alert_id, alert_sent_at, all_clear_sent
    try:
        data = requests.get(OREF_API, timeout=5).json()
    except Exception as e:
        log.warning(f"⚠️ API: {e}")
        return

• Confidence: 90% confidence
• Finding: Credentials or environment variables flow to a network sink. This is a high-confidence indicator of credential exfiltration.

External Script Fetching

High

• Category: Supply Chain

Content

bash install.sh

# Test API
curl -s http://localhost:49000/current | python3 -m json.tool

# Test 3CX call manually
curl -X POST http://localhost:3000/api/outbound-call \

• Confidence: 90% confidence
• Finding: Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 99% confidence
• Finding: This second mismatch finding reinforces that the skill claims to be OpenClaw-only while static analysis indicates Home Assistant-backed TTS, additional call-routing capability, and daemonized monitoring behavior. Misrepresentation of runtime behavior increases the chance of unsafe deployment, especially where external systems, credentials, and always-on execution are involved.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: This second mismatch finding reinforces that the skill claims to be OpenClaw-only while static analysis indicates Home Assistant-backed TTS, additional call-routing capability, and daemonized monitoring behavior. Misrepresentation of runtime behavior increases the chance of unsafe deployment, especially where external systems, credentials, and always-on execution are involved.

Credential Access

High

• Category: Privilege Escalation

Content

set -e

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
ENV_FILE="$SCRIPT_DIR/.env"
LOG_FILE="/var/log/oref_native.log"

echo "🚨 ORef Alerts - OpenClaw Native Installer"

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Description-Behavior Mismatch

High

• Confidence: 99% confidence
• Finding: The skill metadata says 'No Docker monitor,' yet the installer starts and manages a Docker container. This mismatch is a trust and transparency problem: users may approve the skill under false assumptions, while the installer introduces additional runtime code, network exposure, and supply-chain risk not disclosed in the manifest.

Description-Behavior Mismatch

High

• Confidence: 99% confidence
• Finding: The manifest claims 'No Home Assistant,' but the installer prompts for a Home Assistant URL and token and stores them for later use. This undisclosed expansion of scope is dangerous because it solicits sensitive credentials and creates an integration path to another trusted system the user may not expect this skill to access.

Intent-Code Divergence

High

• Confidence: 99% confidence
• Finding: The documentation states that OpenClaw TTS is used, but the implementation actually performs TTS through Home Assistant with a bearer token. Misleading documentation about which component handles voice announcements can cause unsafe deployment decisions, hidden secret provisioning, and underestimation of external trust dependencies.

Description-Behavior Mismatch

High

• Confidence: 98% confidence
• Finding: The skill metadata and module comments claim there is no Home Assistant dependency, yet the code uses Home Assistant for TTS and transmits a bearer token to that service. This discrepancy is security-relevant because operators may deploy the skill under false assumptions about network exposure, secret usage, and required trust boundaries.

Description-Behavior Mismatch

Medium

• Confidence: 96% confidence
• Finding: The top-level description presents the skill as fully OpenClaw-native with no Home Assistant involvement. Elsewhere in the same file, the architecture and configuration explicitly include optional Home Assistant TTS and a Docker-based ORef proxy, so the stated scope is materially broader than the description suggests.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: This is an active contradiction within the documentation, not merely an omission. The introductory claim conflicts with the architecture and configuration sections that explicitly describe Home Assistant TTS and 3CX call integrations.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The README describes automatic WhatsApp group messaging and outbound phone calls for alerts without an explicit caution that test or live configuration may contact real recipients. In an alerting skill, this increases the risk of accidental disruptive notifications, nuisance calls, or panic if a user follows setup steps without understanding the external effects.

External Transmission

Medium

• Category: Data Exfiltration

Content

curl -s http://localhost:49000/current | python3 -m json.tool

# Test 3CX call manually
curl -X POST http://localhost:3000/api/outbound-call \
  -H "Content-Type: application/json" \
  -d '{"to":"12610","message":"בדיקת מערכת התרעות","language":"he"}'
```

• Confidence: 86% confidence
• Finding: The manual test command triggers an outbound call through a local 3CX API endpoint, which can contact a real extension with spoken content. In this skill's context, that creates a real-world notification channel that can be abused or triggered accidentally, causing disruption, harassment, or unintended alerting even though the endpoint shown is localhost.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 88% confidence
• Finding: The skill advertises operational behavior that clearly requires powerful capabilities (environment access, network access, and shell/process execution) but does not declare any tool scope or permission boundaries. In an agent ecosystem, missing scope declarations weaken reviewability and least-privilege enforcement, making it easier for a skill to run with broader privileges than users expect.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The skill routes alerts to a WhatsApp group and speaks them aloud, but the description does not prominently warn users about these disclosure channels. That omission can cause unintended exposure of sensitive location or emergency-status information to group members or anyone within hearing range.

Session Persistence

Medium

• Category: Rogue Agent

Content

```bash
# Install cron (every 5 seconds via loop)
nohup python3 /root/.openclaw/workspace/skills/oref-native/oref_native.py \
  >> /var/log/oref_native.log 2>&1 &

# Or add to crontab (restart on boot)

• Confidence: 91% confidence
• Finding: The setup instructions recommend background execution with nohup and persistence at boot via crontab @reboot, establishing a continuously running process outside normal interactive control. Persistence is security-relevant because it survives reboots, can evade casual visibility, and expands the blast radius if the monitored script is modified or compromised later.

Intent-Code Divergence

Medium

• Confidence: 98% confidence
• Finding: The header explicitly says 'no Home Assistant needed' while the script later collects and stores Home Assistant credentials. Contradictory messaging reduces informed consent and can socially engineer users into entering secrets under the belief that the integration is unnecessary or dormant.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 96% confidence
• Finding: The installer pulls and runs dmatik/oref-alerts:latest without pinning a specific version or image digest, which makes the deployed code mutable over time and vulnerable to upstream supply-chain compromise. In an installer context, this is especially risky because the container is started automatically and exposed on a host port, so a malicious or compromised future image would execute immediately on the user's system.

Missing User Warnings

Medium

• Confidence: 98% confidence
• Finding: The installer collects a Home Assistant token and writes it to a plaintext .env file in the skill directory without warning, permission hardening, or secure secret handling. If local users, backups, logs, or other processes can read that file, the token could be stolen and used to control or query the user's Home Assistant environment.

Session Persistence

Medium

• Category: Rogue Agent

Content

source "$ENV_FILE"
export $(cat "$ENV_FILE" | grep -v "^#" | xargs)

nohup python3 "$SCRIPT_DIR/oref_native.py" >> "$LOG_FILE" 2>&1 &
PID=$!
sleep 2

• Confidence: 65% confidence
• Finding: 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.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The installer silently modifies the user's crontab to achieve persistence on reboot without an explicit confirmation step. Persistence is sensitive behavior because it creates long-term execution of the skill, increases blast radius if the script is later modified, and may violate user expectations for a one-time installer.

Session Persistence

Medium

• Category: Rogue Agent

Content

# ── 5. crontab ────────────────────────────────────
ENV_EXPORTS=$(cat "$ENV_FILE" | grep -v "^#" | tr '\n' ' ')
CRON_CMD="@reboot $ENV_EXPORTS python3 $SCRIPT_DIR/oref_native.py >> $LOG_FILE 2>&1 &"
(crontab -l 2>/dev/null | grep -v oref_native; echo "$CRON_CMD") | crontab -
echo "✅ Added to crontab (auto-start on reboot)"

echo ""

• Confidence: 97% confidence
• Finding: Adding an @reboot cron entry establishes persistent execution across reboots. In the context of an installer, persistence is not automatically malicious, but it is security-relevant because it ensures future code execution without further user action and can be abused if the script or its environment is tampered with later.

Description-Behavior Mismatch

Medium

• Confidence: 87% confidence
• Finding: The stated purpose is an OpenClaw-native Home Front Command alert skill focused on WhatsApp and TTS. Introducing a separate 3CX outbound-calling integration expands behavior beyond the manifest description, which emphasizes removing auxiliary components rather than adding telephony integrations.

Static analysis

No suspicious patterns detected.