Back to skill

Security audit

STX Copilot

Security checks for vulnerabilities and agentic risk

Overview

This is a coherent IBM Transformation Extender reference skill, but it includes unsafe operational examples that could expose sensitive financial data or create weak administrative access if copied into real systems.

Review this skill before installing in production-facing workflows. Treat its examples as reference material only: do not enable WTX_DUMP_DATA or TRACE logging on real payment/customer data without approval, redaction, restricted log access, and short retention, and do not copy the admin/secret Launcher user example into any environment.

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 (2)

T09 · Insecure Skill Coding Practices

Error
Location
references/execution.md:67
Finding
Predictable Administrative Credentials and Unsafe Shell Argument Handling<![CDATA[ ## Vulnerability Details **File Location**: `references/execution.md`, line 67 **Vulnerability Type**: Hardcoded weak administrative credentials and unsafe shell command construction **Risk Level**: High ### Vulnerable Code ```bash launcheradmin.sh -adduser user:admin;login:admin;pwd:secret ``` ### Technical Analysis The deployment documentation presents an administrative account creation command containing predictable credentials: the username is `admin` and the password is `secret`. Because the command appears as an executable example without a warning or placeholder notation, an operator may copy it directly into a real environment. The credential specification is also not quoted. In POSIX-compatible shells, semicolons are command separators. The shell may therefore interpret the example as three separate commands: ```bash launcheradmin.sh -adduser user:admin login:admin pwd:secret ``` This can produce an incomplete Launcher account configuration and attempt to execute unintended commands named `login:admin` and `pwd:secret`. Even if a particular execution environment preserves the argument, the resulting administrative password remains publicly known and trivial to guess. ### Attack Path 1. An administrator follows the deployment documentation and copies the example command. 2. If the Launcher accepts the intended credential specification, an administrative account is created with the predictable `admin` / `secret` credentials. 3. The Launcher administration listener is exposed to an attacker through the host network or an incorrectly restricted management interface. 4. The attacker authenticates using the documented credentials. 5. The attacker uses Launcher administrative functions to enumerate, start, stop, import, export, or otherwise manipulate deployed map systems, subject to the privileges granted to the administrative account. Alternatively, shell interpretation of the unquoted semicolons may result in partial account creation o ...[truncated 726 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Remove all usable default credentials from the documentation. - Use explicit placeholders that cannot reasonably be mistaken for production values. - Quote the complete credential argument so shell metacharacters are not interpreted: ```bash launcheradmin.sh -adduser 'user:<role>;login:<unique-admin-name>;pwd:<strong-generated-secret>' ``` - Prefer an interactive password prompt or an approved secret manager instead of placing passwords in command-line arguments. Command-line secrets may be exposed through shell history, process listings, terminal logs, or automation output. - Require a unique, randomly generated password that meets the organization's password policy. - Document immediate rotation if temporary bootstrap credentials must be used. - Restrict the Launcher administration listener to a dedicated management network or localhost where possible. - Apply firewall controls, authentication rate limiting, audit logging, and least-privilege administrative roles. - Add a warning that the example is illustrative and must never be copied unchanged into production. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
references/debugging.md:31
Finding
Financial Message Payloads Can Be Exposed Through Plaintext Diagnostic Logs<![CDATA[ ## Vulnerability Details **File Location**: `references/debugging.md`, lines 31–38; related guidance also appears at lines 87–92 and in `SKILL.md`, lines 180–183 **Vulnerability Type**: Plaintext logging of sensitive input payloads and transformation values **Risk Level**: Medium ### Vulnerable Code ```bash ## Environment Variable Debugging ```bash # Capture input data passed to the map in wtxlogger output export WTX_DUMP_DATA=true # WARNING: produces very large log files in production — use only for diagnosis # Enable verbose ITX runtime logging export DTX_TRACE=1 ``` ``` The configuration example later enables the same behavior together with TRACE logging: ```properties # customer_overrides.properties wtxlogger.level=TRACE wtxlogger.maxFileSize=20MB wtxlogger.maxBackupIndex=5 WTX_DUMP_DATA=true ``` ### Technical Analysis The debugging guidance instructs operators to enable complete input-data capture through `WTX_DUMP_DATA=true` and verbose runtime or value-level tracing. This Skill specifically targets SWIFT MT, ISO 20022, and other financial transformations. Such payloads commonly contain account identifiers, transaction references, customer names, addresses, payment amounts, remittance details, and other regulated or confidential information. The existing warning addresses only large log files. It does not explain that payload contents may be confidential, prohibit use with live production data, require redaction, define restrictive access controls, mandate encrypted storage, or require cleanup after debugging. The associated example configures five 20 MB backup files, potentially retaining multiple copies of sensitive payloads. If logs are forwarded to a centralized logging service, the data may also cross trust boundaries and become visible to a broader set of administrators or support personnel than the original transaction-processing system. ### Attack Path 1. A production transformation fails or produces unexpected output. 2. An ...[truncated 1404 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Keep `WTX_DUMP_DATA`, TRACE logging, and value tracing disabled by default. - Add an explicit warning that these settings may record complete financial messages, credentials embedded in payloads, personal data, and account information. - Prohibit payload dumping in production unless it is approved through a documented incident-response or change-management process. - Prefer synthetic, anonymized, tokenized, or selectively redacted test messages. - Enable error-only tracing before escalating to value-level or complete-payload capture. - Limit diagnostic logging to the shortest possible period and document commands for immediately disabling it afterward. - Apply restrictive ownership and file permissions to all generated logs. - Encrypt diagnostic logs at rest and in transit, including logs sent to centralized monitoring platforms. - Prevent sensitive diagnostic logs from entering general-purpose telemetry, support bundles, backups, or ticket attachments. - Configure short retention and securely delete local files and retained backups after troubleshooting. - Record who enabled payload logging, why it was enabled, and when it was disabled. - Add masking controls for account numbers, customer names, addresses, identifiers, and remittance information where supported. - Update the example so that sensitive payload dumping is visibly disabled in persistent configuration: ```properties wtxlogger.level=INFO WTX_DUMP_DATA=false ``` ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (6)

Vague Triggers

High
Confidence
98% confidence
Finding
The skill explicitly says 'When in doubt, trigger,' which encourages unnecessary invocation beyond clear user intent. Over-broad activation increases the chance that unrelated user data or prompts are routed into a specialized finance/integration skill, causing context over-collection, privacy exposure, and confused or unsafe task execution.

Missing User Warnings

Medium
Confidence
87% confidence
Finding
The debugging guidance recommends enabling WTX_DUMP_DATA to capture input data in logs, but the warning is minimal and not actionable for sensitive financial/integration payloads. In this skill's context, inputs may include SWIFT, ISO 20022, COBOL, or other production message data containing regulated or confidential information, so logging raw payloads can create material data leakage risk.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The documentation instructs users to enable `WTX_DUMP_DATA=true`, which causes full input data to be written to logs. In an ITX/WTX context, inputs often contain financial, EDI, COBOL, or other sensitive business payloads, so this can expose regulated or confidential data to persistent log storage and any systems or personnel with log access.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The `customer_overrides.properties` example includes `WTX_DUMP_DATA=true` in a persistent logging configuration without a nearby privacy/security warning. Because this example is likely to be copied into real environments, it increases the risk of ongoing sensitive data leakage into application logs, especially in production B2B and financial transformation deployments.

Vague Triggers

Medium
Confidence
91% confidence
Finding
The document says the Launcher activates execution based on events such as file arrival, MQ message, HTTP request, or schedule, but it does not define what specific events, endpoints, message patterns, or filters should trigger a run. In markdown documentation, this kind of broad invocation description can create ambiguity about when the skill should activate versus when it should not.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The documentation shows `launcheradmin.sh -adduser user:admin;login:admin;pwd:secret`, which normalizes embedding plaintext credentials directly in command lines. Command-line secrets can be exposed through shell history, process listings, logs, screenshots, and copied documentation, increasing the chance of credential disclosure and insecure reuse in real deployments.

Static analysis

No suspicious patterns detected.