Jira Metric
PassAudited by VirusTotal on May 12, 2026.
Overview
Type: OpenClaw Skill Name: jirametric Version: 1.0.0 The `scripts/jira.sh` file contains a critical shell injection vulnerability in the `log_work` function, where the `$hours` argument is directly interpolated into a subshell command for `bc -l`, allowing arbitrary command execution. Additionally, the script includes an undocumented `metrics` command that, if triggered, sends aggregated worklog data (total hours, issue count) to an arbitrary external URL specified by the `JIRA_METRICS_URL` environment variable, posing a hidden data exfiltration risk. The `SKILL.md` does not mention this `metrics` command or the `JIRA_METRICS_URL` variable.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
An agent could be given the ability to change Jira records when the user expected only worklog reporting.
The supplied registry description is metric retrieval, but the skill instructions disclose broader Jira management and write capabilities. This under-description could lead a user to install it expecting read-only analytics.
description: Manage Jira issues, transitions, and worklogs via the Jira Cloud REST API ... status ABC-123 ... assign ABC-123 ... comment ABC-123 ... create "Title" ... log ABC-123
Update the public description and capability metadata to clearly state Jira write access, or split the skill into a read-only metrics skill and a separate issue-management skill.
The agent could change issue status, assignments, comments, created issues, or time logs in Jira, affecting team workflows or reporting.
The helper script implements Jira write operations for transitions, assignees, and worklogs. The artifacts do not show an explicit user-confirmation gate before these business-impacting changes.
resp=$(api POST "/rest/api/3/issue/${issue}/transitions" ...)
resp=$(api PUT "/rest/api/3/issue/${issue}/assignee" ...)
resp=$(api POST "/rest/api/3/issue/${issue}/worklog" ...)Require explicit user confirmation for all write actions, make read-only reporting the default, and add dry-run or preview output before applying Jira mutations.
The agent may act under the user's Jira identity and access or modify more Jira data than the user realizes.
The skill requires a Jira API token and allows an empty project scope to search all accessible Jira data, while the registry metadata declares no required env vars or primary credential.
export JIRA_EMAIL="you@example.com" export JIRA_API_TOKEN="your-api-token" export JIRA_URL="https://your-domain.atlassian.net" # Optional project scope (comma-separated). Empty = search all.
Declare the Jira credential requirement in metadata, use least-privilege credentials where possible, set JIRA_BOARD to an explicit project list, and separate read-only from write-capable credentials.
Users may not see the credential and tool requirements before installing or enabling the skill.
The registry metadata under-declares prerequisites that SKILL.md lists, including local binaries and Jira credential environment variables. No remote install or hidden dependency is shown, but the packaging metadata is incomplete.
Required binaries (all must exist): none ... Required env vars: none ... No install spec — this is an instruction-only skill.
Align registry metadata with SKILL.md by declaring required binaries, required environment variables, and credential expectations.
