SLA Monitor

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

Overview

This skill is mostly documentation for SLA monitoring, but it includes a copyable Docker command that would run a persistent third-party monitoring service with broad network exposure and no security hardening guidance.

Review the self-hosted Docker command before using this skill in production. Pin the Uptime Kuma image to a reviewed digest, bind the port to localhost or restrict it with firewall/security-group rules, put remote access behind authenticated TLS, and choose a restart policy and volume handling process you can manage and roll back.

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:29

Finding

Mutable Container Image Deployed Persistently with Broad Network Exposure

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 29–31
Vulnerability Type: Unpinned third-party container image and insecure network binding
Risk Level: Medium

Complete Code Snippet:

bash

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

Technical Analysis

The documented command deploys the third-party image louislam/uptime-kuma:1. This is a mutable major-version tag rather than an immutable image digest. Consequently, separate executions of the same reviewed command can retrieve different image contents. A compromised registry account, upstream release, or distribution path could cause unreviewed code to execute when a user follows the deployment instructions.

The command also uses --restart=always, causing the container to restart after Docker daemon or host restarts. This increases the duration and operational effect of any vulnerable or compromised image.

In addition, -p 3001:3001 publishes the container port on all host interfaces by default. Unless access is restricted elsewhere by a firewall or network policy, the Uptime Kuma interface may be reachable from untrusted networks. The command does not document authentication, TLS termination, firewall restrictions, or reverse-proxy access controls.

Attack Path

1. A user follows the deployment command from SKILL.md.
2. Docker resolves the mutable louislam/uptime-kuma:1 tag at execution time.
3. If the tag has changed or its supply chain has been compromised, Docker retrieves and runs content that was not part of the audited project.
4. The container remains operational across Docker daemon or host restarts because of --restart=always.
5. Port 3001 is published on all host interfaces.
6. A network attacker who can reach the host may probe the exposed monitoring interface and exploit any application vulnerability or insecure initial configuration present in ...[truncated 1136 chars]

Remediation

View remediation

Remediation Suggestions

1. Pin the container to a reviewed, immutable version and digest:

   bash

   docker run -d \
     --restart=unless-stopped \
     -p 127.0.0.1:3001:3001 \
     -v uptime-kuma:/app/data \
     --name uptime-kuma \
     louislam/uptime-kuma:<exact-version>@sha256:<verified-digest>
   

2. Verify the digest against the publisher's authenticated release information and establish a controlled process for reviewing and updating it.
3. Bind the port to 127.0.0.1 unless direct external access is explicitly required. Place the service behind an authenticated TLS reverse proxy when remote access is needed.
4. Restrict inbound traffic with host firewall rules, cloud security groups, or equivalent network policies.
5. Document secure initial setup, including administrator authentication, strong credentials, TLS, session security, and access restrictions.
6. Harden the container with least-privilege controls where supported, including capability removal, resource limits, and appropriate security profiles.
7. Scan the pinned image for known vulnerabilities before deployment and define a reviewed update and rollback procedure.
8. Reconsider the unconditional restart policy. Use --restart=unless-stopped or an explicitly managed service lifecycle to make administrative shutdown effective.

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

Findings (1)

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 91% confidence

Finding

The Docker example pulls and runs louislam/uptime-kuma:1, which uses a mutable tag rather than an immutable digest. Mutable tags can be retargeted over time, causing users of the skill to deploy unexpected or compromised images without noticing. In a production monitoring skill, this is more dangerous because readers are likely to copy the command directly into operational environments.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.