Back to skill

Security audit

Jiraandconfluence Skill

Security checks for vulnerabilities and agentic risk

Overview

The skill’s Jira and Confluence purpose is clear, but its helper scripts handle credentials in a way that can unexpectedly execute a local file and expose tokens to local process inspection.

Review before installing. Use least-privilege read-only Atlassian tokens, run the scripts only from a trusted directory, and avoid any environment where another user or monitoring system can inspect process command lines. The publisher should anchor auth.sh to the script directory and use a safer secret-passing mechanism for curl before this is treated as low risk.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (4)

T09 · Insecure Skill Coding Practices

Error
Location
scripts/jira_reader.sh:5
Finding
Working-Directory-Dependent Sourcing Allows Arbitrary Code Execution in Jira Reader<![CDATA[ ## Vulnerability Details **File Location**: `scripts/jira_reader.sh`, lines 5-7 **Vulnerability Type**: Unsafe shell script sourcing **Risk Level**: High ### Vulnerable Code ```bash # Source authentication if [[ -f "../scripts/auth.sh" ]]; then source ../scripts/auth.sh fi ``` ### Technical Analysis The relative path `../scripts/auth.sh` is resolved from the caller's current working directory, not from the directory containing `jira_reader.sh`. An attacker who can create a file at that relative location can cause the script to source and execute attacker-controlled shell commands. Because `source` executes the target file in the current shell context, malicious code inherits the invoking user's privileges and can access the user's environment, including exported API tokens. The sourcing operation also occurs before argument validation. The documented project-root invocation does not reliably load the packaged authentication script because `../scripts/auth.sh` points outside the project when the current working directory is the project root. ### Attack Path 1. An attacker identifies or influences the directory from which the victim will invoke `jira_reader.sh`. 2. The attacker creates a malicious `../scripts/auth.sh` relative to that working directory. 3. The victim invokes the Jira reader using an absolute or relative path. 4. The script confirms that the attacker-controlled file exists and sources it. 5. The malicious commands execute with the victim's operating-system privileges and can read exported credentials or modify files accessible to the victim. ### Impact Assessment Successful exploitation provides arbitrary shell command execution with the privileges of the user running the reader. The attacker may access exported Jira and Confluence tokens, read or modify user-accessible files, invoke network tools, and perform any other action permitted to that user. This issue does not independently elevate privileges beyond those of the inv ...[truncated 156 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Resolve `auth.sh` relative to the executing script rather than the current working directory: ```bash set -euo pipefail SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)" AUTH_FILE="$SCRIPT_DIR/auth.sh" if [[ ! -f "$AUTH_FILE" ]]; then printf 'Error: authentication script not found.\n' >&2 exit 1 fi source "$AUTH_FILE" ``` Additionally: - Ensure the installation directory and `auth.sh` are owned by a trusted account and are not writable by untrusted users. - Fail closed when the expected authentication script is missing. - Validate arguments before performing operations that are not required for argument handling. - Consider eliminating executable configuration sourcing entirely; use a non-executable configuration format if only data must be loaded. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
scripts/confluence_reader.sh:5
Finding
Working-Directory-Dependent Sourcing Allows Arbitrary Code Execution in Confluence Reader<![CDATA[ ## Vulnerability Details **File Location**: `scripts/confluence_reader.sh`, lines 5-7 **Vulnerability Type**: Unsafe shell script sourcing **Risk Level**: High ### Vulnerable Code ```bash # Source authentication if [[ -f "../scripts/auth.sh" ]]; then source ../scripts/auth.sh fi ``` ### Technical Analysis The relative path `../scripts/auth.sh` is interpreted relative to the process's current working directory. It is not anchored to the directory containing `confluence_reader.sh`. This permits an attacker-controlled file at the resolved path to be loaded as executable shell code. The `source` built-in executes commands in the current shell and gives them access to the reader's environment. This includes any Jira or Confluence credentials exported before invocation. The file is sourced before the supplied page reference is validated. ### Attack Path 1. An attacker creates a malicious `../scripts/auth.sh` relative to a directory where the victim is expected to run the reader. 2. The victim invokes `confluence_reader.sh` from that directory. 3. The file existence check succeeds for the attacker's file. 4. The script sources the malicious file. 5. Attacker-selected commands execute as the victim and can access environment variables and user-accessible resources. ### Impact Assessment The attacker can execute arbitrary shell commands with the invoking user's privileges. Potential consequences include disclosure of Atlassian credentials, theft or modification of local data, and network actions performed under the victim's account. No privilege escalation beyond the invoking user's permissions is inherent in this flaw. The exploit depends on the attacker being able to control the resolved relative file or the working-directory context. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions Anchor the authentication script path to the reader's own directory and reject missing or unexpected files: ```bash set -euo pipefail SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)" AUTH_FILE="$SCRIPT_DIR/auth.sh" if [[ ! -f "$AUTH_FILE" ]]; then printf 'Error: authentication script not found.\n' >&2 exit 1 fi source "$AUTH_FILE" ``` Further hardening should include: - Restricting write permissions on the script installation directory. - Verifying that deployment does not permit untrusted users to replace `auth.sh`. - Avoiding executable configuration files where a data-only configuration mechanism is sufficient. - Validating command-line arguments before unnecessary initialization. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/jira_reader.sh:20
Finding
Jira API Credential Exposed Through Curl Process Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/jira_reader.sh`, lines 20-24 **Vulnerability Type**: Sensitive credential exposure in command-line arguments **Risk Level**: Medium ### Vulnerable Code ```bash # Make API request curl -s \ -H "Authorization: Basic ${JIRA_API_TOKEN}" \ -H "Content-Type: application/json" \ "${JIRA_API_URL}" | jq '.' ``` ### Technical Analysis The Jira credential is expanded directly into a `curl` command-line argument. While the request is running, the complete Authorization header may be exposed through process inspection interfaces, diagnostic tooling, process monitoring, or command-line audit logs. The practical visibility of process arguments depends on the operating system and its process-isolation configuration. On systems that allow other local users, administrators, monitoring agents, or container peers to inspect command lines, the credential can be captured and replayed. ### Attack Path 1. The victim invokes `jira_reader.sh` with `JIRA_API_TOKEN` set. 2. The script expands the credential into the `curl` argument list. 3. During a sufficiently long-running request, a local observer or monitoring system captures the `curl` process command line. 4. The observer extracts the Authorization value. 5. The credential is replayed against the associated Atlassian service. ### Impact Assessment An attacker who recovers the credential obtains the Jira permissions associated with the token and account. Based on the intended scope, this may expose issue metadata, descriptions, comments, and other Jira data readable by that account. If the supplied credential has broader permissions than recommended, the impact expands accordingly. This finding requires local process-inspection or logging access and does not itself grant operating-system privilege escalation. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions Avoid placing Authorization values in process arguments. Supply sensitive curl configuration through a protected file or another secret-aware mechanism. For a temporary configuration file: 1. Create it using `mktemp`. 2. Immediately restrict permissions to `0600`. 3. Register a trap to delete it on normal exit and signals. 4. Store the Authorization header in the file. 5. Invoke `curl --config "$CONFIG_FILE"` without including the credential in its arguments. Illustrative pattern: ```bash CURL_CONFIG="$(mktemp)" chmod 600 "$CURL_CONFIG" trap 'rm -f -- "$CURL_CONFIG"' EXIT HUP INT TERM printf 'header = "Authorization: Basic %s"\n' "$JIRA_API_TOKEN" > "$CURL_CONFIG" printf 'header = "Content-Type: application/json"\n' >> "$CURL_CONFIG" curl --silent --show-error --fail \ --config "$CURL_CONFIG" \ "$JIRA_API_URL" | jq '.' ``` Also enforce least-privilege Jira permissions, rotate exposed tokens, avoid verbose shell tracing, and configure host process visibility so unrelated users cannot inspect process metadata. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/confluence_reader.sh:20
Finding
Confluence API Credential Exposed Through Curl Process Arguments<![CDATA[ ## Vulnerability Details **File Location**: `scripts/confluence_reader.sh`, lines 20-24 **Vulnerability Type**: Sensitive credential exposure in command-line arguments **Risk Level**: Medium ### Vulnerable Code ```bash # Make API request curl -s \ -H "Authorization: Basic ${CONFLUENCE_API_TOKEN}" \ -H "Content-Type: application/json" \ "${CONFLUENCE_API_URL}" | jq '.' ``` ### Technical Analysis The Confluence credential is interpolated into the command-line argument used for the HTTP Authorization header. Process command lines may be visible to local users with applicable inspection permissions, privileged monitoring software, audit systems, or other processes sharing an insufficiently isolated execution environment. Because the credential is transmitted as part of the argument vector, it can remain observable for the lifetime of the `curl` process. Operating-system hardening may reduce exposure but does not make command-line arguments an appropriate secret transport mechanism. ### Attack Path 1. The victim runs `confluence_reader.sh` with `CONFLUENCE_API_TOKEN` set. 2. The shell expands the token into the `curl` argument vector. 3. A local observer captures the process command line while the request is active or obtains it from process-monitoring logs. 4. The observer extracts the Authorization value. 5. The recovered credential is used to access Confluence as the associated account. ### Impact Assessment Credential compromise grants the attacker the Confluence access assigned to the token and account. This can expose page titles, page bodies, version information, and other content available to that identity. Broader token permissions would correspondingly increase the affected scope. Exploitation requires access to process metadata or relevant logs. The flaw does not directly provide additional operating-system privileges. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions Do not pass the Confluence Authorization header directly through the argument vector. Use a secret-aware client facility or a temporary curl configuration file protected with mode `0600` and deleted using a signal-safe cleanup trap. Illustrative pattern: ```bash CURL_CONFIG="$(mktemp)" chmod 600 "$CURL_CONFIG" trap 'rm -f -- "$CURL_CONFIG"' EXIT HUP INT TERM printf 'header = "Authorization: Basic %s"\n' "$CONFLUENCE_API_TOKEN" > "$CURL_CONFIG" printf 'header = "Content-Type: application/json"\n' >> "$CURL_CONFIG" curl --silent --show-error --fail \ --config "$CURL_CONFIG" \ "$CONFLUENCE_API_URL" | jq '.' ``` Additional controls should include: - Restricting the token to read-only, least-privilege access. - Rotating credentials suspected of prior exposure. - Disabling shell tracing around secret-handling code. - Restricting cross-user process inspection and protecting monitoring logs. - Ensuring temporary files are never created with permissive default access. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (2)

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The script performs an HTTP request to Confluence and includes an Authorization header populated from CONFLUENCE_API_TOKEN. While the code comments mention authentication, there is no user-facing warning, confirmation, or explicit disclosure that credentials and requested page data will be sent over the network.

Missing User Warnings

Medium
Confidence
89% confidence
Finding
This code performs a network request to Jira and sends an authorization token in the request headers, but there is no user-facing disclosure beyond an internal comment. The script prints usage information only and does not warn that it will contact an external service using configured credentials.

Static analysis

No suspicious patterns detected.