other
- Location
SKILL.md:19- Finding
Financial Credentials May Be Disclosed to an External Development API
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 19–23, 42, 50, 61, and 102–106
Vulnerability Type: Sensitive Credential Disclosure
Risk Level: CriticalRelevant code snippets:
markdown The default API base URL is `https://payment-api-dev.aiotnetwork.io`. All endpoints are relative to this URL. To override (e.g. for local development): ```bash export AIOT_API_BASE_URL="http://localhost:8080"text ```markdown - `confirm_transfer` — Confirm a pending transfer | `POST /api/v1/bank/transfer/:id/confirm` | Requires auth | Requires transaction PIN - `confirm_remittance` — Confirm a pending remittance | `POST /api/v1/bank/transfer/remittance/:id/confirm` | Requires auth | Requires transaction PIN - `confirm_conversion` — Confirm a pending conversion | `POST /api/v1/bank/convert/:id/confirm` | Requires auth | Requires transaction PINmarkdown - If a tool requires authentication, verify the session has a valid bearer token before calling it. - If a tool requires a transaction PIN, ask the user for it fresh each time. Never cache or log PINs. - Never expose, log, or persist secrets (passwords, tokens, full card numbers, CVVs).Technical Analysis
The skill directs the agent to use an externally hosted development API as its default service while also requiring authenticated sessions and fresh transaction PINs for financially consequential confirmation operations. Consequently, bearer-token authorization data and transaction PINs may be transmitted to infrastructure outside the audited package.
Although the instructions prohibit caching or logging PINs, the package contains no implementation that demonstrates credential isolation, endpoint trust validation, transaction-scoped authorization, certificate pinning, or a mechanism that keeps the PIN outside the agent context. The use of a development-domain endpoint as the default further weakens the expected trust boundary for ...[truncated 2033 chars]
- Remediation
View remediation
Remediation Suggestions
- Do not collect transaction PINs directly in the agent conversation or expose them to the model context.
- Move transaction authorization to a trusted, browser-hosted confirmation page or secure first-party application where the PIN is entered directly into an isolated payment-provider interface.
- Replace the development API default with a verified production endpoint and document the service owner, security boundary, and data-processing expectations.
- Enforce an allowlist of approved HTTPS origins. Reject arbitrary hosts, user-influenced URLs, redirects to unapproved origins, and non-HTTPS configurations outside isolated local testing.
- Separate development and production configuration so development endpoints cannot be selected in production deployments.
- Use short-lived, least-privilege, transaction-scoped authorization tokens rather than broadly reusable bearer tokens.
- Bind every confirmation credential to a specific transaction identifier, amount, currency, recipient, and expiration time. Enforce single use and replay prevention on the server.
- Ensure PINs and authorization headers are redacted from prompts, traces, telemetry, logs, error messages, and tool-call records.
- Publish or include the audited tool implementation so request construction, redirect handling, TLS verification, secret handling, and endpoint validation can be independently reviewed.
- Require explicit user review of the final recipient, amount, currency, exchange rate, and fees through a trusted interface before confirmation.