T09 · Insecure Skill Coding Practices
Error
- Location
- references/coolify-api.md:14
- Finding
- Coolify bearer token transmitted over unencrypted HTTP to a hardcoded public endpoint<![CDATA[ ## Vulnerability Details **File Location**: `references/coolify-api.md`, lines 14, 69–70, 75–76, and 81–82 **Vulnerability Type**: Cleartext transmission of privileged credentials and use of an unverified hardcoded endpoint **Risk Level**: High ### Vulnerable Code ```bash coolify context add default http://217.77.2.59:8000 '<token>' --default ``` ```bash curl -H "Authorization: Bearer <token>" http://<host>:8000/api/v1/applications ``` ```bash curl -X POST -H "Authorization: Bearer <token>" \ "http://217.77.2.59:8000/api/v1/deploy?uuid=<app-uuid>" ``` ```bash curl -X DELETE -H "Authorization: Bearer <token>" \ "http://217.77.2.59:8000/api/v1/applications/<app-uuid>" ``` ### Technical Analysis The reference documentation instructs an agent or user to submit a Coolify bearer token over plain HTTP. HTTP provides neither transport encryption nor server authentication. Consequently, the `Authorization` header and other sensitive request data can be observed or modified by an on-path attacker. The context configuration additionally directs credentials to the fixed public IP address `217.77.2.59` without establishing that the endpoint belongs to or has been approved by the user. An operator controlling that endpoint could directly receive the supplied token. Because bearer tokens grant access based solely on possession, an intercepted token can generally be replayed without needing the user's password. Passing the token directly as a command-line argument may also expose it through shell history, process inspection, terminal logs, or automation logs. ### Attack Path 1. A user or agent follows the documented context setup or API examples. 2. A real Coolify bearer token is substituted for the `<token>` placeholder. 3. The token is sent in cleartext to the hardcoded public IP or another HTTP endpoint. 4. A network-positioned attacker, compromised gateway, malicious endpoint operator, or other traffic observer captures the bearer token. 5. The att ...[truncated 1012 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the hardcoded public IP address from all examples and require the user to provide an explicitly approved Coolify endpoint. 2. Require HTTPS for all Coolify CLI and API connections. Examples should use a form such as `https://coolify.example.com` and must not suggest disabling certificate verification. 3. Validate the destination before submitting credentials: - Require explicit user confirmation for newly supplied hosts. - Reject plain HTTP endpoints. - Reject unexpected redirects or hostname changes. - Verify the server certificate and hostname. 4. Do not place tokens directly in command-line arguments. Load credentials from a protected secret store, restricted configuration file, or environment variable supported by the tool. 5. Ensure credential files are readable only by the owning account and are excluded from source control, logs, and generated artifacts. 6. Issue least-privilege, short-lived tokens limited to the required projects and operations. 7. Rotate any real token that may already have been used with these HTTP examples and review Coolify audit logs for unauthorized API activity. 8. Replace the affected examples with secure patterns, for example: ```bash export COOLIFY_TOKEN="$(secure-secret-command)" export COOLIFY_URL="https://coolify.example.com" curl --fail-with-body \ -H "Authorization: Bearer ${COOLIFY_TOKEN}" \ "${COOLIFY_URL}/api/v1/applications" ``` The actual secret-loading mechanism should avoid recording the token in shell history or exposing it in project files. ]]>