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
- 9
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 9 closed, publicly disclosed Palmera reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Access control, Front-running / MEV, Logic error, 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
- Front-running / MEV findings disclosed against Palmera
- Logic error 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: Unauthorized Role Modification Vulnerability in setRole Function
Palmera's setRole is designed to bind a user's role to a specific safe through a safeId parameter, but the underlying call only forwards the user address, role, and enabled flag to RolesAuthority.setUserRole, silently ignoring safeId. As a result, roles are written globally against the user address rather than scoped to the organization's safe. Because any organization's root can invoke setRole with their own safeId, a malicious root can add or strip arbitrary roles for users belonging to other organizations, enabling unauthorized Safe transaction execution through self-escalation and cross-organization denial of service. The write-up's PoC demonstrates org2's root revoking a user's role from org1 and granting a different one, with assertions confirming the global role state was flipped.
Palmera: Malicious users can front-run host users safe management actions and add those safes as root for wrong org
Palmera's root-safe creation flow lets any root-safe caller assign an arbitrary Safe address as the root of their organization without verifying that the target Safe consented or belongs to them. Because a Safe can only be registered to one organization, an attacker can front-run legitimate addSafe calls by registering an honest user's Safe under a malicious organization, permanently bricking that Safe from being added to its rightful tree. Every subsequent attempt by the honest party reverts with SafeAlreadyRegistered, resulting in a griefing denial-of-service on the module's orchestration composability. The proposed fix adds an explicit consent flag the target Safe must set before it can be registered as a root.
Palmera: Potential Protocol insolvency in `removeWholeTree` and `disconnectSafe`
Palmera's Gnosis Safe hierarchy module contains a state-managed `_exitSafe` routine that reverts with `PreviewModuleNotFound` whenever the caller's previously-registered preview module resolves to the zero address. Because a Safe operator can call `disableModule` directly to remove the Palmera module without clearing the protocol's bookkeeping, this leaves the safe in a state where any subsequent `removeWholeTree` or `disconnectSafe` invocation aborts. The practical consequence is a griefing-style denial of service that permanently blocks the protocol's cleanup and disconnection operations for that safe. A PoC confirms the module pointer is zero after a prior disconnect, and the proposed fix skips the `disableModule` call when no preview module exists instead of reverting.
Palmera: Safe owner/s can prevent being removed from organization by indefinitely increasing their child array
Palmera's Safe-organization module lets any arbitrary safe attach itself as a child of another super safe via addSafe, growing the superSafe's child array with no cap (only tree depth is limited). When an administrator later removes that safe, removeSafe executes two storage loops—one scanning the full parent child array and another reparenting every child of the removed safe—so an attacker who inflated the child array with a large number of siblings forces an out-of-gas revert, bricking the removal of a compromised safe. Because membership joining is permissionless, a malicious child can grief the owning organization indefinitely. The recommended fix is to enforce a limit on the safe.child array at integration time.
Palmera: Ineffective Revocation of Multiple Roles in `disableSafeLeadRoles` Function
Palmera's disableSafeLeadRoles privilege-revocation path is implemented as a chain of if/else-if branches, so once any one Safe Lead role matches and is revoked the remaining branches are skipped. A Lead who holds more than one Safe Lead role (for example both SAFE_LEAD_EXEC_ON_BEHALF_ONLY and SAFE_LEAD_MODIFY_OWNERS_ONLY) therefore keeps the secondary role active after the function runs, defeating the intent of full role revocation. The report supplies the exact faulty Solidity function and a corrected version that revokes each role independently.
All reports in this group
- Palmera: Incomplete Deletion of Organization State Leads to Residual Effects on New UsersLogic error$0
- Palmera: setRole` Function Incorrectly Assigns `_safe.lead` without Validating `enabled` ParameterAccess control$0
- Palmera: isSafeLead` Function Lacks Role Authorization Check, Leading to Unauthorized AccessAccess control$0