Dollar Platoon | On-Demand Gigworkers

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

Overview

This skill is a disclosed gig-payroll API guide, but it includes high-impact wallet/payment authority, weakly scoped authentication patterns, and explicit pricing for manipulative engagement tasks.

Install only after review. This skill should be treated as a high-risk marketplace integration: avoid using it for fake engagement, paid reviews, account farming, or spam-related tasks; do not rely on short URL tokens for sensitive publishing; rotate any exposed tokens or API keys; require explicit confirmation for deposits, transfers, proof approvals, and rollups; and do not render or forward untrusted HTML without strong sanitization.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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

Error

• Location: SKILL.md:110
• Finding: Legacy Gigs Permit Unauthenticated Task Injection## Vulnerability Details **File Location**: `SKILL.md`, lines 110-122 **Vulnerability Type**: Authentication bypass caused by backward-compatible fail-open behavior **Risk Level**: High ### Vulnerable Snippet ```markdown ### Security Tokens Every gig has a 6-character alphanumeric security token embedded in its email address and webhook URL. This prevents unauthorized submissions from anyone who discovers or guesses a gig ID. **How it works:** - **Email:** `{gig_id}_{token}[e-mail]` - **Webhook:** `/inbound/webhook/{gig_id}?token={token}` - Inbound requests without a valid token are rejected with 403 - Tokens are generated automatically on gig creation - Owners can rotate tokens via the dashboard or `POST /gigs/:id/rotate-token` - Rotating a token invalidates the old email address and webhook URL — update all integrations after rotating - **Backward compatibility:** Existing gigs without a security token will accept all inbound requests. Generate a token from the dashboard to enable protection. ``` ### Technical Analysis The documented backward-compatibility mechanism deliberately allows inbound requests to gigs that do not have a security token. This is fail-open authentication: the absence of a credential disables access control instead of denying the request. Gig identifiers are not documented as cryptographic secrets. If a legacy gig ID is exposed through an invitation, API response, log, browser history, marketplace listing, or other integration, an unauthenticated party could submit arbitrary inbound task content. The platform may then store and distribute that content to gigworker mailboxes. This behavior is not necessary for the current declared functionality. A migration mechanism can preserve legacy gigs without allowing indefinite unauthenticated ingestion. ### Attack Path 1. The attacker discovers or enumerates the identifier of a legacy gig without a security token ...[truncated 829 chars]
• Remediation: ## Remediation Suggestions - Remove fail-open behavior and reject every inbound request that lacks a valid credential. - Automatically generate strong tokens for all legacy gigs before enforcing authentication. - Temporarily pause inbound delivery for legacy gigs until owners acknowledge the migration. - Record and notify owners of rejected requests during the transition. - Monitor for repeated requests to legacy gig identifiers and apply account- and IP-based throttling. - Add automated tests confirming that missing, malformed, expired, and rotated tokens always result in denial.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:110
• Finding: Low-Entropy Gig Tokens Are Exposed in Query Strings## Vulnerability Details **File Location**: `SKILL.md`, lines 110-121 and 655-684 **Vulnerability Type**: Weak bearer credential design and credential exposure through URLs **Risk Level**: High ### Vulnerable Snippet ```markdown Every gig has a 6-character alphanumeric security token embedded in its email address and webhook URL. - **Webhook:** `/inbound/webhook/{gig_id}?token={token}` ``` ```markdown #### POST /inbound/webhook/:gig_id?token=... curl -X POST "https://staging.dollarplatoon.com/api/inbound/webhook/GIG_01HX...?token=abc123&subject=My+Report" \ -H "Content-Type: text/html" \ -d '<h1>Task Details</h1><p>Please complete this task...</p>' Requires valid `token` query parameter matching the gig's security token. Returns 403 if token is invalid. ``` ### Technical Analysis A six-character alphanumeric token has a maximum search space of approximately 62⁶ combinations. Although rate limiting can impede online guessing, this is substantially weaker than a conventional randomly generated bearer credential with at least 128 bits of entropy. The credential is also placed in the URL query string. Query parameters are commonly captured by reverse-proxy logs, application logs, monitoring services, browser history, copied links, analytics tooling, and support diagnostics. Depending on referrer policy and navigation behavior, URLs can also be disclosed to third parties. Anyone possessing this token can act as an authorized task publisher for the associated gig. Token rotation is documented, but it only limits damage after compromise is detected. ### Attack Path 1. The token is leaked through URL logging, browser history, monitoring data, copied configuration, or another integration. 2. Alternatively, an attacker identifies a gig and attempts token guesses against the inbound endpoint. 3. The attacker sends a request containing the recovered token in the query string. 4. The ...[truncated 629 chars]
• Remediation: ## Remediation Suggestions - Replace six-character tokens with cryptographically random credentials containing at least 128 bits of entropy. - Send credentials in an `Authorization` header or a dedicated secret header rather than in query parameters. - Store only a one-way hash of each token where feasible. - Redact authorization values from application, proxy, CDN, and observability logs. - Apply strict rate limits by gig, source IP, and account, with progressive backoff and abuse alerts. - Support token expiration, overlap-free rotation, scoped publisher credentials, and immediate revocation. - Rotate every existing short token after deploying the stronger format.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:655
• Finding: Externally Supplied HTML Is Documented as Being Rendered by the Frontend## Vulnerability Details **File Location**: `SKILL.md`, lines 655-684 **Vulnerability Type**: Potential stored cross-site scripting through untrusted task content **Risk Level**: High ### Vulnerable Snippet ```markdown #### POST /inbound/webhook/:gig_id?token=... Accepts **JSON** (default) or **HTML/plain text** payloads. Content-Type header determines parsing. **HTML payload (Content-Type: text/html or text/plain):** ```bash curl -X POST "https://staging.dollarplatoon.com/api/inbound/webhook/GIG_01HX...?token=abc123&subject=My+Report" \ -H "Content-Type: text/html" \ -d '<h1>Task Details</h1><p>Please complete this task...</p>' ``` When HTML/text is sent, the message is stored with `type: "email"` and rendered as formatted HTML on the frontend (same as email-sourced tasks). ``` ### Technical Analysis The interface accepts externally supplied HTML, stores it, and renders it as formatted HTML. The documentation does not state that the content is sanitized, escaped, sandboxed, or constrained by a strict Content Security Policy. Rendering untrusted HTML directly can create stored cross-site scripting. Dangerous elements and attributes include scripts, event handlers, active SVG content, malicious links, form elements, and resource-loading tags. Even where ordinary script tags are blocked, unsafe HTML parsing or incomplete sanitization may allow bypasses. Authentication of the publisher does not make its content safe. A legitimate publisher account or token may be compromised, and legacy gigs explicitly permit tokenless submissions. ### Attack Path 1. The attacker obtains publishing access through a valid or compromised token, or targets a tokenless legacy gig. 2. The attacker submits crafted HTML to the inbound webhook using `Content-Type: text/html`. 3. The platform stores the content as an email-type message. 4. A gigworker or client opens the task in the frontend. 5. Th ...[truncated 772 chars]
• Remediation: ## Remediation Suggestions - Treat all inbound HTML and email content as hostile. - Prefer rendering escaped plain text or a limited Markdown subset. - If HTML is required, sanitize it server-side and client-side using a maintained allowlist-based sanitizer. - Remove scripts, event-handler attributes, active SVG/MathML, forms, iframes, dangerous URL schemes, and automatic external resource loading. - Render rich content in a sandboxed iframe on a separate origin without same-origin privileges. - Deploy a strict CSP that disallows inline script and restricts scripts, frames, forms, images, and connections. - Add regression tests using established XSS payload suites. - Display the publisher identity and warn users before opening external links.

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:874
• Finding: Unauthenticated OfficeX Login Returns a Full API Key Based Only on Identifiers## Vulnerability Details **File Location**: `SKILL.md`, lines 874-899 **Vulnerability Type**: Weak authentication and potential account takeover **Risk Level**: Critical ### Vulnerable Snippet ```markdown ### OfficeX Integration | Method | Path | Auth | Description | |--------|------|------|-------------| | POST | `/officex/webhook` | No | Handle OfficeX install/uninstall | | POST | `/officex/login` | No | Login via OfficeX credentials | #### POST /officex/webhook ```json // Request { "event": "INSTALL", "payload": { "install_id": "...", "install_secret": "...", "user_id": "...", "app_id": "..." } } // Response { "agent_context": { "user_email": "[e-mail]", "api_key": "...", "api_url": "https://...", "install_id": "...", "install_secret": "..." } } ``` Creates user with email `officex-{user_id}@dollar-platoon.local`. Auto-provisions hot wallet. #### POST /officex/login ```json // Request { "officex_user_id": "...", "officex_install_id": "..." } // Response { "email": "[e-mail]", "api_key": "..." } ``` Returns 404 if user not found (webhook may not have fired yet). Returns 403 if install_id mismatch. ``` ### Technical Analysis The documented `/officex/login` endpoint is unauthenticated and accepts only `officex_user_id` and `officex_install_id`. Neither value is documented as a secret, and the request includes no installation secret, signature, nonce, one-time code, or independently verifiable OfficeX assertion. Comparing the supplied installation ID with a stored installation ID proves equality of identifiers, not possession of a secret. If these identifiers are predictable, logged, included in webhook traffic, exposed to integrations, or otherwise disclosed, an attacker could request the account's existing API key. The API key authorizes sensitive operations, including access to private gig data and managed hot-wallet transfer endpoints. ...[truncated 1762 chars]
• Remediation: ## Remediation Suggestions - Do not authenticate users using identifiers alone. - Require proof of possession of `install_secret`, preferably through an HMAC over a nonce, timestamp, audience, and request body. - Alternatively, require a short-lived signed OfficeX assertion and validate its issuer, audience, subject, expiration, and nonce. - Authenticate `/officex/webhook` with cryptographic signature verification and replay protection. - Never return an installation secret in routine webhook responses. - Issue short-lived, scoped access tokens instead of returning a reusable full-privilege API key. - Rotate the API key after successful credential exchange rather than repeatedly returning an existing key. - Require step-up authorization for wallet transfers, deposits, token rotation, and payout operations. - Bind sensitive operations to explicit account ownership checks and transaction limits. - Rate-limit login attempts and produce generic failure responses to reduce account enumeration. - Audit identifier and credential exposure in logs, revoke potentially exposed credentials, and alert affected users.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (11)

Context-Inappropriate Capability

High

• Confidence: 99% confidence
• Finding: The recommended-pricing section explicitly supports paid actions such as upvotes, follows, comments, reviews, account creation, and other coordinated engagement across third-party platforms. This goes beyond a neutral payroll tool and operationalizes deceptive amplification, likely violating platform rules and enabling fraud, spam, fake reviews, and inauthentic influence campaigns at scale.

Natural-Language Policy Violations

High

• Confidence: 99% confidence
• Finding: The skill content promotes deceptive growth-hacking tasks without meaningful safeguards, such as paid comments, likes, follows, and reviews. In context, this is not an incidental example; it functions as a playbook for using the platform to coordinate inauthentic behavior on third-party services.

Ssd 4

High

• Confidence: 99% confidence
• Finding: Normalizing detailed price lists for activities like account creation, upvotes, likes, comments, follows, and reviews materially lowers the barrier to conducting coordinated manipulation campaigns. The specificity of the pricing guidance makes the platform more dangerous by turning abuse patterns into a standardized commercial service.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

Scale your workforce instantly. Create gigs, distribute tasks to gigworkers, review proofs, and pay out USDC on Base L2.

- **Create Gigs** — Post tasks with USDC funding. Set price per proof, review timeouts, and distribution mode.
- **Review Proofs** — Approve or reject submissions with a single click. Auto-approve after timeout protects gigworkers.
- **Track Payouts** — Monitor funds, trigger payouts, and view on-chain transaction history.

### For Gigworkers

• Confidence: 85% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

Scale your workforce instantly. Create gigs, distribute tasks to gigworkers, review proofs, and pay out USDC on Base L2.

- **Create Gigs** — Post tasks with USDC funding. Set price per proof, review timeouts, and distribution mode.
- **Review Proofs** — Approve or reject submissions with a single click. Auto-approve after timeout protects gigworkers.
- **Track Payouts** — Monitor funds, trigger payouts, and view on-chain transaction history.

### For Gigworkers

• Confidence: 85% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

2. Gigworkers join and receive a personal mailbox
3. Tasks are distributed to mailboxes via email or webhook
4. Gigworkers submit proofs of completed work
5. Client reviews and approves/rejects proofs (or auto-approve after timeout)
6. Approved proofs trigger USDC payouts on Base L2

### Wallets & Gas

• Confidence: 85% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

2. Gigworkers join and receive a personal mailbox
3. Tasks are distributed to mailboxes via email or webhook
4. Gigworkers submit proofs of completed work
5. Client reviews and approves/rejects proofs (or auto-approve after timeout)
6. Approved proofs trigger USDC payouts on Base L2

### Wallets & Gas

• Confidence: 85% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

2. Gigworkers join and receive a personal mailbox
3. Tasks are distributed to mailboxes via email or webhook
4. Gigworkers submit proofs of completed work
5. Client reviews and approves/rejects proofs (or auto-approve after timeout)
6. Approved proofs trigger USDC payouts on Base L2

### Wallets & Gas

• Confidence: 85% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

2. Gigworkers join and receive a personal mailbox
3. Tasks are distributed to mailboxes via email or webhook
4. Gigworkers submit proofs of completed work
5. Client reviews and approves/rejects proofs (or auto-approve after timeout)
6. Approved proofs trigger USDC payouts on Base L2

### Wallets & Gas

• Confidence: 85% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The skill claims to prohibit abuse such as harassment, money laundering, and malware distribution, but elsewhere documents task categories that strongly resemble platform manipulation and deceptive activity. This inconsistency creates a policy loophole: users are told abuse is banned while being given concrete operational guidance for likely abusive campaigns.

External Transmission

Medium

• Category: Data Exfiltration

Content

**HTML payload (Content-Type: text/html or text/plain):**

```bash
curl -X POST "https://staging.dollarplatoon.com/api/inbound/webhook/GIG_01HX...?token=abc123&subject=My+Report" \
  -H "Content-Type: text/html" \
  -d '<h1>Task Details</h1><p>Please complete this task...</p>'
```

• 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.