Ika Operator

• Outcome: Review
• Latest audit: Sep 14, 2026 · 10:18 PM UTC
• Version: 1.0.0

Overview

This is an operations guide rather than active malware, but it gives high-value validator and staking instructions with important safety checks under-specified.

Install only if you are comfortable treating this as a high-risk validator runbook. Independently verify the official Ika sources, release artifacts, package/object IDs, staking portal authenticity, and every wallet transaction before signing. Do not expose metrics or admin endpoints to the public Internet, use HTTPS and protected secret storage for monitoring credentials, back up validator keys securely, and run database deletion commands only when you intentionally want to discard local state and resync.

A.I.G

Vulnerability Patterns

• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (4)

T09 · Insecure Skill Coding Practices

Warning

• Location: references/configuration.md:39
• Finding: Unauthenticated Metrics Endpoint Exposed on All Network Interfaces## Vulnerability Details **File Location**: `references/configuration.md:39-40`; related exposure instructions appear in `SKILL.md:64-70`, `references/operations.md:106`, and `references/validator-setup.md:43-51` **Vulnerability Type**: T09: Insecure Skill Coding Practices **Risk Level**: Medium **Vulnerable Code Snippet**: ```yaml metrics-address: '0.0.0.0:9184' # Prometheus metrics endpoint # Default: 0.0.0.0:9184 ``` The operational documentation reinforces this configuration: ```text Default endpoint: `http://0.0.0.0:9184/metrics` ``` It also instructs operators to open the corresponding port: ```text | TCP/9184 | Inbound/Outbound | Metrics Scraping | ``` ### Technical Analysis The documented default binds the Prometheus metrics service to `0.0.0.0`, making it listen on every available network interface. The deployment guidance also instructs operators to open TCP port 9184 without documenting authentication, network allowlisting, or an authenticated reverse proxy. The metrics described by the project include consensus progress, MPC session activity, peer states, event-processing lag, checkpoint progress, transaction queue lengths, and load-shedding behavior. If port 9184 is reachable from an untrusted network, an unauthenticated remote party can query this operational data directly. ### Attack Path 1. An operator follows the documented configuration and binds the metrics service to `0.0.0.0:9184`. 2. The operator opens TCP port 9184 as instructed. 3. An attacker scans the validator address and identifies the exposed Prometheus endpoint. 4. The attacker requests `http://validator-address:9184/metrics`. 5. The attacker collects consensus, synchronization, peer, queue, and workload telemetry. 6. The information is used to identify degraded periods, synchronization delays, or other favorable windows for targeted denial-of-service activity. ### Impact A ...[truncated 457 chars]
• Remediation: ## Remediation Suggestions - Change the secure default to `127.0.0.1:9184` or a dedicated private monitoring interface. - Do not instruct operators to expose port 9184 to the public Internet. - Require host firewall or cloud security-group rules that allow only designated monitoring servers. - Use a VPN, private network, or mutually authenticated TLS proxy when metrics must cross network boundaries. - Place the endpoint behind an authenticated reverse proxy if remote access is required. - Document that the raw Prometheus endpoint provides no application-layer authentication. - Add deployment verification steps such as external port scanning and firewall-rule review.

T09 · Insecure Skill Coding Practices

Warning

• Location: references/operations.md:232
• Finding: Plaintext HTTP Used for Remote Metrics and Credential Transmission Examples## Vulnerability Details **File Location**: `references/operations.md:232-237`; related plaintext push examples appear at `references/configuration.md:53-56` and `references/operations.md:118-121` **Vulnerability Type**: T09: Insecure Skill Coding Practices **Risk Level**: Medium **Vulnerable Code Snippet**: ```yaml remote-write: url: 'http://mimir.example.com/api/v1/push' username: user password: pass pool-max-idle-per-host: 8 ``` Additional plaintext metrics guidance includes: ```yaml metrics: push-interval-seconds: 60 push-url: 'http://metrics.example.com/api/v1/push' ``` ### Technical Analysis The examples present unencrypted HTTP as a valid transport for sending validator telemetry to remote monitoring services. One example configures a username and password alongside an `http://` remote-write URL. If operators adapt these examples for an endpoint reached over an untrusted or shared network, transport encryption is absent. Any credentials transmitted by the metrics client, as well as the metric payloads themselves, may be observable by a network-positioned attacker. Plaintext HTTP also lacks server authentication and integrity protection, allowing traffic modification or redirection. The finding concerns remote examples such as `mimir.example.com` and `metrics.example.com`; loopback-only HTTP endpoints do not have the same network exposure. ### Attack Path 1. An operator copies the documented remote-write or metrics-push example. 2. The placeholder host is replaced, but the `http://` scheme is retained. 3. The metrics client sends telemetry and any configured authentication data without TLS. 4. An attacker with access to the local network, routing path, proxy infrastructure, or compromised gateway observes the traffic. 5. The attacker captures credentials or validator telemetry, or modifies metric submissions in transit. 6. Captured credentials may then be used against the monitor ...[truncated 532 chars]
• Remediation: ## Remediation Suggestions - Replace all non-loopback remote examples with `https://` URLs. - State explicitly that plaintext HTTP is acceptable only for services confined to the same trusted host or an equivalently protected channel. - Require certificate validation and discourage disabling TLS verification. - Prefer mutual TLS or scoped bearer credentials for monitoring infrastructure. - Store passwords in a protected environment file, secret manager, or service credential mechanism rather than directly in YAML. - Use narrowly scoped monitoring accounts and rotate credentials regularly. - Document network controls that prevent telemetry from traversing untrusted networks.

T08 · Insecure Dependencies

Warning

• Location: references/validator-setup.md:178
• Finding: High-Value Staking Workflow Depends on an External Hosted Portal Without Documented Authenticity Verification## Vulnerability Details **File Location**: `references/validator-setup.md:178-187`; the same portal is referenced at `SKILL.md:119-121` **Vulnerability Type**: T08: Insecure Dependencies **Risk Level**: Medium **Vulnerable Code Snippet**: ```text ## Step 4: Stake into Validator **Minimum stake: 40 million IKA** (below this, cannot join committee). Staking portal: https://ika-mainnet-validators-staking.pages.dev/ 1. Connect your wallet 2. Find your validator 3. **Verify Validator ID matches** the CLI output from Step 3 4. Stake at least 40M IKA ``` ### Technical Analysis The Skill directs operators to connect a cryptocurrency wallet and stake at least 40 million IKA through a frontend hosted on a `pages.dev` domain. The instructions verify the displayed validator ID, but they do not provide an independent method to verify the frontend deployment, expected smart-contract package and object IDs, transaction targets, or transaction effects before signing. A third-party hosting or deployment-account compromise could change the application after this Skill has been reviewed. A modified frontend could construct a transaction targeting an attacker-controlled object or request unrelated wallet permissions while continuing to display the expected validator information. This finding does not establish that the referenced portal is currently malicious. The risk arises from making a high-value transaction depend on mutable externally hosted content without documented authenticity controls. ### Attack Path 1. An attacker compromises the portal's hosting account, deployment pipeline, DNS resolution, or frontend dependencies. 2. The attacker replaces the legitimate frontend with a visually similar version. 3. An operator follows the Skill's documented URL and connects a wallet. 4. The malicious frontend displays the expected validator ID but constructs a different transaction. 5. The operator relies on the visible page a ...[truncated 652 chars]
• Remediation: ## Remediation Suggestions - Host the staking interface under an authenticated domain controlled by the project. - Publish the expected package IDs, object IDs, function names, recipients, and transaction effects in the setup guide. - Require operators to compare transaction details in the wallet before signing. - Provide a reproducible build and signed release metadata for the staking frontend. - Publish deployment hashes or attestations that operators can independently verify. - Provide a CLI or direct on-chain staking procedure that does not depend on mutable web content. - Warn users not to approve unexpected transfers, capability grants, or package calls even when the page displays the correct validator ID.

T08 · Insecure Dependencies

Note

• Location: SKILL.md:76
• Finding: Release Binaries Are Downloaded and Executed Without Documented Integrity Verification## Vulnerability Details **File Location**: `SKILL.md:76`; repeated download guidance appears at `references/validator-setup.md:20` and `references/validator-setup.md:284` **Vulnerability Type**: T08: Insecure Dependencies **Risk Level**: Low **Vulnerable Code Snippet**: ```text Download binaries from: https://github.com/dwallet-labs/ika/releases ``` The update guidance similarly states: ```text - **Update regularly** - download new binaries from GitHub releases ``` ### Technical Analysis The Skill directs operators to download executable validator binaries from GitHub releases, but it does not instruct them to select a pinned version, verify a cryptographic checksum, validate a release signature, or check a provenance attestation. GitHub is not inherently an unsafe source, and the referenced repository is specific rather than obviously typosquatted. However, release assets are mutable external supply-chain artifacts. Compromise of the repository account, release workflow, maintainer credentials, or uploaded asset could result in operators installing a malicious binary. The binary is subsequently run as a persistent validator process with access to validator key files, network services, and node databases. Therefore, integrity verification should occur before installation or execution. ### Attack Path 1. An attacker compromises a maintainer account, release automation token, build environment, or release asset. 2. A malicious binary is uploaded under an expected release filename. 3. An operator follows the documentation and downloads the binary without checking a signature or trusted checksum. 4. The operator installs and launches the binary as the validator service. 5. The malicious process reads files available to the service account, communicates externally, modifies validator behavior, or tampers with local node state. ### Impact Assessment Successful exploitation executes attacker-controlled native c ...[truncated 462 chars]
• Remediation: ## Remediation Suggestions - Pin an explicit tested release version instead of instructing users to download an unspecified latest release. - Publish SHA-256 or stronger hashes through an independently authenticated channel. - Sign releases with a documented maintainer key or use verifiable provenance attestations such as Sigstore. - Add exact verification commands to the installation procedure and require verification before execution. - Verify the repository owner, release tag, asset name, signer identity, and expected architecture. - Prefer reproducible builds from reviewed source where feasible, and compare locally built artifacts against published provenance. - Run the validator under a dedicated unprivileged account with restrictive key-file permissions and systemd sandboxing to reduce supply-chain compromise impact.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (8)

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

```bash
# Stop the node
# Remove the database directory
rm -rf /opt/ika/db/live

# Restart - node will resync from peers via state sync
./target/release/ika-fullnode --config-path config.yaml

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

```bash
# Stop the node
# Remove the database directory
rm -rf /opt/ika/db/live

# Restart - node will resync from peers via state sync
./target/release/ika-fullnode --config-path config.yaml

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

```bash
# Stop the node
# Remove the database directory
rm -rf /opt/ika/db/live

# Restart - node will resync from peers via state sync
./target/release/ika-fullnode --config-path config.yaml

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

For validators, also clear consensus DB:

```bash
rm -rf /opt/ika/consensus_db/*
```

### Event Cursor Override

• Confidence: 90% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The configuration reference includes inline examples for `aws-access-key-id` and `aws-secret-access-key` directly in the YAML, without warning operators not to store long-lived secrets in config files or version control. In an infrastructure operations guide, this can normalize insecure secret handling and lead users to place real cloud credentials in plaintext configs, increasing the risk of credential leakage through repos, backups, logs, or support bundles.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

- [456, '0x123456...']
```

Pinned checkpoints skip verification and reject mismatched digests.

### Database Recovery

• Confidence: 85% confidence
• Finding: The statement that pinned checkpoints 'skip verification' is dangerous because it normalizes bypassing an integrity check in a recovery workflow. If an operator pins an incorrect or attacker-influenced checkpoint digest, the node may accept bad recovery state or diverge from expected chain validation guarantees.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: This markdown file includes `rm -rf` recovery commands that delete live database and consensus data, but the surrounding text does not explicitly warn that these actions are destructive and may permanently remove local state. The only nearby warning in this section applies to event cursor overrides, not to the deletion steps themselves.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The guide advertises an admin API endpoint for validator operations but provides no warning that administrative interfaces must never be exposed to untrusted networks. In a validator context, operators may interpret this as a service to publish or leave broadly reachable, which could enable remote control, configuration changes, operational disruption, or key-adjacent abuse depending on the API surface.

Static analysis

Detected: suspicious.destructive_delete_command

Documentation contains a destructive delete command without an explicit confirmation gate.

Warn

• Code: suspicious.destructive_delete_command
• Location: references/operations.md:194