Quick Answer
LUKSO's EVM compatibility means Solidity developers can deploy without rewriting code — but the Universal Profile standard (LSPs) introduces an account model built for permissioned, programmable identity, not just asset custody. That flexibility is the point, and it's also where misconfiguration turns into a real security gap.
A Universal Profile (LSP0/ERC725Account) is a smart contract, not an EOA. It holds assets and identity data directly, and every interaction with it goes through the account's own contract logic rather than a raw private key signature.
Control over a Universal Profile is delegated to one or more controller addresses via the Key Manager, each with scoped permissions. Overly broad grants — especially the SUPER_ permissions that bypass restriction checks — are the most common LUKSO-specific misconfiguration.
Every incoming asset transfer can trigger a Universal Receiver Delegate contract automatically. This enables real functionality (auto-cataloging, custom accept/reject logic) but means delegate contracts need the same reentrancy discipline as any other externally-triggered code path.
All standard Ethereum Solidity vulnerability classes still apply on LUKSO: reentrancy, oracle manipulation, access control flaws, flash loan attacks. LSP-specific risks are additive, not a replacement for standard EVM security review.
| Vulnerability Type | Severity | Description | Example |
|---|---|---|---|
| Stale Key Manager Permissions After Ownership Transfer | Critical | A Universal Profile's LSP6 Key Manager grants permissions to specific controller addresses. When ownership of the profile is transferred to a new owner, permissions granted to the previous controller are not automatically revoked. A Code4rena audit of LUKSO in 2023 found this exact issue: a former owner can retain dangerous permissions after the profile changes hands. | A Universal Profile is sold or transferred to a new owner, but the previous owner's controller address still holds SETDATA or CALL permissions on the Key Manager — letting them modify profile data or execute transactions on an account they no longer own. |
| Overly Broad SUPER_ Permissions | Critical | LSP6 defines 'SUPER_' permissions (SUPER_CALL, SUPER_TRANSFERVALUE, SUPER_SETDATA) that bypass the AllowedCalls and AllowedERC725YDataKeys restrictions entirely. Granting one of these to a third-party controller — a dApp, an automation bot, a Grid mini-app — gives that address effectively unrestricted control over the entire account, not just a scoped subset of actions. | A project grants SUPER_CALL to a bot that's supposed to only call one specific contract function — the bot (or anyone who compromises it) can now call any contract from the profile, not just the intended one. |
| Unvalidated Universal Receiver Delegate Logic | High | LSP1's universalReceiver() function fires automatically whenever a Universal Profile receives any asset — LYX, an LSP7 token, or an LSP8 NFT. If a Universal Receiver Delegate contract is set to handle these notifications, its logic executes on every incoming transfer. An unguarded delegate is a reentrancy-equivalent risk, the same class of problem ERC-777's tokensReceived hook caused in early DeFi. | A Universal Receiver Delegate that updates internal accounting state without a reentrancy guard — an attacker sends a token that itself calls back into the profile mid-transfer, exploiting the inconsistent state before the first transfer completes. |
| Unscoped LSP7/LSP8 Operator Authorization | High | authorizeOperator is LSP7/LSP8's equivalent of ERC-20's approve or ERC-721's setApprovalForAll. LSP8 adds per-tokenId operator scoping, but it's often misused as if it granted global authority, or never revoked after the interaction it was meant for is done — the same unlimited-approval risk that's caused real losses across standard ERC token ecosystems. | A marketplace contract is authorized as an operator for a full LSP8 collection to enable listing, and is never revoked after the sale completes — a bug or compromise in that marketplace contract can move any token in the collection indefinitely. |
| Custom LSP7/LSP8 Extensions Skipping Parent Hooks | Medium | Like OpenZeppelin's ERC-20 and ERC-721, LSP7 and LSP8 are meant to be extended. Teams that add custom mint, burn, or transfer logic without calling the parent contract's hooks — or without correctly validating the force and data parameters — can break the Universal Receiver notification guarantee or bypass standard behavior receivers rely on. | A custom LSP7 extension overrides _transfer to add a fee, but forgets to call the parent's notification logic — recipient contracts that depend on receiving a universalReceiver callback never get notified, silently breaking any integration that relies on it. |
Vulnerability #1 is grounded in a real, public finding: Code4rena's June 2023 LUKSO audit.