proxq

• Outcome: Pass
• Latest audit: Aug 8, 2026 · 10:42 PM UTC
• Version: 0.10.13

Overview

This skill is a clearly disclosed guide for using a trusted async HTTP proxy queue, with real but expected proxy and no-auth risks explained in the artifact.

Install only if you operate or trust the proxq instance. Put proxq behind authentication or bind it to a private interface, configure upstreams only to services you intend it to reach, avoid forwarding secrets unless the upstream is trusted, and do not cancel job IDs except ones you submitted or the user explicitly identifies.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• 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
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

External Transmission

Medium

• Category: Data Exfiltration

Content

{ "openclaw": { "emoji": "🦡", "primaryEnv": "PROXQ_URL", "requires": { "bins": ["curl", "docker"] } } }
permissions:
  network: "outbound HTTP to the configured PROXQ_URL (submit/poll/cancel job calls) — AND proxq itself makes arbitrary outbound HTTP requests to whatever upstream/URL you submit through it, on your behalf. That's an SSRF surface: only submit requests you intend proxq's configured upstreams to receive."
  shell: "curl + docker/docker-compose invocations shown in setup.md and this file (container lifecycle, request examples) — no other host access"
---

# proxq

• Confidence: 88% confidence
• Finding: The skill explicitly permits outbound HTTP to a proxq instance that can in turn forward arbitrary HTTP requests to configured upstreams on the caller’s behalf. In this context, the external transmission is not merely informational: it creates a real SSRF-capable relay and can transmit request bodies, headers, and potentially sensitive data to internal or trusted backends if the proxq deployment is mis-scoped or exposed without auth.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

---
name: proxq
description: Go, Redis-backed async HTTP proxy queue (built on asynq). POST any HTTP request (any method, any path, any body) to a configured upstream, get a job ID back instantly (202), a worker forwards it later, you poll GET /__jobs/{id} for status (queued/running/completed/failed) and GET /__jobs/{id}/content for the replayed upstream response (status/headers/body). DELETE /__jobs/{id} cancels. Path-prefix routing to multiple upstreams, per-upstream timeout/retries/pathFilter, optional response caching (memory or Redis LRU), automatic direct-proxy bypass for WebSocket/chunked/large-body requests. No built-in auth. Use when the user wants to turn a slow/unreliable backend into a fire-and-forget async API, decouple a client from upstream latency, relay webhooks with retries, or queue heavy uploads/processing jobs behind short-timeout reverse proxies.
homepage: https://github.com/psyb0t/docker-proxq
user-invocable: true
metadata:

• Confidence: 95% confidence
• Finding: The documented interface includes DELETE /__jobs/{id} cancellation in a system with no built-in authentication or ownership checks. That means a user with network access to proxq can cancel any known job ID, enabling unauthorized interference with other users’ queued or in-flight work.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

- **No built-in authentication or authorization.** proxq ships with zero auth — no API key, no bearer token, no allowlist. Anyone who can reach `PROXQ_URL` can submit jobs, poll any job ID, and cancel any job ID (job IDs are UUIDv4 but there is no ownership check). Front it with a reverse proxy doing auth (basic auth, mTLS, an API gateway) or bind it to loopback/an internal network only — do not expose a bare proxq instance to the open internet.
- **Trusted upstreams only.** Configure `upstreams[].url` to point only at backends you control or explicitly trust. proxq forwards the full original request (method, headers, body) plus `X-Forwarded-For`/`X-Real-IP`/`X-Forwarded-Proto` — treat the upstream config the same way you'd treat a reverse-proxy target list.
- **Consumer-only.** This skill talks to an instance you (or your operator) already run and trust. It never provisions, hardens, or reconfigures the server — that's covered in setup.md as an explicit operator step.
- **Cancelling a job** — `DELETE /__jobs/{id}` best-effort stops an in-flight job and deletes its record (no undo). Per the no-auth point above there's no ownership check, so only cancel a job you submitted or one the user explicitly named — don't guess IDs or bulk-cancel.

## When To Use

• Confidence: 98% confidence
• Finding: This section confirms that proxq has no ownership check for DELETE /__jobs/{id}, so any reachable client can cancel arbitrary jobs if they know or obtain an ID. In a multi-user or exposed deployment, this becomes an insecure direct object reference-style control flaw that can disrupt workloads and delete task records.

Static analysis

No suspicious patterns detected.