aigate

• Outcome: Review
• Latest audit: Sep 13, 2026 · 2:06 AM UTC
• Version: 5.2.0

Overview

The skill is transparent about its purpose, but it installs a very powerful self-hosted AI gateway where one token can control code execution, browsing, messaging, storage, and provider access.

Install only on an isolated trusted host or VM, pin and review the upstream commit and container images before running Make targets, enable only the services you need, split per-service tokens before giving any credential to an agent, protect .env/mailbox/Telethon files, and never expose port 4000 directly to the public internet.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:82
• Finding: Unpinned Remote Repository Is Retrieved and Executed<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:82-88` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: High ```bash git clone https://github.com/psyb0t/aigate cd aigate make bootstrap # creates .env from .env.example (any target does this) # edit .env: set AIGATE_TOKEN, flip the flags for the providers/services you want to 1 # .env is gitignored. docker-compose.yml is tracked, so put compose changes in # docker-compose.override.yml, which is gitignored and merges last make limits # writes .env.limits sized to this machine's RAM/CPU make run-bg # start the stack in the background ``` The same unsafe installation pattern is repeated in `references/setup.md:7-14`. ### Technical Analysis The instructions clone the current default branch of a remote Git repository and subsequently execute repository-controlled Make targets. No reviewed commit, immutable release tag, source checksum, signature, or container-image digest is specified. The effective payload therefore remains mutable after this Skill has been reviewed. The audited artifact does not contain the upstream `Makefile`, Docker Compose definitions, bootstrap scripts, or container contents executed by these commands. Running `make bootstrap`, `make limits`, or `make run-bg` may execute arbitrary commands defined by the repository with the permissions of the invoking user, while Docker access can commonly provide a path to host-level control. This is specifically a remote payload retrieval issue rather than evidence that the current upstream repository is malicious. The risk arises because future or compromised upstream content would be trusted and executed without integrity validation. ### Attack Path 1. An attacker compromises the upstream repository, its maintainer account, default branch, build pipeline, or a mutable container image referenced by the repository. 2. The attacker modifies a Make target, Compose configuration, script, or container en ...[truncated 1001 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin the source repository to a specific, reviewed commit: ```bash git clone https://github.com/psyb0t/aigate cd aigate git checkout --detach <reviewed-full-commit-hash> ``` 2. Verify the commit using a trusted signature or an independently distributed checksum before executing any target. 3. Pin every container image by immutable digest rather than a mutable tag: ```yaml image: example/image@sha256:<verified-digest> ``` 4. Vendor the required Makefile, Compose configuration, and bootstrap scripts into the audited Skill package where feasible. 5. Audit all Make targets and Compose lifecycle hooks before execution, including build contexts, bind mounts, privileged containers, host networking, and Docker socket mounts. 6. Run installation from a dedicated low-privilege account or isolated virtual machine without access to unrelated host secrets. 7. Avoid providing production credentials until image and startup integrity checks have completed. 8. Establish an update procedure requiring review and integrity verification before changing the pinned commit or image digests. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:34
• Finding: Shared Master Bearer Token Grants Excessive Cross-Service Privileges<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:34-48` **Vulnerability Type**: Excessive authorization and failure to enforce least privilege **Risk Level**: High ```text No per-tool scoping by default. `AIGATE_TOKEN` is a single all-or-nothing capability grant — every per-service token (`CLAUDEBOX_API_TOKEN`, `PIBOX_ZAI_API_TOKEN`, `PREDICTALOT_AUTH_TOKEN`, `AUDIOLLA_AUTH_TOKEN`, `FLICKIES_AUTH_TOKEN`, `STEALTHY_AUTO_BROWSE_AUTH_TOKEN`, `HYBRIDS3_MASTER_KEY`, `MCP_TOOLS_AUTH_TOKEN`, `TELETHON_AUTH_KEY`, etc.) defaults to it unless the operator explicitly overrides each one separately. Handing an agent the token is not "give it chat access" — it's granting code execution, browser automation, and messaging in one shot, with no way to grant a narrower subset unless the operator has pre-split the per-service tokens. An agent must only be given `AIGATE_TOKEN` when it is fully trusted and only for the specific action the user explicitly requested — never pass it to an agent "just in case it needs something." ``` The configuration behavior is also documented in `references/setup.md:40-42`: ```text `AIGATE_TOKEN` | Master bearer token. Every per-service token below defaults to this value when left unset — one token authenticates against LiteLLM, claudebox, pibox-zai, predictalot, mcp_tools, stealthy-auto-browse, hybrids3, telethon, audiolla, flickies, talkies, talkies-cuda. Override a specific `*_AUTH_TOKEN` / `*_API_TOKEN` var to scope that service separately. ``` ### Technical Analysis The default authorization model reuses one bearer token across services with materially different privilege levels. A credential provided for an ordinary inference request can therefore also authorize access to enabled code-execution agents, browser automation, object storage, email, Telegram, and other operational capabilities. Authentication proves possession of the token but does not establish whether the caller is authorized for a particular service or opera ...[truncated 1916 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove fallback from service-specific credentials to `AIGATE_TOKEN`; require an explicit, unique credential for every privileged service. 2. Implement deny-by-default route authorization with granular scopes such as: - `inference:invoke` - `code:execute` - `browser:control` - `storage:read` - `storage:write` - `mail:send` - `telegram:send` 3. Issue short-lived credentials restricted to the exact routes and operations needed by each client or agent. 4. Place an authorization gateway in front of all routes and validate issuer, audience, scope, expiry, and caller identity on every request. 5. Use separate identities and credentials for human users, autonomous agents, administrative interfaces, and service-to-service communication. 6. Prevent untrusted inference clients from reaching administrative or tool-execution routes through network segmentation and explicit routing policy. 7. Rotate the master and service credentials after splitting them, and revoke previously shared tokens. 8. Redact bearer tokens from application, proxy, queue, and audit logs. 9. Add automated startup validation that rejects enabled high-privilege services when their dedicated tokens are absent or equal to the master token. 10. Maintain auditable per-service access logs and alert on cross-service access or unusual execution, messaging, and storage activity. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• 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

Findings (9)

Privileged Kubernetes Workload

High

• Category: Tool Misuse

Content

- Never expose port `4000` directly to the public internet. Use Cloudflare Tunnel (`CLOUDFLARED=1`) or Tailscale (`TAILSCALE=1`) — both keep no ports open on the host — or put a real authenticating gateway/reverse-proxy in front of it.
- Every request needs `Authorization: Bearer $AIGATE_TOKEN` (or a per-service override token) — there is no unauthenticated path once a service is enabled. Don't hardcode the token in scripts committed to a repo; source it from `.env`/environment.
- Internal services (Postgres, Redis, LiteLLM, and most optional services) bind to no host ports at all — only nginx is exposed. Don't add host port mappings for internal services unless you specifically need direct access and understand you're widening the blast radius.
- `piston` runs `privileged: true` (required for nsjail's own isolation, not a bypass of it) and lives on an internal-only network with no outbound internet — don't change that without understanding why.
- Guard `.env` and any mailbox/Telethon config files — they hold plaintext secrets and are gitignored for a reason.

## When to use

• Confidence: 92% confidence
• Finding: Running a container with privileged:true is inherently dangerous because it greatly expands the container's access to the host kernel and device surface. Although the document explains this is for nsjail isolation and notes the service is internal-only with no outbound internet, privileged mode still materially increases blast radius if that service is compromised or misconfigured.

Credential Access

High

• Category: Privilege Escalation

Content

```bash
git clone https://github.com/psyb0t/aigate
cd aigate
make bootstrap   # creates .env from .env.example (any target does this)
# edit .env — see "Required env" below, then flip service flags to 1
# .env is gitignored. docker-compose.yml is tracked, so put compose changes in
# docker-compose.override.yml, which is gitignored and merges last

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

Credential Access

High

• Category: Privilege Escalation

Content

```bash
git clone https://github.com/psyb0t/aigate
cd aigate
make bootstrap   # creates .env from .env.example (any target does this)
# edit .env — see "Required env" below, then flip service flags to 1
# .env is gitignored. docker-compose.yml is tracked, so put compose changes in
# docker-compose.override.yml, which is gitignored and merges last

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

Credential Access

High

• Category: Privilege Escalation

Content

```bash
git clone https://github.com/psyb0t/aigate
cd aigate
make bootstrap   # creates .env from .env.example (any target does this)
# edit .env — see "Required env" below, then flip service flags to 1
# .env is gitignored. docker-compose.yml is tracked, so put compose changes in
# docker-compose.override.yml, which is gitignored and merges last

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

Credential Access

High

• Category: Privilege Escalation

Content

```bash
git clone https://github.com/psyb0t/aigate
cd aigate
make bootstrap   # creates .env from .env.example (any target does this)
# edit .env — see "Required env" below, then flip service flags to 1
# .env is gitignored. docker-compose.yml is tracked, so put compose changes in
# docker-compose.override.yml, which is gitignored and merges last

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

Credential Access

High

• Category: Privilege Escalation

Content

```bash
git clone https://github.com/psyb0t/aigate
cd aigate
make bootstrap   # creates .env from .env.example (any target does this)
# edit .env — see "Required env" below, then flip service flags to 1
# .env is gitignored. docker-compose.yml is tracked, so put compose changes in
# docker-compose.override.yml, which is gitignored and merges last

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

External Transmission

Medium

• Category: Data Exfiltration

Content

- aigate itself reaches out to model providers, MCP tool backends, and the open internet on the user's behalf (web search, browser automation, email, Telegram)
  shell:
    - docker / docker compose (bring the stack up/down, read logs)
    - curl (call the OpenAI-compatible endpoint and direct service routes)
metadata:
  openclaw:
    emoji: "🚪"

• Confidence: 90% confidence
• Finding: The skill explicitly permits use of curl against a single bearer-token gateway that can proxy requests to external model providers, browser automation, email, Telegram, and other internet-facing backends. This creates a real external transmission and delegation channel: any agent given the token can cause data to leave the host and trigger actions on remote services, so the risk is elevated by the stack's broad capabilities and lack of fine-grained scoping.

Unrestricted Tool Access

Medium

• Category: Excessive Agency

Content

**This is a very high-capability, very high-blast-radius stack. Treat the endpoint and its token like root on the host.** A single `AIGATE_TOKEN` bearer can, depending on what's enabled:

- Hold API keys/credentials for many cloud model providers (Groq, Cerebras, OpenRouter, HuggingFace, Mistral, Cohere, Anthropic, OpenAI) plus subscription agent backends (Claude Code OAuth/API key, z.ai GLM Coding Plan).
- Execute arbitrary code — three full agentic coding agents (claudebox, pibox-zai, pibox) with shell + file access, plus sandboxed multi-language execution (piston).
- Drive a real browser (stealth Camoufox cluster) that can log into sites, fill forms, and act as the user across the open web.
- Send email and Telegram messages on the user's behalf (mailbox, Telethon) — mailbox additionally holds plaintext IMAP/SMTP credentials in its YAML config.
- Read/write S3-compatible object storage with a public-read bucket.

• Confidence: 98% confidence
• Finding: This is a true high-risk capability exposure: the documentation states that one bearer token can unlock arbitrary code execution, shell/file access, browser automation, messaging, and storage operations. Because there is no per-tool scoping by default, compromise or misuse of that token effectively grants root-equivalent operational power over the stack and connected accounts/services.

External Transmission

Medium

• Category: Data Exfiltration

Content

All requests carry `Authorization: Bearer $AIGATE_TOKEN` (or the relevant per-service override):

```bash
curl http://localhost:4000/chat/completions \
  -H "Authorization: Bearer $AIGATE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"model": "local-ollama-cpu-llama3.2-3b", "messages": [{"role": "user", "content": "hello"}]}'

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Static analysis

No suspicious patterns detected.