T09 · Insecure Skill Coding Practices
- Location
references/jira.md:5- Finding
Plaintext Jira API Token Embedded Throughout the Skill Package
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This Jira automation skill mostly matches its stated purpose, but it ships a plaintext Jira API token and can mutate Jira and local repositories, so it needs careful review before use.
Do not install this package as-is. The exposed Jira token should be revoked and removed from all files and prior package versions, and the skill should be changed to require secure user-provided credentials, validate the Jira tenant URL, narrow its triggers, and add explicit approval checkpoints before Jira mutations, repo sync, file edits, or test execution.
references/jira.md:5Plaintext Jira API Token Embedded Throughout the Skill Package
scripts/get_issue_info.py:16Jira Credentials Can Be Forwarded to an Arbitrary Configured Server
The skill documentation explicitly expands into local repository discovery, code modification, and test execution, which is materially broader than simple Jira task management. That scope expansion is dangerous because a user invoking a Jira-oriented skill may unintentionally authorize shell execution in local repos, increasing the risk of unintended code changes or execution of project test commands.
The skill documentation explicitly expands into local repository discovery, code modification, and test execution, which is materially broader than simple Jira task management. That scope expansion is dangerous because a user invoking a Jira-oriented skill may unintentionally authorize shell execution in local repos, increasing the risk of unintended code changes or execution of project test commands.
The skill documentation explicitly expands into local repository discovery, code modification, and test execution, which is materially broader than simple Jira task management. That scope expansion is dangerous because a user invoking a Jira-oriented skill may unintentionally authorize shell execution in local repos, increasing the risk of unintended code changes or execution of project test commands.
The skill documentation explicitly expands into local repository discovery, code modification, and test execution, which is materially broader than simple Jira task management. That scope expansion is dangerous because a user invoking a Jira-oriented skill may unintentionally authorize shell execution in local repos, increasing the risk of unintended code changes or execution of project test commands.
The skill documentation explicitly expands into local repository discovery, code modification, and test execution, which is materially broader than simple Jira task management. That scope expansion is dangerous because a user invoking a Jira-oriented skill may unintentionally authorize shell execution in local repos, increasing the risk of unintended code changes or execution of project test commands.
The skill documentation explicitly expands into local repository discovery, code modification, and test execution, which is materially broader than simple Jira task management. That scope expansion is dangerous because a user invoking a Jira-oriented skill may unintentionally authorize shell execution in local repos, increasing the risk of unintended code changes or execution of project test commands.
The skill documentation explicitly expands into local repository discovery, code modification, and test execution, which is materially broader than simple Jira task management. That scope expansion is dangerous because a user invoking a Jira-oriented skill may unintentionally authorize shell execution in local repos, increasing the risk of unintended code changes or execution of project test commands.
The skill documentation explicitly expands into local repository discovery, code modification, and test execution, which is materially broader than simple Jira task management. That scope expansion is dangerous because a user invoking a Jira-oriented skill may unintentionally authorize shell execution in local repos, increasing the risk of unintended code changes or execution of project test commands.
The skill documentation explicitly expands into local repository discovery, code modification, and test execution, which is materially broader than simple Jira task management. That scope expansion is dangerous because a user invoking a Jira-oriented skill may unintentionally authorize shell execution in local repos, increasing the risk of unintended code changes or execution of project test commands.
The file hardcodes a specific Jira email identity as the default account and also embeds a default API token alongside it, meaning anyone who can run or read the skill may inherit real credentials. This can lead to unauthorized access to the Jira tenant, issue creation/modification as that user, credential leakage through source control, and persistent compromise until the secrets are rotated.
The code silently reads sensitive Jira connection parameters and even includes credential defaults without any disclosure, making secret use opaque to operators and increasing the chance of unintended data access. In an agent skill context, this is more dangerous because users may trigger the tool expecting local repo mapping while it actually authenticates to an external service with privileged credentials.
The script embeds a real-looking Jira email and API token as defaults, which exposes sensitive credentials directly in source code. Anyone with access to the skill or repository can reuse those credentials to access Jira, impersonate the account, read or modify tickets, and potentially pivot into broader operational workflows.
The script contains a hardcoded Jira email address and API token as default values, which exposes live credentials to anyone who can read the file or any logs, backups, or distributions containing it. In a Jira automation skill, these credentials enable authenticated access to project data and actions, making the issue especially dangerous because the skill is explicitly designed to read and potentially operate on Jira issues.
The script contains a hardcoded Jira email address and API token as fallback defaults, then immediately uses them to authenticate to a remote Jira instance. Embedding live credentials in source code is a real secret exposure vulnerability: anyone with access to the skill can reuse the token to query or modify Jira data, and the skill context increases risk because this package is explicitly designed to automate Jira operations against a real project.
The script hardcodes a real Jira email address and API token as default values, which exposes live credentials to anyone with access to the code and enables unauthorized authenticated access to the Jira tenant. In the context of an automation skill that can operate on project DS issues, this is especially dangerous because the credential can be reused outside the intended workflow to read, modify, or automate actions against Jira.
The code silently consumes embedded credentials and authenticates to Jira without any user disclosure, meaning anyone invoking the script may unknowingly perform actions using a privileged real account. This masks the use of sensitive authentication material and makes abuse or accidental misuse easier, especially within an agent skill advertised as routine task automation.
The script embeds a real Jira account email and API token as default values, which exposes reusable credentials to anyone who can read the file or logs derived from it. In the context of a Jira automation skill, this is especially dangerous because the secret grants direct authenticated access to a production SaaS tenant and enables unauthorized issue access or modification.
The skill declares required environment variables and documents shell-based scripts, but it does not define an explicit tool scope or allowed-tools boundary. That omission increases the chance an agent can invoke broader shell or environment capabilities than intended, especially given the end-to-end workflow includes repo sync and test execution.
Broad triggers like 'Jira task' or 'work on issue' are ambiguous and may invoke the skill in situations where the user intended only conversation or lightweight lookup. Because this skill can progress into repo operations and code changes, accidental activation carries more risk than a simple informational skill.
The skill reaches beyond Jira into Google Drive-backed templates and configuration, introducing another data source and trust boundary not obvious from the high-level purpose. This increases the attack surface because template content or drive-hosted artifacts could influence issue creation or comments and may expose unrelated sensitive data.
The documented end-to-end workflow goes well beyond Jira management into repository sync, source modification, and repeated test execution. In context, that makes the skill materially more dangerous because a natural-language Jira request can trigger local code operations, branch manipulation, and shell-based testing in a developer environment.
The instruction to follow steps 'without asking unless blocked' promotes autonomous action in a workflow that includes repository syncing, code modification, and test execution. Even though there is one approval gate before proceeding, the skill then allows multiple consequential actions without per-action consent, increasing the chance of unintended changes in the user's environment.
`scripts/sync_repo.py <ISSUE_KEY>` — Finds repo via `references/repos.json`, fetches remote, checks out or creates `feature/<ISSUE_KEY>` branch. Reports `repo_path` and `branch`. Optional: `--branch <name>` to force branch name.
### 8. Full Task Execution Flow (End-to-End)
**Trigger**: "work on DS-XXX", "fix DS-XXX", "pick up DS-XXX". Follow steps in order without asking unless blocked.
1. `get_issue_info.py` → summarize task, acceptance criteria, subtasks.
2. **Confirm with user** — wait for explicit approval before proceeding.
The skill is described as Jira-focused, but the reference file exposes an additional Google Drive resource and folder ID that broadens the agent's accessible data surface without clear justification. Even though a Drive folder ID is not a secret by itself, documenting unrelated external storage in a skill reference can enable unintended data access, exfiltration paths, or prompt-induced use of capabilities outside the declared scope.
The script contains hardcoded fallback Jira credentials, including what appears to be a live API token and email address. If environment variables are absent, the code will use embedded secrets, enabling unauthorized access to the Jira tenant by anyone with code access or logs, and this is especially dangerous in a Jira automation skill that can read and modify project data.
This code sends user-provided comment text and issue identifiers to a remote Jira server via authenticated API calls, but the function and CLI flow provide no confirmation prompt, logging, or explicit warning that data will be transmitted externally. The brief docstrings describe functionality but do not disclose the privacy or remote-transmission aspect of the operation.