Palmera — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Palmera, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 2
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 2 closed, publicly disclosed Palmera reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Access control, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Access control findings disclosed against Palmera
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Palmera: Unauthorized Access Control Due to Retained Root Role When Root Safe Exits and Joins New Org
Palmera's module that manages Safe-based organizations grants the ROOT_SAFE role when a safe creates an organization, but the addSafe path that re-ingests an existing safe into a new organization never revokes a pre-existing ROOT_SAFE grant. Because roles are keyed to the safe address rather than cleared on exit, a safe that leaves one organization and is added as a member of another is still recognized as root by the contract, receiving administrative privileges over an org where it should be a regular member. The report reproduces the role-assignment snippet and a mitigation diff that revokes ROOT_SAFE inside addSafe before granting the membership role.
Palmera: setRole` Function Incorrectly Assigns `_safe.lead` without Validating `enabled` Parameter
Palmera's setRole function updates the _safe.lead storage field whenever a lead-related role identifier (SAFE_LEAD or the two SAFE_LEAD variants) is passed, but it ignores the enabled boolean. As a result, a root-safe admin who disables a user's lead role still leaves (or sets) _safe.lead pointing at that user, so the stored lead diverges from the active role set. Any operator that treats _safe.lead as the source of truth can thus recognize a user whose lead role was revoked as the current lead, misrouting operations or authorizations.