Back to skill

Security audit

Polymarket Bots by

Security checks for vulnerabilities and agentic risk

Overview

This skill is purpose-aligned for Dawn trading operations, but it normalizes live trading, funding, and unpinned CLI installation without enough explicit user control or safety framing.

Review this carefully before installing. Use paper mode by default, require explicit confirmation before any funding or `--live` launch, verify budgets and duration, and prefer a pinned or isolated Dawn CLI installation from a trusted source.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:35
Finding
Unpinned Third-Party CLI and Unaudited Installer Execution## Vulnerability Details **File Location**: `SKILL.md`, lines 35–54 **Vulnerability Type**: Unpinned executable dependency and unaudited installation script **Risk Level**: Medium ### Vulnerable Code ```bash npm install -g @dawnai/cli ``` ```bash cd dawn-cli npm install npm run build ./install.sh ``` ### Technical Analysis The installation instructions globally install `@dawnai/cli` without pinning an audited version or integrity hash. Consequently, the code installed depends on whichever package version and transitive dependency graph the npm registry resolves at execution time. npm installation can also execute package lifecycle scripts with the privileges of the invoking user. The alternative local-source workflow does not identify a trusted repository or pin a source commit. It installs dependencies, runs a package-defined build process, and executes `install.sh`. That directory and script are not included in the audited project, so their implementation and security properties cannot be verified from this artifact. This creates a supply-chain trust boundary in which package maintainers, registry availability, transitive dependencies, the local source checkout, and its installer can affect the code ultimately executed. The risk is elevated because the installed CLI is subsequently expected to handle authentication, wallet and funding operations, uploaded strategy code, and live financial transactions. ### Attack Path 1. An attacker compromises the upstream npm package, one of its transitive dependencies, its publisher account, or the source checkout used by the local workflow. 2. The attacker introduces a malicious npm lifecycle hook, build action, or `install.sh` payload. 3. A user follows `SKILL.md` and runs the unpinned installation procedure. 4. npm resolves the compromised release or dependency, or the user executes the compromised local source workflow. 5. The malicious lifecycle hook, build process ...[truncated 1060 chars]
Remediation
## Remediation Suggestions 1. Pin `@dawnai/cli` to a specifically reviewed version rather than installing the registry's current release. 2. Record and verify package integrity information, and retain a lockfile for any local dependency installation. 3. Explicitly document the official npm scope, registry, and source repository to reduce substitution and dependency-confusion risks. 4. Pin the local-source workflow to a reviewed commit or signed release tag and verify its signature or checksum before building. 5. Review and include the contents of `install.sh`, or provide a link to an immutable audited revision, before instructing users to execute it. 6. Prefer a project-local or isolated installation over a global installation, and run installation with the least-privileged account possible. 7. Disable npm lifecycle scripts during dependency retrieval where feasible, then explicitly run only reviewed build steps. 8. Require explicit user confirmation before authentication, funding operations, or any launch using `--live`.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (2)

Missing User Warnings

Medium
Confidence
94% confidence
Finding
This skill explicitly supports live strategy launches and operational trading workflows, including funding and `--live` execution, but it does not require an explicit user confirmation or present a real-money risk warning before those steps. In an agent setting, that omission can lead to unintended placement of live trades or financially consequential actions from an ambiguous or casually phrased user request.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The run checklist and surrounding workflow normalize funding-related actions without a clear warning that they may move or commit user funds. In a tool-using assistant, this increases the chance that account funding or wallet operations are treated as routine setup rather than sensitive financial actions requiring informed consent.

Static analysis

No suspicious patterns detected.