OpenRA-RL

• Outcome: Pass
• Latest audit: Sep 10, 2026 · 9:24 PM UTC
• Version: 1.1.0

Overview

This skill is a coherent game integration, but it relies on an external Python package and Docker image that users should verify before running.

Install only if you are comfortable running the openra-rl package and its Docker container. Prefer reviewing the linked project, pinning a known package version, checking which image is pulled, and keeping the server bound to local access unless you intentionally expose it.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:13

Finding

Unpinned Third-Party Package and Docker Image Execution

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 13-16 and 27-39
Vulnerability Type: Unpinned third-party executable dependencies
Risk Level: Medium

The Skill installs the openra-rl package without pinning an exact version or verifying its integrity. It subsequently runs that package to retrieve and start a Docker image whose registry, tag, and immutable digest are not specified.

Relevant code snippets:

SKILL.md, lines 13-16:

yaml

  install:
    - kind: uv
      package: openra-rl
      bins: [openra-rl]

SKILL.md, lines 27-39:

markdown

### 1. Install

```bash
pip install openra-rl

2. Start the game server

bash

openra-rl server start

This pulls the Docker image and starts the game server on port 8000.

text

### Technical Analysis

Neither installation method constrains `openra-rl` to a reviewed version or validates the downloaded artifact with a cryptographic hash. Package resolution can therefore select a different release from the one intended or previously audited.

The installed executable then pulls and starts an unspecified Docker image. The documentation does not identify the image registry, repository, tag, digest, container privileges, volume mounts, or network binding configuration. A mutable image tag or compromised upstream package could consequently alter the code executed after this Skill has been reviewed.

This is a supply-chain weakness rather than evidence that the current package or image is malicious. The project contains no executable source code with which to verify the behavior of the package or container.

### Attack Path

1. An attacker compromises the upstream package publication account, package repository, container registry, or mutable image tag.
2. The attacker publishes a modified `openra-rl` release or replaces the Docker image selected by the server command.
3. A user follows the Skill instructions and ex
...[truncated 1146 chars]

Remediation

View remediation

Remediation Suggestions

1. Pin openra-rl to a specific audited version in both metadata and installation instructions, for example openra-rl==1.1.0.
2. Use a lock file or hash-verified installation such as pip install --require-hashes -r requirements.txt.
3. Publish expected package hashes and document how users can verify downloaded artifacts.
4. Identify the exact container registry and repository used by openra-rl server start.
5. Pin the container image by immutable digest, such as repository/image@sha256:..., rather than relying on a mutable tag.
6. Document and minimize container permissions: run as a non-root user, drop unnecessary Linux capabilities, enable no-new-privileges, use a read-only root filesystem where practical, and avoid privileged mode.
7. Do not mount the Docker socket, sensitive host directories, SSH keys, cloud credentials, or broad home-directory paths into the container.
8. Bind port 8000 to loopback by default unless remote access is explicitly required, and document any authentication or network-exposure controls.
9. Add provenance verification, vulnerability scanning, and reproducible release procedures for both Python packages and container images.

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
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.