Evidence used
- No CISA KEV confirmation is currently recorded.
- The selected CVSS metric records a network-reachable, unauthenticated path with no user interaction.
- EPSS is 0.38% for the current model date.
BlackTreeCVE Intelligencealchemyplatform · modular-account
Official source article: GitHub GHSA-JHP7-7CQ9-M4PV ↗. Check the applicable product and release in the original source.
Medium technical severity with no CISA KEV confirmation; remediate through the normal risk-based patch cycle unless local exposure raises the priority.
Medium technical severity with no CISA KEV confirmation; remediate through the normal risk-based patch cycle unless local exposure raises the priority.
Fix not verifiedAlchemy's Modular Account is a smart contract account that is compatible with ERC-4337 and ERC-6900. In versions on the 2.x branch prior to commit 5e6f540d249afcaeaf76ab95517d0359fde883b0, owners of Modular Accounts can grant session keys (scoped external keys) to external parties and would use the allowlist module to restrict which external contracts can be accessed by the session key. There is a bug in the allowlist module in that we don't check for the `executeUserOp` -> `execute` or `executeBatch` path, effectively allowing any session key to bypass any access control restrictions set on the session key. Session keys are able to access ERC20 and ERC721 token contracts amongst others, transferring all tokens from the account out andonfigure the permissions on external modules on session keys. They would be able to remove all restrictions set on themselves this way, or rotate the keys of other keys with higher privileges into keys that they control. Commit 5e6f540d249afcaeaf76ab95517d0359fde883b0 fixes this issue.
Alchemy's Modular Account is a smart contract account that is compatible with ERC-4337 and ERC-6900. In versions on the 2.x branch prior to commit 5e6f540d249afcaeaf76ab95517d0359fde883b0, owners of Modular Accounts can grant session keys (scoped external keys) to external parties and would use the allowlist module to restrict which external contracts can be accessed by the session key. There is a bug in the allowlist module in that we don't check for the `executeUserOp` -> `execute` or `executeBatch` path, effectively allowing any session key to bypass any access control restrictions set on the session key. Session keys are able to access ERC20 and ERC721 token contracts amongst others, transferring all tokens from the account out andonfigure the permissions on external modules on session keys. They would be able to remove all restrictions set on themselves this way, or rotate the keys of other keys with higher privileges into keys that they control. Commit 5e6f540d249afcaeaf76ab95517d0359fde883b0 fixes this issue.
The application performs an authorisation check, but it does not correctly enforce the required permission boundary.
An attacker operating through a network path may attempt exploitation without authentication or user interaction. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
Alchemy's Modular Account is a smart contract account that is compatible with ERC-4337 and ERC-6900. In versions on the 2.x branch prior to commit 5e6f540d249afcaeaf76ab95517d0359fde883b0, owners of Modular Accounts can grant session keys (scoped external keys) to external parties and would use the allowlist module to restrict which external contracts can be accessed by the session key. There is a bug in the allowlist module in that we don't check for the `executeUserOp` -> `execute` or `executeBatch` path, effectively allowing any session key to bypass any access control restrictions set on the session key. Session keys are able to access ERC20 and ERC721 token contracts amongst others, transferring all tokens from the account out andonfigure the permissions on external modules on session keys. They would be able to remove all restrictions set on themselves this way, or rotate the keys of other keys with higher privileges into keys that they control. Commit 5e6f540d249afcaeaf76ab95517d0359fde883b0 fixes this issue.
The application performs an authorisation check, but it does not correctly enforce the required permission boundary.
An attacker operating through a network path may attempt exploitation without authentication or user interaction. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
No exploit-tagged reference or CISA SSVC proof-of-concept state is currently recorded. Research may still exist outside the structured feeds.
CWE-863: Incorrect Authorization. The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:UCommon Vulnerability Scoring System 4.0: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 15 May 2025 · Last source change 19 May 2025, 14:42 UTC · CWE-863 · Incorrect Authorization
Core structured fields are present and their contributing authorities are shown above.
No material field changes have been recorded since change tracking began. Routine source refreshes and cosmetic edits are intentionally excluded.