T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:38
- Finding
- WordPress Basic Authentication Credentials May Be Sent Without Enforced TLS<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 38–50 **Vulnerability Type**: Credentials transmitted to a user-supplied network destination without mandatory HTTPS validation **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown ### Step 1 — Authenticate **Required credentials**: - `site_url`: e.g., `https://example.com` (no trailing slash) - `username`: WP admin username - `app_password`: Application Password from WP Admin → Users → Profile → Application Passwords **Auth header**: ``` Authorization: Basic base64(username:app_password) ``` **Test connection**: ``` GET {site_url}/wp-json/wp/v2/users/me ``` ``` ### Technical Analysis The Skill instructs the Agent to construct an HTTP Basic Authentication header from the WordPress username and Application Password, then send it to a user-provided `site_url`. Although the example uses HTTPS, the instructions do not require the `https://` scheme, reject plaintext HTTP, validate the hostname, or prohibit forwarding the authorization header through cross-origin redirects. Base64 encoding is not encryption. If the supplied endpoint uses HTTP, the username and Application Password can be read by an on-path attacker. If the URL or redirect destination is attacker-controlled, the credentials can be delivered directly to an unintended server. This network access is necessary for the declared WordPress publishing function, but unrestricted destination selection and the absence of mandatory transport security exceed the minimum safe privileges required. ### Attack Path 1. An attacker or untrusted workflow supplies an `http://` WordPress URL or an HTTPS endpoint that redirects to another origin. 2. The Agent follows the Skill and creates `Authorization: Basic base64(username:app_password)`. 3. The Agent sends the connection test or publishing request to that endpoint. 4. The credential is exposed over plaintext transport or delivered to the attacker-controlled destination. 5. The a ...[truncated 789 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Require `site_url` to use HTTPS and reject all plaintext HTTP destinations before constructing an authorization header. 2. Canonicalize and validate the hostname against a user-confirmed or configured allowlist. 3. Disable automatic redirects for authenticated requests, or strip `Authorization` whenever the scheme, hostname, or port changes. 4. Resolve and display the final authentication origin for explicit confirmation before sending credentials. 5. Use a dedicated WordPress account with only the capabilities needed to publish posts and upload media. 6. Use a separate, revocable Application Password for this workflow rather than an administrator credential. 7. Prevent credentials from appearing in logs, error messages, command histories, or progress output. 8. Document certificate-validation failures as fatal; do not permit insecure TLS bypasses. ]]>