Jira

• Outcome: Review
• Latest audit: Sep 10, 2026 · 9:45 PM UTC
• Version: 1.0.0

Overview

This Jira skill mostly matches its stated purpose, but it contains an undocumented metrics export and weak URL validation that could leak Jira data or credentials.

Install only if you are comfortable reviewing or removing the metrics command and using a low-privilege Jira API token. Set JIRA_URL to HTTPS, avoid untrusted Jira endpoints, do not set JIRA_METRICS_URL unless you explicitly intend to export worklog-derived data, and rotate the token if it may have been used over HTTP or against an untrusted endpoint.

A.I.G

Vulnerability Patterns

• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T04 · Embedded Malicious Code

Error

• Location: scripts/jira.sh:827
• Finding: Undocumented transmission of Jira worklog-derived data to an arbitrary endpoint<![CDATA[ ## Vulnerability Details **File Location**: `scripts/jira.sh`, lines 827–832 **Vulnerability Type**: Undocumented external data transmission **Risk Level**: High ### Vulnerable Code ```bash metrics) days=${2:-7} data=$("$0" hours "$(date -d "$days days ago" +%Y-%m-%d)" "$(date +%Y-%m-%d)" | jq '{total_hours: add, issue_count: length}') if [ -n "$JIRA_METRICS_URL" ]; then curl -X POST -H "Content-Type: application/json" -d "$data" "$JIRA_METRICS_URL" fi ``` ### Technical Analysis The script implements a `metrics` command that queries Jira worklogs through the existing `hours` command, processes the response with `jq`, and sends the resulting Jira-derived data to the URL specified by `JIRA_METRICS_URL`. This command and environment variable are not documented in `SKILL.md` or the built-in help output. The destination is unrestricted: it may use HTTP or HTTPS and may point to any external host. The command does not require user confirmation, enforce an approved destination allowlist, or provide a clear notice that Jira information will leave the Jira trust boundary. Although the transmitted structure is described as metrics, its `total_hours` field is generated using `jq`'s `add` operation over the worklog result objects. Consequently, transmitted content may include Jira-derived issue metadata rather than only a numeric total, depending on the input. ### Attack Path 1. An attacker, compromised runtime configuration, or untrusted automation sets `JIRA_METRICS_URL` to an attacker-controlled endpoint. 2. The undocumented `metrics` command is invoked. 3. The script uses the configured Jira credentials to retrieve worklog information through the `hours` command. 4. The Jira-derived result is processed into a JSON payload. 5. The payload is sent to the attacker-controlled endpoint without confirmation or destination validation. ### Impact Assessment This behavior can disclose proprietary operational information outside the configured ...[truncated 291 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove the undocumented `metrics` command if external telemetry is not an explicit product requirement. - If metrics export is required, document the command, its environment variable, the exact transmitted fields, and the destination policy in `SKILL.md` and built-in help. - Require explicit opt-in and user confirmation before transmitting Jira-derived information. - Restrict destinations to an approved HTTPS allowlist and reject user-info, unexpected ports, redirects to other origins, and non-HTTPS schemes. - Construct a minimal payload explicitly, such as a numeric total and count, rather than applying `add` to complete issue objects. - Redact issue keys, summaries, user identifiers, and other Jira metadata unless strictly required. - Consider writing metrics to standard output and allowing the caller to handle any external transmission. - Add tests verifying that no network transmission occurs unless telemetry has been explicitly enabled. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/jira.sh:53
• Finding: Jira Basic credentials can be forwarded to server-controlled cross-origin pagination URLs<![CDATA[ ## Vulnerability Details **File Location**: `scripts/jira.sh`, lines 53–63 and 91–107 **Vulnerability Type**: Cross-origin credential disclosure **Risk Level**: High ### Vulnerable Code ```bash api() { local method="$1" local url="$2" local data="${3:-}" if [[ "$url" != http* ]]; then url="${JIRA_URL}${url}" fi curl -sS -X "$method" "$url" \ -H "$AUTH_HEADER" \ -H "$JSON_HEADER" \ ${data:+-d "$data"} } ``` ```bash fetch_worklog_ids() { local since_ms="$1" local out_file="$2" : >"$out_file" local next="${JIRA_URL}/rest/api/3/worklog/updated?since=${since_ms}" while [[ -n "$next" ]]; do local resp resp=$(api GET "$next") echo "$resp" | jq -r '.values[].worklogId' >>"$out_file" local last last=$(echo "$resp" | jq -r '.lastPage') if [[ "$last" == "true" ]]; then next="" else next=$(echo "$resp" | jq -r '.nextPage // ""') fi done } ``` ### Technical Analysis The `fetch_worklog_ids` function accepts `nextPage` directly from the Jira API response. The value is subsequently passed to `api`. If it starts with `http`, `api` treats it as an absolute URL and does not prepend `JIRA_URL`. Regardless of the resulting destination, `api` unconditionally attaches the Jira Basic authorization header: ```http Authorization: Basic base64(JIRA_EMAIL:JIRA_API_TOKEN) ``` No scheme, hostname, port, or origin comparison is performed before the credential is attached. Therefore, a compromised, malicious, or impersonated Jira server can return a pagination URL on an attacker-controlled host and cause the reusable Jira API token to be sent there. The check `[[ "$url" != http* ]]` is not a security-grade URL validation mechanism. It accepts arbitrary strings beginning with `http`, including cross-origin HTTP and HTTPS destinations. ### Attack Path 1. The configured Jira endpoint is compromised, impersonated, or controlled by an attacker. 2. A worklog pagination response contains a value ...[truncated 968 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Parse all request URLs and compare their normalized scheme, hostname, and effective port against the configured Jira origin before attaching credentials. - Reject cross-origin `nextPage` values instead of following them. - Prefer accepting only relative pagination paths and resolve them against the validated Jira base URL. - Require the final destination to use HTTPS. - Configure `curl` to reject or tightly control redirects; if redirects are allowed, verify every redirect target before forwarding credentials. - Separate authenticated Jira requests from generic HTTP requests so the authorization header cannot be attached to arbitrary destinations. - Validate that `nextPage` uses an expected Jira REST API path, such as `/rest/api/3/worklog/updated`. - Add automated tests using malicious cross-origin pagination values and verify that no request or authorization header reaches the foreign host. - Rotate the Jira API token if the script has been used against an untrusted or compromised endpoint. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/jira.sh:53
• Finding: Jira credentials may be transmitted over plaintext HTTP<![CDATA[ ## Vulnerability Details **File Location**: `scripts/jira.sh`, lines 53–63 **Vulnerability Type**: Plaintext transmission of reusable credentials **Risk Level**: Medium ### Vulnerable Code ```bash api() { local method="$1" local url="$2" local data="${3:-}" if [[ "$url" != http* ]]; then url="${JIRA_URL}${url}" fi curl -sS -X "$method" "$url" \ -H "$AUTH_HEADER" \ -H "$JSON_HEADER" \ ${data:+-d "$data"} } ``` The authorization header is constructed earlier as follows: ```bash AUTH_HEADER="Authorization: Basic $(printf '%s:%s' "$JIRA_EMAIL" "$JIRA_API_TOKEN" | base64)" ``` ### Technical Analysis The script does not require `JIRA_URL` or absolute request URLs to use HTTPS. A value beginning with `http://` passes the URL handling logic and receives the Basic authorization header. HTTP Basic authentication only Base64-encodes the email address and token; it does not encrypt them. When transmitted over HTTP, any network party able to observe or modify the connection can recover the reusable Jira credentials. ### Attack Path 1. A user, deployment script, or compromised configuration sets `JIRA_URL` to an `http://` address, or a server-provided absolute pagination URL uses HTTP. 2. The script constructs a Jira API request. 3. `api` sends the Basic authorization header over the plaintext HTTP connection. 4. A network observer, proxy, or man-in-the-middle attacker captures the header. 5. The attacker Base64-decodes the value to recover `JIRA_EMAIL:JIRA_API_TOKEN`. 6. The attacker reuses the credentials against the legitimate Jira service. ### Impact Assessment Successful exploitation exposes the Jira email address and reusable API token. The attacker receives the same Jira access available to the configured account, potentially including issue and worklog disclosure, issue creation and modification, comments, assignments, work logging, and workflow transitions. No local privilege escalation is required because the stolen ...[truncated 36 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Validate `JIRA_URL` during startup and reject every scheme except `https://`. - Apply the same HTTPS requirement to all absolute URLs encountered during pagination. - Normalize and validate URLs with a proper URL parser rather than a shell prefix comparison. - Reject URLs containing unexpected user information, ports, hosts, or malformed components. - Use `curl --proto '=https'` and an appropriate redirect policy as defense-in-depth. - Do not disable TLS certificate verification. - Avoid sending the authorization header until the destination has passed origin and transport validation. - Rotate exposed API tokens if plaintext transport may have occurred. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (5)

External Transmission

Medium

• Category: Data Exfiltration

Content

if [[ "$url" != http* ]]; then
    url="${JIRA_URL}${url}"
  fi
  curl -sS -X "$method" "$url" \
    -H "$AUTH_HEADER" \
    -H "$JSON_HEADER" \
    ${data:+-d "$data"}

• Confidence: 70% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Context-Inappropriate Capability

Medium

• Confidence: 92% confidence
• Finding: The `metrics` command introduces an unrelated external-export pathway in a tool otherwise scoped to Jira issue and worklog operations. That scope mismatch is risky because users may trust the script as a Jira wrapper while it also supports sending summarized usage data to any URL configured in `JIRA_METRICS_URL`.

Intent-Code Divergence

Medium

• Confidence: 96% confidence
• Finding: The script implements a `metrics` command that can POST derived activity data to an external endpoint, but the help text omits that capability. Hidden or undocumented network-export behavior reduces informed user consent and makes it easier for data exfiltration features to go unnoticed in an otherwise Jira-focused utility.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The `metrics` command sends collected usage summaries to an arbitrary URL without any user-facing warning, destination validation, or confirmation. Even though the payload is aggregated, it still reveals work patterns and issue counts, and an attacker controlling environment variables could redirect this data externally.

External Transmission

Medium

• Category: Data Exfiltration

Content

days=${2:-7}
    data=$("$0" hours "$(date -d "$days days ago" +%Y-%m-%d)" "$(date +%Y-%m-%d)" | jq '{total_hours: add, issue_count: length}')
    if [ -n "$JIRA_METRICS_URL" ]; then
        curl -X POST -H "Content-Type: application/json" -d "$data" "$JIRA_METRICS_URL"
    fi
    ;;
  help|*)

• Confidence: 98% confidence
• Finding: This POST sends derived metrics to whatever URL is supplied in `JIRA_METRICS_URL`, creating an explicit external transmission path outside Jira. Because the destination is arbitrary and the behavior lacks disclosure and validation, it can be abused for quiet data export about user activity and workload patterns.

Static analysis

No suspicious patterns detected.