T09 · Insecure Skill Coding Practices
- Location
scripts/jira.py:24- Finding
Jira credentials can be transmitted to an arbitrary or plaintext destination
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This Jira skill is mostly coherent, but it can make live Jira changes and can send Jira API credentials to an unvalidated URL configured in the environment.
Review before installing. Use this only with a narrowly permissioned Jira API token, set JIRA_BASE_URL only to your HTTPS Atlassian tenant, and treat all create, update, comment, transition, worklog, raw API, link, and attachment examples as live Jira changes that should be explicitly approved.
scripts/jira.py:24Jira credentials can be transmitted to an arbitrary or plaintext destination
Credentials or environment variables flow to a network sink. This is a high-confidence indicator of credential exfiltration.
req = Request(url, data=body, headers=headers, method=method)
try:
with urlopen(req) as resp:
content = resp.read().decode()
return json.loads(content) if content else {}
except HTTPError as e:
The skill documents use of environment variables and outbound network access to Jira, but it does not declare any tool scope such as permissions or allowed-tools. That omission weakens execution guardrails and can allow the skill to be invoked with broader capabilities than users or the platform expect, especially because it can read credentials from the environment and perform remote actions.
The trigger language is very broad, including phrases like any Atlassian Jira Cloud task, which increases the chance of unintended invocation. In a skill that can create, update, transition, comment on issues, and log work, accidental activation can lead to unintended changes in production project data.
The description advertises issue creation and updates but does not clearly warn that these operations modify remote Jira data. This is dangerous because users may treat the skill as informational while it is actually capable of making authenticated state changes in an external system.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
"$JIRA_BASE_URL/rest/api/3/issue/PROJ-123" | jq .
# POST request
curl -s -X POST -u "$JIRA_USER_EMAIL:$JIRA_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"body": {"type": "doc", "version": 1, "content": [{"type": "paragraph", "content": [{"type": "text", "text": "Comment"}]}]}}' \
"$JIRA_BASE_URL/rest/api/3/issue/PROJ-123/comment" | jq .
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# Create link
curl -X POST -u "$JIRA_USER_EMAIL:$JIRA_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"type": {"name": "Blocks"},
The skill exposes state-changing Jira operations such as create, update, comment, transition, and worklog without any confirmation, dry-run mode, or user-visible warning before execution. In an agent setting, ambiguous prompts, prompt injection from issue content, or mistaken tool selection could cause unintended writes to production Jira data, workflow changes, or audit-affecting worklog entries.
The authentication section instructs users to supply an account email and API token but provides no warning about protecting those credentials or avoiding logging and sharing them. While this is standard for Jira API usage, omitting basic credential-handling guidance increases the risk of accidental exposure.
No suspicious patterns detected.