T09 · Insecure Skill Coding Practices
- Location
SKILL.md:59- Finding
Insufficient authorization safeguards for passenger PII submission and irreversible USDC payment
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 59–101
Vulnerability Type: Sensitive-data transmission and unsafe cryptocurrency transaction authorization
Risk Level: HighVulnerable Code
bash curl -X POST https://api.cabin.team/v1/book \ -H "Content-Type: application/json" \ -d '{ "offer_id": "offer_1", "search_id": "abc123", "passengers": [{ "type": "adult", "given_name": "John", "family_name": "Doe", "email": "john@example.com", "born_on": "1990-01-15", "gender": "m" }] }'bash # Check USDC balance on Base node src/balance.js base --json # Send USDC to deposit address node src/send.js base USDC <deposit_address> <amount_usdc> --yes --jsonTechnical Analysis
The booking workflow transmits passengers' names, email addresses, dates of birth, and gender to
https://api.cabin.team. This transmission is directly related to the declared flight-booking functionality and uses HTTPS, so it is not evidence of concealed or unrelated data exfiltration. However, the Skill does not require an explicit disclosure and consent checkpoint immediately before transmitting the information, nor does it provide guidance to prevent passenger data from being unnecessarily retained or logged.The payment workflow presents a greater risk. It instructs an agent with wallet capabilities to send USDC to a deposit address returned by the remote booking API while supplying the
--yesoption. This option suppresses an interactive confirmation step for an irreversible blockchain transaction. The instructions do not require the agent to present the exact recipient address, token contract, network, amount, and associated booking identifier to the user for transaction-specific approval.Consequently, a compromised or erroneous API response, address substitution, stale booking, incorrect amount, or agent misunderstan ...[truncated 1825 chars]
- Remediation
View remediation
Remediation Suggestions
- Require explicit, informed user consent immediately before transmitting passenger PII. Identify the destination service and enumerate the data fields that will be submitted.
- Collect and transmit only information required by the selected airline or booking provider. Do not retain passenger PII after the booking workflow unless the user explicitly requests it and an appropriate retention policy exists.
- Warn agents not to include passenger PII in persistent memory, telemetry, shell history, diagnostic output, or general-purpose logs. Redact sensitive fields from errors.
- Remove
--yesfrom the wallet command so that payment cannot silently bypass confirmation. - Require transaction-specific user approval immediately before every transfer. Display the full recipient address, Base network, verified USDC contract address, exact amount, estimated gas fee, and booking identifier.
- Treat the API-provided address and amount as untrusted input. Validate the Ethereum address format, enforce the Base network and expected USDC token contract, reject zero or abnormal amounts, and apply reasonable spending limits.
- Use a trusted secondary confirmation channel or signed payment request to bind the deposit address, amount, booking ID, and expiration time together.
- Reconfirm expired or stale bookings before payment and reject transactions when the booking state or quoted amount has changed.
- Default wallet integrations to least privilege, including per-transaction approval, narrowly scoped spending limits, and no access to unrelated tokens or accounts.