mwcHorus

• Outcome: Review
• Latest audit: Sep 11, 2026 · 6:52 AM UTC
• Version: 1.0.1

Overview

The skill is openly about running a local Horus intelligence terminal, but it also directs persistent memory, cross-channel conversation sharing, and a network-exposed relay in ways that need careful review before installation.

Install only if you are comfortable with Horus maintaining durable project memory and treating multiple chat channels as one shared context. Before running it, change the relay bind host to 127.0.0.1 unless remote access is intentionally needed, protect any remote relay with authentication and firewalling, keep .env out of source control, and avoid storing secrets, personal data, or raw chat content in MEMORY.md.

A.I.G

Vulnerability Patterns

• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T02 · Agent Memory Poisoning

Error

• Location: SKILL.md:341
• Finding: Untrusted intelligence is mandated to be written into durable cross-session memory## Vulnerability Details **File Location**: `SKILL.md:341-365`; related instructions in `SubagentSKILL.md:55-65` and `SubagentSKILL.md:98-104` **Vulnerability Type**: Persistent memory poisoning **Risk Level**: High ### Vulnerable Code `SKILL.md:341-365`: ```markdown ## Memory + identity persistence requirement Document Horus context in: `~/workspace/horus/MEMORY.md` At minimum keep durable notes for: - What Horus is (purpose + UX) — currently MWC 2026 Barcelona event intelligence terminal - Where Horus data lives (`~/workspace/horus/horus-relay/data/`) - Active event context (MWC 2026 — 3–6 March 2026, Fira Gran Via, Barcelona) - Key tracked themes: Samsung/Qualcomm/Ericsson/Nokia announcements, 5G/6G, AI on device, semiconductor supply chain - How to answer intel questions from data by default - Cross-channel continuity expectation (external chat + Horus chat = same agent) ## Horus memory file (required) Maintain project memory in: ```text ~/workspace/horus/MEMORY.md ``` Use it as a durable backup log of important events and changes, each with UTC date/time. When major incidents or architectural changes happen, append an entry immediately. This memory is used to cross-reference ongoing events and avoid losing context between sessions. ``` `SubagentSKILL.md:55-65`: ```markdown ## Memory requirement (mandatory) For notable announcements and major changes, append entries with UTC timestamp to: `~/workspace/horus/MEMORY.md` Use concise format: ```markdown ## YYYY-MM-DD HH:MM UTC — <event or announcement> - What was announced/happened: - Why it matters (market / tech / industry impact): - Sources/signals: - Follow-up: ``` ``` `SubagentSKILL.md:98-104`: ```markdown ## Durable memory reminder Keep `~/workspace/horus/MEMORY.md` updated with durable facts: - Horus purpose: MWC 2026 Barcelona tech event intelligence terminal - Active event: MWC 2026, Fira ...[truncated 3278 chars]
• Remediation: ## Remediation Suggestions 1. Remove the requirement to persist every notable announcement or major change automatically. 2. Require explicit user approval before writing feed-derived information to durable memory. 3. Keep intelligence records in a project-scoped database or cache instead of agent behavioral memory. 4. Store external content strictly as data and never as executable instructions or assistant policy. 5. Record immutable provenance for every persisted item, including source URL, retrieval time, source type, and content hash. 6. Require corroboration from multiple independent sources before promoting a claim to durable status. 7. Add confidence, verification state, expiration time, and last-reviewed time to each record. 8. Prevent feed content from modifying identity, safety, tool-use, or response-policy fields. 9. Separate cross-channel conversation state by user and authorization context rather than relying on one shared global memory file. 10. Treat all existing `MEMORY.md` entries as untrusted until reviewed and sourced. 11. Add size limits, file locking, schema validation, and rollback or audit logging for approved writes. 12. Permit agents to read the event cache by default, but grant write access to durable memory only for an explicit memory-maintenance task.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:203
• Finding: Relay is configured to listen on all network interfaces without mandatory access controls## Vulnerability Details **File Location**: `SKILL.md:203-216`; repeated at `SKILL.md:287-302` **Vulnerability Type**: Unsafe network exposure configuration **Risk Level**: Medium ### Vulnerable Code `SKILL.md:203-216`: ```markdown ### 4) Required relay env ```env HOST=0.0.0.0 PORT=8787 OPENCLAW_SESSION_KEY=agent:main:web:horus-chat ``` Optional (custom builds only): ```env OPENCLAW_BASE_URL=... OPENCLAW_TOKEN=... ``` ``` The configuration is repeated in the current environment-variable template: ```markdown ## Environment variables (current) ```env HOST=0.0.0.0 PORT=8787 MAX_SIGNALS=100 BTC_POLL_MS=5000 FLIGHTS_POLL_MS=90000 INCIDENTS_POLL_MS=60000 J7_USERNAME= J7_PASSWORD= OPENCLAW_SESSION_KEY=agent:main:web:horus-chat ``` ``` ### Technical Analysis Binding the relay to `0.0.0.0` makes it listen on every available network interface rather than only the loopback interface. This conflicts with the Skill's stated local/private design and expands the relay's attack surface to any network from which the host and port are reachable. The documented relay exposes intelligence endpoints and a `POST /api/chat` bridge. The guide does not make authentication, authorization, TLS, network allowlisting, request-size limits, or rate limiting mandatory before selecting the public bind address. The OpenClaw session key shown here is a routing identifier rather than proof that callers are authorized. If the implementation follows this guide without additional controls, an external caller may be able to submit content to the relay, which then forwards that content to the configured OpenClaw agent session. A remote relay can be legitimate when the dashboard runs on another host, but exposing every interface is not the least-privileged default. Remote access should be an explicit deployment choice with compensating controls. ### Attack Path 1. An operator follows the documented config ...[truncated 1899 chars]
• Remediation: ## Remediation Suggestions 1. Change the secure default to `HOST=127.0.0.1`. 2. Require an explicit opt-in setting before allowing non-loopback binding. 3. If remote access is required, place the relay behind an authenticated reverse proxy or private VPN. 4. Require TLS for all traffic that leaves the local host. 5. Authenticate every relay endpoint and authorize access per user and operation. 6. Protect `POST /api/chat` with short-lived credentials, replay protection, request-size limits, rate limits, and per-user session isolation. 7. Apply firewall allowlists so only intended frontend hosts can reach port `8787`. 8. Restrict browser origins and validate `Origin` and `Host` headers, while recognizing that CORS alone is not authentication. 9. Use a dedicated least-privileged OpenClaw session that cannot access unrelated conversations, secrets, or high-impact tools. 10. Avoid sharing one stable agent session among mutually untrusted users. 11. Sanitize and structurally delimit all relayed user content before passing it to an agent. 12. Add startup warnings or refuse to start when `0.0.0.0` is selected without authentication and transport security. 13. Document network trust assumptions and add automated tests confirming that unauthenticated requests are rejected.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (9)

Credential Access

High

• Category: Privilege Escalation

Content

├── horus-relay/
│   ├── src/server.js
│   ├── data/                # runtime data files (ignored)
│   ├── .env                # secrets/local config (ignored)
│   └── .env.example        # safe template (committed)
├── horus-ui-react/
│   └── src/

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

Ae1

High

• Category: analysis-evasion

Content

- new source behavior is documented in `SKILL.md` + `MEMORY.md`

• Confidence: 100% confidence
• Finding: Referenced artifact was not completely inspected

Vague Triggers

Medium

• Confidence: 92% confidence
• Finding: The skill’s activation scope is very broad ('Use when working on Horus...') and lacks clear trigger boundaries or exclusions. In an agentic environment, this can cause the skill to be invoked in loosely related contexts, increasing the chance that sensitive instructions about local files, credentials, persistence, and gateway/chat behavior are applied when not appropriate.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill requires maintaining a durable memory file and appending major events/changes, but it does not warn against storing secrets, tokens, credentials, personal data, or sensitive conversational content. Because the file is explicitly intended as cross-session continuity, it can become a long-lived sensitive data sink on disk and increase exposure through backup, sync, local compromise, or accidental commit.

Vague Triggers

Medium

• Confidence: 95% confidence
• Finding: This markdown skill file defines invocation behavior using a common everyday phrase and an open-ended extension ("or similar"). That can overlap with ordinary conversation and does not clearly bound when the skill should activate versus when it should not.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill mandates writing notable announcements and major changes to a persistent MEMORY.md file without any consent, scoping, or data-minimization guardrails. If user-provided or conversation-derived content is included, this can silently retain sensitive information on disk and make it available to later runs or operators beyond the original interaction.

Ssd 3

Medium

• Confidence: 94% confidence
• Finding: The durable-memory requirement encourages storing conversation-derived facts over time without defining what must never be stored or who may later read it. In practice this can accumulate sensitive inferences, operator notes, or user-provided details that may later be exposed in responses or through local file access.

Ssd 3

Medium

• Confidence: 97% confidence
• Finding: The instruction to treat Telegram, Discord, iMessage, and web chat as one shared conversation context creates a real risk of cross-channel data leakage. Content disclosed in one channel could be retained and later surfaced in another channel with different participants, expectations, or security properties, breaking contextual isolation and consent boundaries.

Natural-Language Policy Violations

Low

• Confidence: 88% confidence
• Finding: The instruction requires responses to begin with the exact English phrase "Here's the latest from MWC 2026:". That imposes a language choice regardless of the user's preferred language and does not provide any opt-in or locale-selection mechanism.

Static analysis

No suspicious patterns detected.