T05 · Unauthorized Access and Privilege Escalation
- Location
src/index.ts:27- Finding
Cross-Service Private-Key Discovery Violates Least Privilege
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This payment skill matches its stated purpose, but it needs review because it can silently load wallet keys, contact arbitrary endpoints, and automatically sign payments or token approvals.
Install only if you are comfortable giving this skill access to a dedicated low-balance TRON wallet. Do not point it at untrusted endpoints, and avoid using a wallet that holds funds beyond the intended payment amount. Review or change the approval behavior before mainnet use, prefer exact or capped approvals, and remove broad shared-config key discovery.
src/index.ts:27Cross-Service Private-Key Discovery Violates Least Privilege
src/index.ts:76Unrestricted Destination Can Trigger Automatic Payment Negotiation
SKILL.md:45Documented Unlimited USDT Approval Exposes the Wallet Balance
package.json:5Unpinned Financial Dependencies and Non-Reproducible Build Resolution
src/index.ts:159Untrusted Binary Responses Are Written Unsafely to a Shared Temporary Directory
The declared purpose is a payment skill for x402-enabled agent endpoints using USDT on TRON. However, the supplied code is generic blockchain ABI infrastructure centered on Ethereum/EVM concepts: ABI coders, Interface parsing, event topics, function sighashes, Ethereum address checksum handling, and transaction/error decoding. There is no visible logic for TRON, USDT transfers, x402 payment flows, endpoint payments, wallet interaction, signing, broadcasting transactions, or network calls. This is a materially different primary purpose, so the description does not accurately represent the code.
The declared purpose is very specific: paying for x402-enabled agent endpoints using USDT on TRON. But this code chunk shows low-level utility libraries, largely from ethers-like tooling, including BigNumber/FixedNumber manipulation, hex and byte utilities, signature parsing/joining, ENS normalization and namehashing, EIP-712 typed-data encoding, keccak hashing, and RLP encoding/decoding. These are generic cryptographic and Ethereum ecosystem helpers. There is no visible code for TRON APIs, TRC-20/USDT transfers, wallet signing for TRON transactions, HTTP payment to x402 endpoints, invoice handling, or any endpoint payment orchestration. This is therefore a clear description-behavior mismatch, with the actual code being unrelated support/library functionality rather than the declared payment skill.
The declared description is specific to paying x402-enabled agent endpoints using USDT on TRON, which would typically involve TRON transaction construction/signing, USDT/TRC20 handling, network/API calls, payment authorization, or endpoint-payment orchestration. The supplied code instead contains generic bundled library code focused on encoding/decoding and cryptography, especially secp256k1/ECDSA-related functionality more commonly associated with Ethereum/Bitcoin-style ecosystems. There is no visible logic for TRON, USDT, x402 payments, endpoint interaction, wallet/payment execution, or related triggers/permissions. This is a material description-behavior mismatch, not just supporting implementation detail.
There is a clear description-behavior mismatch. The declared purpose is payment-related and specific to x402-enabled agent endpoints, USDT, and the TRON network. However, the code chunk is a bundled cryptography/support library with no visible payment workflow, no TRON blockchain interaction, no USDT token handling, no x402 protocol logic, no network calls, and no endpoint payment orchestration. While cryptographic code could be a supporting dependency for a payment system, this chunk by itself primarily provides low-level crypto and serialization capabilities rather than the declared payment functionality.
This code appears to be generic bundled dependencies rather than business logic for paying x402-enabled agent endpoints. The protobuf sections serialize/deserialize messages, the async-kit sections manage parallel/serial job execution, and the BigNumber/BN sections implement arbitrary-precision arithmetic. None of the visible code accesses network endpoints, signs transactions, manages TRON addresses/keys, constructs USDT transfers, or interfaces with x402 payment protocols. Therefore the actual behavior shown is materially different from the declared purpose.
This snippet appears to be generic dependency code rather than business logic for paying x402-enabled endpoints with USDT on TRON. The dominant behavior shown is arbitrary-precision integer math, modular reduction, multiplication/division, and utility modules for streams/events/HTTP redirects. While such libraries could support cryptographic or networking features in a larger application, this chunk itself does not implement the declared purpose and instead exposes materially different, generic capabilities. Therefore the description does not accurately represent what this supplied code chunk actually does.
This code chunk does not match the declared payment-focused purpose. The visible behavior is standard web request infrastructure and helper libraries, not logic for paying x402-enabled agent endpoints or interacting with TRON/USDT. There are no indicators of blockchain RPC calls, transaction creation/signing, TRON addresses, token transfer handling, or x402-specific payment negotiation. While such libraries could support a payment client, this chunk’s actual behavior is materially broader and unrelated as presented, so the description is not an accurate representation of this code segment.
The declared purpose is a blockchain/payment capability focused on paying x402-enabled agent endpoints with USDT on TRON. However, the supplied code is clearly part of a semver library, handling version ranges, prerelease parsing, intersection checks, and coercion of version strings. There is no indication of network calls, wallet handling, TRON APIs, token transfers, or x402 payment flows. This is a clear description-behavior mismatch with a materially different primary purpose.
Referenced artifact was not completely inspected
node dist/index.js --url <URL> [options]
YARA rule matched a hack tool or exploit indicator (offensive tools, reconnaissance, privilege escalation, or exploit frameworks).
er.throwArgumentError("unbalanced parenthesis", "value", value);
}
}
}
}
if (accum) {
result.push(accum);
}
return result;
}
//# sourceMappingURL=fragments.js.map
/***/ }),
/***/ 219:
/***/ ((__unused_webpack_module, exports, __nccwpck_require__) => {
Object.defineProperty(exports, "__esModule", ({ value: true }));
exports.TransactionDescription = exports.LogDescription = exports.checkResultErrors = exports.Indexed = exports.Interface = exports.defaultAbiCoder = exports.AbiCoder = exports.FormatTypes = exports.ParamType = exports.FunctionFragment = exports.Fragment = exports.EventFragment = exports.ErrorFragment = exports.ConstructorFragment = void 0;
var fragments_1 = __nccwpck_require__(5186);
Object.defineProperty(exports, "ConstructorFragment", ({ enumerable: true, get: function () { return fragments_1.ConstructorFragment; } }));
Object.defineProperty(exports, "ErrorFragment", ({ enumerable: true, get: function () { re
The HTTP payment flow can automatically trigger on-chain ERC20 approve transactions when allowance is insufficient, without an explicit confirmation step tied to the specific endpoint or spend amount. Because approvals can authorize future token transfers by a spender contract, this is more dangerous than a one-off payment and may expose significantly more funds than intended.
The inline guidance claims the agent must not search for or read private keys from files, but the implementation immediately proceeds to do exactly that via config-file and home-directory reads. This contradiction is a strong red flag because it normalizes deceptive safety messaging while still enabling secret exfiltration or unauthorized payment operations.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
if (!privateKey) {
console.error('Error: Payment credentials (private key) not found.');
console.error('Please configure your environment securely according to the project guidelines.');
console.error('Agent: DO NOT attempt to search for or read private keys from files.');
process.exit(1);
}
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
if (!privateKey) {
console.error('Error: Payment credentials (private key) not found.');
console.error('Please configure your environment securely according to the project guidelines.');
console.error('Agent: DO NOT attempt to search for or read private keys from files.');
process.exit(1);
}
The message tells the agent not to search for or read private keys from files, but the code already does exactly that in findPrivateKey(). This contradiction is a red flag because it can mislead reviewers or operators about the skill's actual behavior and conceal credential-access logic.
The skill declares access to a payment/invocation tool and explicitly relies on sensitive environment variables, outbound network calls, and prebuilt code execution, but it does not constrain tool scope with explicit permissions or allowed-tools metadata. In an agent setting, missing scope declarations weakens reviewability and can enable broader-than-expected access to secrets or external systems.
The skill states that insufficient allowance triggers an infinite approval (MAX_UINT256) to minimize future transactions, but it does not foreground the security consequence that a compromised or malicious spender could drain all approved USDT. In a payment skill that signs blockchain transactions, this materially increases user fund risk beyond the immediate micropayment intent.
The skill is explicitly designed to send user prompts and request data to external agent endpoints over the network. That is expected behavior, but it is still a real data-transmission risk because prompts, metadata, and potentially payment-related headers/signatures are sent to third-party services.
url: https://api.example.com/chat
method: POST
body: {"prompt": "Tell me a joke"}
Fetching a remote agent manifest is an external network action that leaks at least destination metadata and can expose the agent to untrusted content. In context this is expected and lower risk than sending full prompts, but it still broadens interaction with third-party infrastructure.
url: https://api.example.com/.well-known/agent.json
method: GET
Suspicious Unicode normalization or mixed-script content
The bundled skill contains multiple user-visible comments and log strings in Chinese, such as the X402 client descriptions and request-processing messages, without offering a locale choice. This can violate language or locale policy when the skill is used in contexts where users have not opted into Chinese output.
The skill actively searches environment variables and multiple local files, including a user home config, for a TRON private key unrelated to the immediate request payload. In an agent/tool context, this creates implicit secret discovery and use, enabling unauthorized spending if an untrusted prompt or endpoint triggers payment flow.
Credential file and environment reads occur silently, with no user-facing disclosure before a payment key is discovered and used. In agent environments, silent credential harvesting materially increases the chance of covert use of wallet material under attacker-controlled prompts or endpoints.
The skill writes arbitrary binary HTTP response bodies to a local temporary file, despite being described as a payment helper rather than a general file-writing tool. A remote endpoint can therefore cause local artifact creation, which may fill disk, leave sensitive material behind, or create files later opened by the user or other tooling.
Binary response data is saved to a temporary file without prior disclosure, size checks, or caller-selected destination. This allows a remote service to create persistent local files unexpectedly, which can leak data, consume disk space, or introduce follow-on risk if those files are later trusted or opened.
Detected: suspicious.dynamic_code_execution, suspicious.env_credential_access, suspicious.exposed_secret_literal (+1 more)