T09 · Insecure Skill Coding Practices
- Location
scripts/lib/part2-morpho-planner.js:4694- Finding
Raw Wallet Private Key Persisted in Morpho Run Artifacts
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is mostly a disclosed blockchain deployment tool, but it has a serious credential-handling risk because raw wallet keys can be accepted and written into saved run artifacts.
Review carefully before installing. Use only environment-variable based signer inputs, never inline privateKey fields, and avoid enabling artifact persistence with any request that contains secrets. Treat any old run directory created with inline keys as sensitive and rotate that wallet if a real key was saved.
scripts/lib/part2-morpho-planner.js:4694Raw Wallet Private Key Persisted in Morpho Run Artifacts
scripts/lib/part2-planner.js:1140Raw Wallet Private Key Persisted in EVK Workflow Artifacts
If the skill is primarily a static EVK configuration/recipe catalog while presenting itself as a Morpho-first execution workflow, users and agents can be misled into relying on nonexistent verification and deployment guarantees. In a financial/deployment setting, misleading operational claims are themselves security-relevant because they distort approval and risk decisions.
If the skill is primarily a static EVK configuration/recipe catalog while presenting itself as a Morpho-first execution workflow, users and agents can be misled into relying on nonexistent verification and deployment guarantees. In a financial/deployment setting, misleading operational claims are themselves security-relevant because they distort approval and risk decisions.
If the skill is primarily a static EVK configuration/recipe catalog while presenting itself as a Morpho-first execution workflow, users and agents can be misled into relying on nonexistent verification and deployment guarantees. In a financial/deployment setting, misleading operational claims are themselves security-relevant because they distort approval and risk decisions.
If the skill is primarily a static EVK configuration/recipe catalog while presenting itself as a Morpho-first execution workflow, users and agents can be misled into relying on nonexistent verification and deployment guarantees. In a financial/deployment setting, misleading operational claims are themselves security-relevant because they distort approval and risk decisions.
If the skill is primarily a static EVK configuration/recipe catalog while presenting itself as a Morpho-first execution workflow, users and agents can be misled into relying on nonexistent verification and deployment guarantees. In a financial/deployment setting, misleading operational claims are themselves security-relevant because they distort approval and risk decisions.
If the skill is primarily a static EVK configuration/recipe catalog while presenting itself as a Morpho-first execution workflow, users and agents can be misled into relying on nonexistent verification and deployment guarantees. In a financial/deployment setting, misleading operational claims are themselves security-relevant because they distort approval and risk decisions.
If the skill is primarily a static EVK configuration/recipe catalog while presenting itself as a Morpho-first execution workflow, users and agents can be misled into relying on nonexistent verification and deployment guarantees. In a financial/deployment setting, misleading operational claims are themselves security-relevant because they distort approval and risk decisions.
The registry enumerates only Euler EVK markets even though the skill metadata explicitly says it must not be used for Euler EVK flows. In an agentic workflow, this kind of configuration contradiction can cause the agent to plan or execute against unsupported protocols, leading to unintended lending actions, unsafe deployments, or bypass of intended protocol restrictions.
The skill metadata promises a Morpho-first lending workflow, but this file hard-codes EVK/Euler-first behavior via SUPPORTED_COMMANDS and the EVK-only warning/blocking logic. In an agent setting, this is dangerous because a caller selecting a Morpho skill may be silently routed into a different protocol workflow, causing unintended planning, funding, deployment preparation, or operator trust failures on the wrong stack.
runEvkWorkflow normalizes the request to protocol 'evk' and proceeds through EVK feed funding, oracle prep, market prep, deployment bundling, and possible send flow regardless of the surrounding Morpho-oriented skill identity. In a signer-backed automation context, this protocol substitution can lead to wrong-protocol actions and real transactions under false operator assumptions.
The skill declares execution-sensitive capabilities such as environment-variable access and networked, signer-backed workflows, but does not define an explicit tool/permission scope. That increases the chance an agent runtime grants broader access than intended, especially for a skill that can progress from planning into real transaction execution.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- treat browser-assisted funding as an explicit handoff, not a silent autonomous path
- require exact asset selection before deployment planning or submission
- require a usable RPC endpoint for any on-chain verification claim
- never ask the user to paste a raw private key into chat
- keep signer material in environment variables or local runtime config, never in committed files or request templates
## Read next
The manifest says this skill should handle Morpho-first lending workflows and explicitly says not to use it for Euler EVK flows or unsupported oracle routes. This artifact is for an EulerRouter contract and includes governance and oracle configuration functions such as govSetConfig, govSetFallbackOracle, govSetResolvedVault, and transferGovernance, which are Euler-specific operational capabilities outside that declared scope.
The artifact explicitly references Euler Vault Kit proxy creation even though the skill metadata says the skill should not be used for Euler EVK flows. This creates a real scope-confusion risk: an agent or maintainer could accidentally invoke unsupported deployment logic, leading to unintended contract interactions, incorrect market setup, or execution on the wrong protocol path.
The file embeds Arbitrum reference markets whose oracleType is ChainlinkOracleV2 while the skill is explicitly presented as Morpho-first for Api3-backed markets. In an agentic deployment workflow, this mismatch can cause the agent to plan, verify, or even deploy against the wrong oracle path, leading to incorrect market assumptions and unsafe execution decisions.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
},
"source": {
"morphoBlueSdk": "@morpho-org/blue-sdk addresses for chain 42161",
"morphoApi": "https://api.morpho.org/graphql"
},
"notes": [
"These are chain-real reference markets on Arbitrum captured on 2026-05-01.",
The notes explicitly state these oracleAddress values are not Api3-backed targets and must be replaced once that path exists, which directly contradicts the skill's claimed ability to execute Api3-backed deployment workflows. In a signer-capable agent, this kind of contradictory configuration creates a real risk of users authorizing funding, deployment, or verification based on unsupported and misleading defaults.
The workflow describes progressing from planning into real feed funding, on-chain deployment, and dependent transaction sequencing, but it does not require a clear user-facing warning or explicit confirmation immediately before irreversible blockchain actions. In an agentic execution context, this increases the risk of users or upstream agents triggering costly, irreversible transactions without fully understanding fund movement, deployment side effects, rollback limits, or signer usage.
The usage examples advertise --private-key as a supported direct CLI input path without warning that command-line arguments are often exposed via shell history, process listings, CI logs, and crash telemetry. In a signer-capable automation tool that can submit live transactions, this materially increases the chance of private key disclosure and downstream wallet compromise.
The manifest emphasizes planning, guarded verification, and progressing to execution only when explicitly allowed, but this file includes concrete transaction execution paths that sign and broadcast buySubscription calls. It also separately implements real contract deployment logic for communal proxies, making the module an executor in addition to a planner/resolver.
The manifest is centered on Morpho market planning, oracle route resolution, Api3 feed readiness/funding, and Morpho oracle/market deployment. This file additionally exposes a generic deploy-communal-proxy command that deploys Api3 reader proxies independently of any Morpho-specific workflow step.
This helper constructs a canary request that is immediately transaction-capable: broadcast.enabled is true, send.enabled is true, and dryRun is false. In a skill whose stated safety model is to default to planning or guarded verification, providing a live-send template as the default bootstrap materially increases the chance of unintended on-chain execution once runtime secrets and RPC values are injected.
The bootstrap helper includes a private-key-based sending path by embedding a privateKey field into a ready-to-send request object. Even though the placeholder is injected at runtime, scaffolding direct raw-key use in a convenience helper encourages unsafe secret handling patterns and lowers the barrier to accidental or unauthorized fund-moving transactions.
A sensitive credential field is present in the same template that also enables broadcasting, but this file provides no local warning, guardrail, or masking mechanism around that secret-bearing path. In an agentic workflow context, this increases the risk that users or upstream components treat the object as ordinary configuration, log it, persist it, or pass it through unsafe channels before execution.
This is a real security issue because the user-facing progress/message boundary says the wrapper is only preparing adapter deployment, while the code path proceeds into full Morpho market deployment and optional verification. In a signer-backed workflow, misleading execution messaging can cause an operator or supervising agent to approve or continue a run under a false understanding of what transactions may actually be sent, which is especially dangerous in a lending-market deployment skill.
Detected: suspicious.env_credential_access, suspicious.exposed_secret_literal