Bread Protocal

• Outcome: Review
• Latest audit: Sep 10, 2026 · 7:39 AM UTC
• Version: 1.0.4

Overview

This skill is a coherent Bread Protocol guide, but it gives live crypto transaction and private-key examples without enough safety controls or warnings.

Review this skill carefully before installing. It is documentation-only and I found no hidden execution or persistence, but it is designed around real Base mainnet wallet activity. Use a low-value wallet, never paste a real private key into source code or prompts, verify contract addresses and chain, approve only exact amounts, simulate transactions where possible, and revoke unused allowances.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: references/workflows.md:5
• Finding: Unsafe Private-Key Handling Encourages Secrets in Source Code## Vulnerability Details **File Location**: `references/workflows.md`, lines 5-12 **Vulnerability Type**: Private key embedded directly in application source **Risk Level**: High **Complete Vulnerable Code Snippet**: ```javascript You need an Ethereum wallet with: - A private key (for signing transactions) - BREAD tokens (from the raise or Uniswap) - ETH for gas (small amounts on Base) const account = privateKeyToAccount('0x...'); ``` ### Technical Analysis The workflow passes a private-key literal directly to `privateKeyToAccount`. Although the displayed value is a placeholder rather than an exposed credential, users are implicitly encouraged to replace it with a real signing key in the source file. Private keys embedded in source can be exposed through version-control history, shared files, IDE telemetry, build artifacts, terminal output, backups, prompt transcripts, or accidental publication. Unlike an ordinary password, possession of a blockchain private key generally gives the holder direct and irrevocable signing authority. ### Attack Path 1. A user copies the workflow and replaces `0x...` with a real private key. 2. The resulting source file is committed, shared, logged, backed up, or submitted to an external service. 3. An attacker obtains the file or its retained history. 4. The attacker extracts the private key and imports it into a wallet. 5. The attacker signs arbitrary transactions and transfers assets or consumes existing token allowances. ### Impact Assessment Successful exploitation compromises the entire wallet represented by the key. The attacker can exercise the same on-chain privileges as the wallet owner, including transferring ETH and tokens, interacting with contracts, approving spenders, and potentially controlling any protocols or administrative roles assigned to that address. The scope is not limited to Bread Protocol.
• Remediation: ## Remediation Suggestions - Do not place private keys directly in source code, examples, command-line arguments, logs, or prompts. - Prefer a hardware wallet, managed signer, encrypted keystore, or dedicated secret-management service. - If a local environment variable must be demonstrated, clearly state that it must never be committed or printed, and ensure the relevant environment file is excluded from version control. - Use a dedicated low-value wallet with only the permissions and funds needed for the operation. - Add explicit warnings that exposed keys must be considered permanently compromised and immediately rotated by transferring assets to a new wallet. - Provide an example based on an injected signer rather than showing a private-key literal as the normal setup path.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:148
• Finding: Backing Example Grants an Excessive BREAD Token Allowance## Vulnerability Details **File Location**: `SKILL.md`, lines 148-154 **Vulnerability Type**: Excessive ERC-20 spending approval **Risk Level**: Medium **Complete Vulnerable Code Snippet**: ```javascript // 1. Approve BREAD for backing fee await bread.approve(BAKERY_ADDRESS, parseEther('100')); // 100 BREAD per 1 ETH // 2. Back with ETH await bakery.backProposal(proposalId, { value: parseEther('0.5') // 0.5 ETH backing }); ``` ### Technical Analysis The documented fee is 100 BREAD per 1 ETH backed. The example backs 0.5 ETH but approves 100 BREAD, while the expected fee under the documented rate is 50 BREAD. Consequently, the example authorizes the Bakery contract to spend twice the demonstrated transaction's required amount. ERC-20 allowances remain active until they are consumed, replaced, or revoked. Any unused allowance therefore survives the backing transaction. The repository's more complete workflows already demonstrate the safer approach of querying `calculateBackingFee(ethAmount)` and approving that calculated amount. ### Attack Path 1. A user follows the quick example and approves the Bakery contract for 100 BREAD. 2. The user backs a proposal with 0.5 ETH. 3. Only the required backing fee is consumed, leaving a residual allowance under the documented fee model. 4. If the approved contract is compromised, upgradeable to hostile logic, or otherwise behaves unexpectedly, the spender can invoke `transferFrom` against the remaining allowance. 5. Additional BREAD is transferred without a new approval transaction from the user. ### Impact Assessment The direct scope is limited to the user's BREAD balance and the unconsumed allowance granted to the specified Bakery contract. It does not expose the wallet's private key or independently authorize ETH transfers. However, repeated excessive approvals or larger adapted transactions can increase the amount at risk.
• Remediation: ## Remediation Suggestions - Calculate the exact fee with `calculateBackingFee(ethAmount)` immediately before approval. - Approve only the returned fee amount rather than using a fixed allowance. - Wait for the approval receipt and verify the chain ID, token address, spender address, and approved amount before backing. - Recalculate or simulate the transaction if state may have changed between fee calculation and submission. - Revoke or reset any unused allowance after the operation. - Make the quick-start example consistent with the safer implementation in `references/workflows.md`.

other

Note

• Location: references/workflows.md:337
• Finding: Contradictory ETH Refund Documentation Can Misrepresent Financial Loss## Vulnerability Details **File Location**: `references/workflows.md`, lines 337-346; conflicting statement in `SKILL.md`, lines 122-130 **Vulnerability Type**: Misleading financial documentation **Risk Level**: Low **Complete Conflicting Snippets**: From `SKILL.md`: ```text ### 5. Claim Refund (Losers) If your backed proposal lost: Function: claimRefund(uint256 proposalId) Selector: 0x34735cd4 Your ETH is returned. BREAD fees are not refunded. ``` From `references/workflows.md`: ```javascript const unclaimed = myBackings.filter(b => b.proposal.settled && !b.backing.claimed ); for (const {proposalId, status} of unclaimed) { if (status === 'WON') { console.log(`Proposal #${proposalId}: Claim tokens!`); } else { console.log(`Proposal #${proposalId}: Claim ETH refund (95% returned)`); } } ``` ### Technical Analysis The primary guide says that a losing backer's ETH is returned, which reasonably implies a full ETH refund, while the workflow explicitly states that only 95% is returned. The repository contains no smart-contract source from which the actual refund calculation can be verified. This discrepancy affects the financial assumptions under which users may decide to back a proposal. It also prevents an Agent from accurately communicating the maximum loss associated with a losing proposal. ### Attack Path 1. A user reads the primary guide and assumes that all backed ETH will be refunded if the proposal loses. 2. The user backs a proposal based on that assumption. 3. The proposal loses. 4. If the 95% statement reflects the actual contract behavior, the user receives less ETH than expected. 5. The discrepancy causes an unanticipated financial loss that cannot generally be reversed on-chain. ### Impact Assessment This issue does not grant an attacker system privileges or wallet-signing authority. Its impact is financial and informational: users may underestima ...[truncated 195 chars]
• Remediation: ## Remediation Suggestions - Verify the exact refund formula against the deployed, verified contract implementation. - State consistently whether the refund is 100%, 95%, or calculated by another formula. - Identify every deduction separately, including protocol fees, retained BREAD fees, and gas costs. - Add a warning that users should simulate the claim and review current verified contract behavior before signing. - Include a version or deployment reference so documentation remains aligned with the listed contract address.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (4)

Vague Triggers

Medium

• Confidence: 93% confidence
• Finding: The trigger description is broad enough to activate on generic terms like 'wallet' or 'Base chain launchpad activities,' which can cause the skill to engage in unrelated conversations and steer users toward financial actions. In a crypto skill that involves wallet connections, token approvals, and ETH spending, overbroad triggering increases the chance of accidental or context-inappropriate invocation.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The skill instructs users to connect a wallet, approve token spending, and send ETH to contracts, but it does not prominently warn that these are irreversible on-chain financial actions with loss risk. Because approvals can authorize token transfers and backing requires real ETH, users may proceed without understanding exposure to scams, contract risk, market loss, or mistaken transactions.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The examples directly demonstrate `approve` and payable transaction flows that spend real assets on Base mainnet, but they do not include any warning that approvals grant token spending authority or that these transactions are irreversible once signed. In an agent skill meant to trigger on wallet and launchpad activity, users or downstream agents may copy these snippets into live execution with insufficient scrutiny, increasing the chance of unintended token allowance grants or ETH loss.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: This workflow instructs the agent/user to approve token spending, send ETH, and claim on-chain assets, but it does not prominently warn that these are real blockchain transactions with irreversible financial consequences. In an agent skill centered on wallet and Base launchpad activity, omission of explicit transaction-risk warnings increases the chance of unintended approvals, value transfer, or loss from interacting with unvetted proposals/contracts.

Static analysis

No suspicious patterns detected.