T09 · Insecure Skill Coding Practices
- Location
scripts/jira-pat.sh:13- Finding
Jira Personal Access Token Can Be Sent to an Untrusted or Insecure Destination
- Content
View full analysis
Vulnerability Details
File Location:
scripts/jira-pat.sh:13-17, 21-24, 37-41, 76-84, 89-99
Vulnerability Type: Unrestricted credential destination and insecure transport
Risk Level: MediumVulnerable Code
bash check_env() { if [[ -z "${JIRA_PAT:-}" ]]; then echo "Error: JIRA_PAT environment variable not set" >&2 exit 1 fi if [[ -z "${JIRA_URL:-}" ]]; then echo "Error: JIRA_URL environment variable not set" >&2 exit 1 fi } jira_get() { check_env local issue_key="$1" curl -s -H "Authorization: Bearer $JIRA_PAT" \ "$JIRA_URL/rest/api/2/issue/$issue_key" | jq } jira_search() { check_env local jql="$1" curl -s -H "Authorization: Bearer $JIRA_PAT" \ "$JIRA_URL/rest/api/2/search?jql=$jql" | \ jq '.issues[] | "\(.key): \(.fields.summary) [\(.fields.status.name)]"' -r } curl -s -X POST \ -H "Authorization: Bearer $JIRA_PAT" \ -H "Content-Type: application/json" \ -d "$payload" \ "$JIRA_URL/rest/api/2/issue/$issue_key/transitions" curl -s -X POST \ -H "Authorization: Bearer $JIRA_PAT" \ -H "Content-Type: application/json" \ -d "$(jq -n --arg body "$body" '{body: $body}')" \ "$JIRA_URL/rest/api/2/issue/$issue_key/comment" | jqThe same unsafe pattern also appears in the documented commands in
SKILL.md:20-30, 36-51, 68-69, 75-86, 92-97, 103-114, 120-133.Technical Analysis
The helper validates only that
JIRA_URLis nonempty. It does not require HTTPS, verify that the host is an approved Jira instance, or reject a URL containing an unexpected scheme, host, port, credentials, query, or fragment.Every operation places the privileged
JIRA_PATvalue in an HTTPAuthorizationheader and sends it to the origin selected throughJIRA_URL. Network access and Bearer authentication are necessary for the declared Jira-management functionality, but allowing the credential destination to remain unrestricted exceeds minimum safe privilege.If
JIRA_URLis accidentally or m ...[truncated 1789 chars]- Remediation
View remediation
Remediation Suggestions
- Parse and validate
JIRA_URLbefore making any request:- Require the
httpsscheme. - Reject embedded credentials, fragments, and malformed URLs.
- Reject unexpected ports unless explicitly approved.
- Normalize the URL and remove trailing slashes.
- Require the
- Restrict the destination hostname through an administrator-controlled allowlist or immutable configuration. Do not rely solely on an environment variable that untrusted processes or wrappers may influence.
- Ensure the validated origin exactly matches the origin receiving the Authorization header. Do not concatenate credentials into arbitrary user-provided URLs.
- Preserve TLS certificate verification and do not introduce
curl -kor--insecure. - Configure
curlto fail safely and expose HTTP errors without printing credentials, for example by using--fail-with-body --silent --show-error. - Document that
JIRA_URLis security-sensitive configuration and must come from a trusted source. - Use a short-lived, revocable PAT with only the Jira permissions required for the intended read or write operations.
- Apply equivalent validation guidance to every command example in
SKILL.md.
A validation routine should fail closed before any network request, for example:
bash validate_jira_url() { case "$JIRA_URL" in https://issues.example.com|https://issues.example.com/) JIRA_URL="${JIRA_URL%/}" ;; *) echo "Error: JIRA_URL must be the approved HTTPS Jira origin" >&2 exit 1 ;; esac }For deployments requiring multiple Jira instances, use a securely maintained allowlist rather than accepting every HTTPS hostname.
- Parse and validate
