xanoutas/solidity-security-findings huggingface dataset:
`LSP8Burnable` extension incorrectly inherits `LSP8IdentifiableDigitalAssetCore`
Audit: 2023-06-lukso-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8Burnable.sol#L15


# Vulnerability details

## Bug Description

The `LSP8Burnable` contract inherits from `LSP8IdentifiableDigitalAssetCore`:

[LSP8Burnable.sol#L15](https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8Burnable.sol#L15)

```solidity
abstract contract LSP8Burnable is LSP8IdentifiableDigitalAssetCore {
```

However, LSP8 extensions are supposed to inherit `LSP8IdentifiableDigitalAsset` instead. This can be inferred by looking at [`LSP8CappedSupply.sol`](https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8CappedSupply.sol), [`LSP8CompatibleERC721.sol`](https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8CompatibleERC721.sol) and [`LSP8Enumerable.sol`](https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8Enumerable.sol):

[LSP8CappedSupply.sol#L13](https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8CappedSupply.sol#L13)

```solidity
abstract contract LSP8CappedSupply is LSP8IdentifiableDigitalAsset {
```

Additionally, the `LSP8BurnableInitAbstract.sol` file is missing in the repository.

## Impact

As `LSP8Burnable` does not inherit `LSP8IdentifiableDigitalAsset`, a developer who implements his LSP8 token using `LSP8Burnable` will face the following issues:

* All functionality from `LSP4DigitalAssetMetadata` will be unavailable.
* As `LSP8Burnable` does not contain a `supportsInterface()` function, it will be incompatible with contracts that use [ERC-165](https://eips.ethereum.org/EIPS/eip-165).

## Recommended Mitigation

The `LSP8Burnable` contract should inherit `LSP8IdentifiableDigitalAsset` instead:

[LSP8Burnable.sol#L15](https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8Burnable.sol#L15)

```diff
-   abstract contract LSP8Burnable is LSP8IdentifiableDigitalAssetCore {
+   abstract contract LSP8Burnable is LSP8IdentifiableDigitalAsset {
```

Secondly, add a `LSP8BurnableInitAbstract.sol` file that contains an implementation of `LSP8Burnable` which can be used in proxies.


## Assessed type

Other
tx.origin may be removed in future and its usage is not recommended
Audit: 2023-06-lukso-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP1UniversalReceiver/LSP1UniversalReceiverDelegateUP/LSP1UniversalReceiverDelegateUP.sol#L103


# Vulnerability details

## Impact
There is a chance that tx.origin will be removed from the Ethereum protocol in the future, so code that uses tx.origin  must be avoid for the authentication purpose.

There is also some EIPs being proposed for change/remove of tx.origin.

https://github.com/ethereum/EIPs/issues/637

https://www.reddit.com/r/ethereum/comments/6d11lv/erc_about_txorigin_change_for_account_abstraction/

In LSP1UniversalReceiverDelegateUP.sol,

```Solidity
File: contracts/LSP1UniversalReceiver/LSP1UniversalReceiverDelegateUP/LSP1UniversalReceiverDelegateUP.sol

78    function universalReceiver(
79        bytes32 typeId,
80        bytes memory /* data */
81    ) public payable virtual returns (bytes memory result) {


     // Some code


103     if (notifier == tx.origin) revert CannotRegisterEOAsAsAssets(notifier);


     // Some code


143 }
```

Here, the function has used tx.origin at L-103 for authentication but these can not work in future if the new EIPs concerning to remove tx.origin removal due to security issues got approved and tx.origin is removed from Ethereum protocol.

## Proof of Concept
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP1UniversalReceiver/LSP1UniversalReceiverDelegateUP/LSP1UniversalReceiverDelegateUP.sol#L103

## Tools Used
Manual review

## Recommended Mitigation Steps
Use msg.sender instead of tx.origin.



## Assessed type

Other
`LSP8CompatibleERC721`'s `approve()` deviates from ERC-721 specification
Audit: 2023-06-lukso-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8CompatibleERC721.sol#L155-L158


# Vulnerability details

## Bug Description

The `LSP8CompatibleERC721` contract is a wrapper around LSP8 that is meant to function similarly to ERC-721 tokens. One of its implemented functions is ERC-721's `approve()`:

[LSP8CompatibleERC721.sol#L155-L158](https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8CompatibleERC721.sol#L155-L158)

```solidity
    function approve(address operator, uint256 tokenId) public virtual {
        authorizeOperator(operator, bytes32(tokenId));
        emit Approval(tokenOwnerOf(bytes32(tokenId)), operator, tokenId);
    }
```

As `approve()` calls `authorizeOperator()` from the `LSP8IdentifiableDigitalAssetCore` contract, only the owner of `tokenId` is allowed to call `approve()`:

[LSP8IdentifiableDigitalAssetCore.sol#L105-L113](https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP8IdentifiableDigitalAsset/LSP8IdentifiableDigitalAssetCore.sol#L105-L113)

```solidity
    function authorizeOperator(
        address operator,
        bytes32 tokenId
    ) public virtual {
        address tokenOwner = tokenOwnerOf(tokenId);

        if (tokenOwner != msg.sender) {
            revert LSP8NotTokenOwner(tokenOwner, tokenId, msg.sender);
        }
```

However, the implementation above deviates from the [ERC-721 specification](https://eips.ethereum.org/EIPS/eip-721), which mentions that an "authorized operator of the current owner" should also be able to call `approve()`:

```solidity
    /// @notice Change or reaffirm the approved address for an NFT
    /// @dev The zero address indicates there is no approved address.
    ///  Throws unless `msg.sender` is the current NFT owner, or an authorized
    ///  operator of the current owner.
    /// @param _approved The new approved NFT controller
    /// @param _tokenId The NFT to approve
    function approve(address _approved, uint256 _tokenId) external payable;
```

This means that anyone who is an approved operator for `tokenId`'s owner through `setApprovalForAll()` should also be able to grant approvals. An example of such behaviour can be seen in [Openzeppelin's ERC721 implementation](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol):

[ERC721.sol#L121-L123](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol#L121-L123)

```solidity
        if (_msgSender() != owner && !isApprovedForAll(owner, _msgSender())) {
            revert ERC721InvalidApprover(_msgSender());
        }
```

## Impact

As `LSP8CompatibleERC721`'s `approve()` functions differently from ERC-721, protocols that rely on this functionality will be incompatible with LSP8 tokens that inherit from `LSP8CompatibleERC721`. 

For example, in an NFT exchange, users might be required to
Allowed calls in `LSP6KeyManager` doesn't allow calls with empty calldata
Audit: 2023-06-lukso-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP6KeyManager/LSP6Modules/LSP6ExecuteModule.sol#L399-L416


# Vulnerability details

## Bug Description

Whenever a controller attempts to call a LSP0 account's `execute()` function without the relevant [SUPER permissions](https://docs.lukso.tech/standards/universal-profile/lsp6-key-manager/#super-permissions), `LSP6ExecuteModule` will check that the call is one of the whitelisted [allowed calls](https://docs.lukso.tech/standards/universal-profile/lsp6-key-manager/#allowed-calls).

If the controller is trying to perform a call with no calldata (eg. `.call("")`), [`_extractExecuteParameters()`](https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP6KeyManager/LSP6Modules/LSP6ExecuteModule.sol#L339-L364) decodes its function selector to `0x00000000`:

[LSP6ExecuteModule.sol#L352-L355](https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP6KeyManager/LSP6Modules/LSP6ExecuteModule.sol#L352-L355)

```solidity
        // CHECK if there is at least a 4 bytes function selector
        bytes4 selector = executeCalldata.length >= 168
            ? bytes4(executeCalldata[164:168])
            : bytes4(0);
```

However, the [`_isAllowedFunction()`](https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP6KeyManager/LSP6Modules/LSP6ExecuteModule.sol#L399-L416) will always return `false` for a `0x00000000` function selector if the allowed call only allows a specific function to be called:

[LSP6ExecuteModule.sol#L410-L415](https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP6KeyManager/LSP6Modules/LSP6ExecuteModule.sol#L410-L415)

```solidity
        bool isFunctionCall = requiredFunction != bytes4(0);

        // ANY function = 0xffffffff
        return
            allowedFunction == bytes4(type(uint32).max) ||
            (isFunctionCall && (requiredFunction == allowedFunction));
```

As `_isAllowedFunction()` is used to verify if the call being executed is whitelisted in allowed calls, this means that `execute()` calls with empty calldata will always fail. 

This is an issue as:
* Users that have `TRANSFERVALUE` permission but don't have `CALL` permission are only allowed to call `execute()` with empty calldata. 
* Setting the `allowedFunction` of an allowed call to `0xffffffff` will allow users with both permissions to call other functions in the contract at the same address.

For instance, if a user wants to allow other users to send LYX to a contract with a `receive()` function (eg.  other LSP0 accounts), but doesn't want them to be able to call other functions in the same contract, he will be unable to do so.

## Impact

Due to how calls with empty calldata are handled in `LSP6ExecuteModule`, `LSP6KeyManager` cannot be configured to only allow **only** transfers of LYX to a contract with a `receive()` function for users without `SUPER_TRANSFERVALUE` permission.  

## Proof of Concept

The following Foundry test demonstrat
Missing Input Validation
Audit: 2023-06-lukso-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP6KeyManager/LSP6Modules/LSP6SetDataModule.sol#L222


# Vulnerability details

## Impact
The below situations do not have checks on their inputs:

When `bytes12(inputDataKey) == _LSP6KEY_ADDRESSPERMISSIONS_PERMISSIONS_PREFIX`: 

```solidity=222
            // AddressPermissions:Permissions:<address>
            if (
                bytes12(inputDataKey) ==
                _LSP6KEY_ADDRESSPERMISSIONS_PERMISSIONS_PREFIX
            ) {
                // controller already has the permissions needed. Do not run internal function.
                if (hasBothAddControllerAndEditPermissions) return (bytes32(0));
```

According to LSP6, `inputDataValue` is expected to be exactly 32 bytes.

-----

When `inputDataKey == _LSP1_UNIVERSAL_RECEIVER_DELEGATE_KEY || bytes12(inputDataKey) == _LSP1_UNIVERSAL_RECEIVER_DELEGATE_PREFIX`:

```solidity=282
            // LSP1UniversalReceiverDelegate or LSP1UniversalReceiverDelegate:<typeId>
        } else if (
            inputDataKey == _LSP1_UNIVERSAL_RECEIVER_DELEGATE_KEY ||
            bytes12(inputDataKey) == _LSP1_UNIVERSAL_RECEIVER_DELEGATE_PREFIX
        ) {
            // same as above. If controller has both permissions, do not read the `target` storage
            // to save gas by avoiding an extra external `view` call.
            if (
                controllerPermissions.hasPermission(
                    _PERMISSION_ADDUNIVERSALRECEIVERDELEGATE |
                        _PERMISSION_CHANGEUNIVERSALRECEIVERDELEGATE
                )
            ) {
                return bytes32(0);
```

According to LSP1, `inputDataValue` is expected to be exactly 20 bytes (an address).

-----

When `bytes12(inputDataKey) == _LSP17_EXTENSION_PREFIX`:

```solidity=302
            // LSP17Extension:<bytes4>
        } else if (bytes12(inputDataKey) == _LSP17_EXTENSION_PREFIX) {
            // same as above. If controller has both permissions, do not read the `target` storage
            // to save gas by avoiding an extra external `view` call.
            if (
                controllerPermissions.hasPermission(
                    _PERMISSION_ADDEXTENSIONS | _PERMISSION_CHANGEEXTENSIONS
                )
            ) {
                return bytes32(0);
```

According to LSP17, `inputDataValue` is expected to be exactly 20 bytes (an address).

-----

When `inputDataKey == _LSP6KEY_ADDRESSPERMISSIONS_ARRAY`: 

```solidity=340
        // AddressPermissions[] -> array length
        if (inputDataKey == _LSP6KEY_ADDRESSPERMISSIONS_ARRAY) {
            // if the controller already has both permissions from one of the two required,
            // No permission required as CHECK is already done. We don't need to read `target` storage.
            if (hasBothAddControllerAndEditPermissions) return bytes32(0);
```

According to LSP2, `inputDataValue` is expected to be exactly 16 bytes (the array length).


## Recommended Mitigation Steps

Add val
initialize function can be front run
Audit: 2023-06-lukso-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP7DigitalAsset/extensions/LSP7CompatibleERC20InitAbstract.sol#L33
https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8CompatibleERC721InitAbstract.sol#L61


# Vulnerability details

## Impact
Initialize function have the potential of front running by a malicious actor. An attacker can front-run the deployer and takeover the contract by setting itself as the owner in the Contract. Taking ownership will result in carrying out malicious acts that cause loss of funds for project and user.

## Proof of Concept
1.	https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP7DigitalAsset/extensions/LSP7CompatibleERC20InitAbstract.sol#L33
2.	https://github.com/code-423n4/2023-06-lukso/blob/main/contracts/LSP8IdentifiableDigitalAsset/extensions/LSP8CompatibleERC721InitAbstract.sol#L61


## Tools Used
Past relative audit reports. 
1.	https://solodit.xyz/issues/initialization-functions-can-be-front-run-trailofbits-advanced-blockchain-pdf
2.	https://solodit.xyz/issues/possible-front-running-on-initialization-halborn-biconomy-bico-token-pdf


## Recommended Mitigation Steps
Implement use of factory pattern to deploy and initialise contract with enhancing access control to the initialize functions.



## Assessed type

Access Control
All Ether sent to LSP0ERC725Account will be permanently locked
Audit: 2023-06-lukso-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L117


# Vulnerability details

## Impact
All Ether sent to LSP0ERC725Account will be permanently locked because it inherits the `receive` function  from the LSP0ERC725AccountCore contract but does not have a withdraw function.

## Proof of Concept
All Ether sent to LSP0ERC725Account will be permanently locked because it inherits the `receive` function  from the LSP0ERC725AccountCore contract but does not have a withdraw function.

```
contract LSP0ERC725Account is LSP0ERC725AccountCore {
```
```
abstract contract LSP0ERC725AccountCore is
    ERC725XCore,
    ERC725YCore,
    IERC1271,
    ILSP0ERC725Account,
    ILSP1UniversalReceiver,
    LSP14Ownable2Step,
    LSP17Extendable,
    LSP20CallVerification
{
...//ommitted code
receive() external payable virtual {//@audit can receive ether but no withdraw.
        if (msg.value != 0) {
            emit ValueReceived(msg.sender, msg.value);
        }
    }
...//omitted code
```

## Tools Used
Manual Review

## Recommended Mitigation Steps
Consider adding a withdraw function to the LSP0ERC725Account contract or the LSP0ERC725AccountCore contract.


## Assessed type

ETH-Transfer
Failed transfer with low level call could be overlooked
Audit: 2023-06-lukso-findings
Severity: MEDIUM

# Lines of code

https://github.com/ERC725Alliance/ERC725/blob/7171a0e25e83cfe4c4dec6262bb62b4422c0478f/implementations/contracts/ERC725XCore.sol#L177
https://github.com/ERC725Alliance/ERC725/blob/7171a0e25e83cfe4c4dec6262bb62b4422c0478f/implementations/contracts/ERC725XCore.sol#L194
https://github.com/ERC725Alliance/ERC725/blob/7171a0e25e83cfe4c4dec6262bb62b4422c0478f/implementations/contracts/ERC725XCore.sol#L211


# Vulnerability details

## Impact
Transfers may fail silently.

## Proof of Concept
- According to the [Solidity docs](https://docs.soliditylang.org/en/v0.8.6/control-structures.html#error-handling-assert-require-revert-and-exceptions):
 "The low-level functions `call`,` delegatecall` and `staticcall` return `true` as their first return value if the account called is non-existent, as part of the design of the EVM. Account existence must be checked prior to calling if needed".
- For reference, see a similar high severity reported in a Uniswap audit here (report # 9): https://github.com/Uniswap/v3-core/blob/main/audits/tob/audit.pdf
```
File: ERC725XCore
177:        (bool success, bytes memory returnData) = target.call{value: value}(data);
----
194:        (bool success, bytes memory returnData) = target.staticcall(data);
---- 
211:        (bool success, bytes memory returnData) = target.delegatecall(data);
```
[ERC725XCore#_executeCall](https://github.com/ERC725Alliance/ERC725/blob/7171a0e25e83cfe4c4dec6262bb62b4422c0478f/implementations/contracts/ERC725XCore.sol#L177) 
[ERC725XCore#_executeStaticCall](https://github.com/ERC725Alliance/ERC725/blob/7171a0e25e83cfe4c4dec6262bb62b4422c0478f/implementations/contracts/ERC725XCore.sol#L194)
[ERC725XCore#_executeDelegateCall](https://github.com/ERC725Alliance/ERC725/blob/7171a0e25e83cfe4c4dec6262bb62b4422c0478f/implementations/contracts/ERC725XCore.sol#L211)


## Tools Used
Manual Review
## Recommended Mitigation Steps
Check for the account's existence prior to transferring.


## Assessed type

Token-Transfer
Incorrect Interface ID for LSP0
Audit: 2023-06-lukso-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0Constants.sol#L5


# Vulnerability details

## Impact
The interface ID stated for LSP0 in `LSP0Constants.sol` and [LIP-0](https://github.com/lukso-network/LIPs/blob/main/LSPs/LSP-0-ERC725Account.md) is `0x3e89ad98`, which will affect related logics.

## Proof of Concept


According to LIP-0, this ID is derived from the XOR of the following:
- selector of `batchCalls()`
- IDs of the following standards:
  - ERC725Y
  - ERC725X
  - LSP1-UniversalReceiver
  - ERC1271-isValidSignature
  - LSP14Ownable2Step
  - LSP17Extendable
  - LSP20CallVerification
 
However, the XOR of all of the above is `0x24871b3d`. We note that if we remove the LSP20CallVerification standard, then we obtain the stated interface ID of `0x3e89ad98`.



## Tools Used
Manual

## Recommended Mitigation Steps
Change the interface ID of LSP0 if the LSP20CallVerification standard is meant to be included.


## Assessed type

Context
Incorrect Interface ID for LSP14
Audit: 2023-06-lukso-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP14Ownable2Step/LSP14Constants.sol#L4


# Vulnerability details

## Impact
Contracts that use `type(ILSP14Ownable2Step).interfaceId`, such as when implementing `IERC165.supportsInterface()`, will use a value different from the current standard.

## Proof of Concept
The interface ID of LSP14 is stated to be `0x94be5999`. However, the interface ID of `ILSP14Ownable2Step` is `0x191b92c2`. This is because `ILSP14Ownable2Step` does not contain the function `owner()`. 



## Tools Used
Manual

## Recommended Mitigation Steps

As other standards, such as LSP0 and LSP9, assume the interface ID of LSP14 is `0x94be5999`, it is recommended to add the function `owner()` to `ILSP14Ownable2Step`.


## Assessed type

Context
Inconsistencies When Using Inherited Functions
Audit: 2023-06-lukso-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L241
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L253
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L305
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L317
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L356
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L363
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L409
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L422
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L469
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L503
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L583
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L605
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L669
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L677
https://github.com/code-423n4/2023-06-lukso/blob/9dbc96410b3052fc0fd9d423249d1fa42958cae8/contracts/LSP0ERC725Account/LSP0ERC725AccountCore.sol#L862


# Vulnerability details

## Impact
The contract `LSP0ERC725AccountCore` contains several instances of using an inherited function whose implementation is the same as the one defined in the inherited contract as well as using a possibly overridden version of the function. This allows inconsistencies in the event that a function is overridden.

## Proof of Concept
### `ERC725YCore._getData()`

The same implementation of `_getData()` as defined in `ERC725YCore` is used on line 862. 

```solidity=869
            bytes20(ERC725YCore._getData(mappedExtensionDataKey))
```

However, a possibly overridden version of `_getData()` is used on lines 469 and 503.

```solidity=469
        bytes memory lsp1DelegateValue = _getData(
            _LSP1_UN