Security audit
Security checks for vulnerabilities and agentic risk
The skill appears intended for IBKR portfolio access, but it asks users to trust mutable installers and store brokerage credentials in plaintext while overstating its read-only safety.
Install only after reviewing and pinning the Docker/Gateway dependencies, using paper trading or a least-privilege IBKR setup, and replacing plaintext .env credential storage with a safer secret mechanism or at least strict file permissions. Treat the skill as high-trust financial infrastructure, not just a read-only helper.
SKILL.md:28Remote Docker Installation Script Executed Without Integrity Verification
install.sh:11Unpinned Python Packages and Mutable Third-Party Gateway Repository
The declared description emphasizes a functional read-only IBKR integration offering portfolio data, quotes, historical data, technical analysis, and Telegram alerts. The supplied code chunk does not implement those user-facing capabilities; it only performs environment setup. It also introduces undeclared behaviors such as installing packages and cloning an external repository. While these may support the stated goal, the actual code chunk's primary behavior is installer/bootstrap logic, which is materially different from the declared operational description.
The code is clearly read-only and does connect to IBKR Gateway, matching part of the description. It can retrieve portfolio/account information and market quotes, which aligns with portfolio monitoring and basic stock lookup. However, several prominently declared capabilities are not present in the supplied code: there is no historical data retrieval, no technical analysis, no Telegram integration, and no alerting functionality. Additionally, the quote command explicitly requests market data type 3 (delayed frozen data), which does not fully support the claim of real-time quotes. This is a material description-to-behavior mismatch because the declared purpose significantly overstates the implemented capabilities.
The explicit command chain curl -fsSL ... | sh is a classic remote code execution anti-pattern because it combines network retrieval with immediate shell execution. In the context of a finance integration on a server that may later hold brokerage credentials and expose APIs, compromise of the host could cascade into theft of secrets, market data, and potentially account access.
curl -fsSL https://get.docker.com | sh
docker --version
docker compose version
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
echo "IB Gateway Docker already exists."
fi
# Copy .env template if .env doesn't exist
if [ ! -f "$WORKSPACE/ib-gateway-docker/.env" ]; then
echo "Copying .env template..."
cp "$SKILL_DIR/.env.template" "$WORKSPACE/ib-gateway-docker/.env"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
echo "IB Gateway Docker already exists."
fi
# Copy .env template if .env doesn't exist
if [ ! -f "$WORKSPACE/ib-gateway-docker/.env" ]; then
echo "Copying .env template..."
cp "$SKILL_DIR/.env.template" "$WORKSPACE/ib-gateway-docker/.env"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
echo "IB Gateway Docker already exists."
fi
# Copy .env template if .env doesn't exist
if [ ! -f "$WORKSPACE/ib-gateway-docker/.env" ]; then
echo "Copying .env template..."
cp "$SKILL_DIR/.env.template" "$WORKSPACE/ib-gateway-docker/.env"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
fi
# Copy .env template if .env doesn't exist
if [ ! -f "$WORKSPACE/ib-gateway-docker/.env" ]; then
echo "Copying .env template..."
cp "$SKILL_DIR/.env.template" "$WORKSPACE/ib-gateway-docker/.env"
echo ""
Copying a template into a live .env path for a brokerage gateway establishes a standard plaintext secret storage location that the rest of the toolchain expects to be populated with real credentials. In the context of a financial integration, encouraging credential placement into a local env file increases the risk of accidental exposure through backups, weak permissions, shell history-assisted handling, or later misuse by the cloned third-party container stack.
# Copy .env template if .env doesn't exist
if [ ! -f "$WORKSPACE/ib-gateway-docker/.env" ]; then
echo "Copying .env template..."
cp "$SKILL_DIR/.env.template" "$WORKSPACE/ib-gateway-docker/.env"
echo ""
echo "⚠️ Edit $WORKSPACE/ib-gateway-docker/.env with your IBKR credentials"
The script explicitly instructs the user to edit the .env file with IBKR credentials, which is a direct prompt to place sensitive brokerage authentication material into a local plaintext file. In this skill context, that is particularly dangerous because the credentials unlock financial account access via a gateway container and may be mishandled or later consumed by unreviewed components.
# Copy .env template if .env doesn't exist
if [ ! -f "$WORKSPACE/ib-gateway-docker/.env" ]; then
echo "Copying .env template..."
cp "$SKILL_DIR/.env.template" "$WORKSPACE/ib-gateway-docker/.env"
echo ""
echo "⚠️ Edit $WORKSPACE/ib-gateway-docker/.env with your IBKR credentials"
echo ""
The next-steps guidance explicitly instructs the user to place IBKR credentials into ib-gateway-docker/.env, reinforcing a workflow that stores high-value financial secrets in a predictable plaintext location. Because this skill also directs users to start an authenticated brokerage gateway and complete 2FA, the resulting exposure is more serious than a generic app secret: it can enable access to live brokerage data and potentially account capabilities depending on configuration.
echo ""
echo "=== Next Steps ==="
echo "1. Edit ib-gateway-docker/.env with your IBKR credentials"
echo "2. Start the container: cd ib-gateway-docker && docker compose up -d"
echo "3. Approve 2FA on your IBKR Mobile app"
echo "4. Test: python3 $SKILL_DIR/scripts/ibkr_client.py summary --port 4001"
The skill markets itself as all read-only safe, but later states that some features may auto-request write access. That contradiction can cause operators to overtrust the integration and connect it to sensitive brokerage accounts under false assumptions about its access model.
The description says to use the skill when users ask about "portfolio monitoring, stock analysis, or automated trading alerts," which are broad categories rather than narrowly scoped trigger phrases. Without clearer constraints or exclusion conditions, the skill could be invoked for generic market-analysis requests unrelated to Interactive Brokers integration.
The guide instructs users to store IBKR credentials in a plaintext .env file, creating a persistent local secret that may be exposed through backups, shell history, file permissions, repository mistakes, or host compromise. Because these are brokerage credentials, disclosure could lead to unauthorized account access and sensitive financial data exposure.
Create a .env file in the ib-gateway-docker directory:
# IBKR Account
The documentation labels the integration as read-only safe while also documenting exposure of the live trading API endpoint on port 4002. Even if READ_ONLY_API is intended, connecting to a live brokerage API materially increases risk because a configuration mistake, image change, or client misuse could enable interaction with a real account.
The script provisions a live Interactive Brokers gateway by cloning a third-party Docker project, creating a local credential file, and instructing the user to enter brokerage credentials and approve 2FA. Even if intended for read-only monitoring, this materially expands the trust boundary and enables authenticated access to a financial account, which contradicts the 'read-only safe' framing and increases the chance of credential exposure or unintended account actions through the gateway or downstream tooling.
The setup flow tells the user to create and populate an .env file with IBKR credentials and then launch an authenticated gateway container, directly undermining the claim that the skill is 'all read-only safe.' In a financial-integration context, misleading safety claims are dangerous because they can cause users to disclose sensitive credentials and authorize brokerage connectivity without understanding the real risk surface.
Piping a remote script from get.docker.com directly into sh executes unreviewed code fetched over the network at install time. If the remote source, TLS trust chain, DNS, or delivery path is compromised, the user can suffer immediate arbitrary code execution on the host.
curl -fsSL https://get.docker.com | sh
docker --version
docker compose version
The setup instructions fix both TIME_ZONE and TZ to Asia/Singapore, which imposes a locale setting by default. The file does not explain that this is only an example or tell users to choose a timezone appropriate to their region, so it can violate locale-choice policy.
This code hard-codes a locale/market preference via default arguments and CLI defaults (SEHK, HKD). Under the policy, forcing a specific locale without user opt-in can be a natural-language policy issue unless the regional constraint is clearly documented and justified, which is not present here.
No suspicious patterns detected.