CoinFabrik/scout-substrate huggingface dataset:
Audit finding: Existential deposit of EVM template could suggest setting it to 0
Project: PolkadotRunetimeTemplates
Auditor: Security Research Labs
Location: evm-template/runtime/src/constants.rs
Impact: Low
Vulnerability class (Scout): Denial of Service (DoS) and Spamming
Status: Risk accepted [13] [Online]. Available: https://github.com/OpenZeppelin/polkadot-runtime-templates/issues/195.

3.2.3 Existential deposit of EVM template could suggest setting it to 0

Attack scenario:
Existential deposit configuration is suggested to be zero

Location:
evm-template/runtime/src/constants.rs

Attack impact:
Existential deposit of 0 could lead to spamming through creating a high number of accounts and thereby slowing down the chain operation

Severity:
Low

Status:
Risk accepted [13]

The minimum balance that an account must maintain to be considered a valid active account in Polkadot is EXISTENTIAL_DEPOSIT (ED). If an account’s balance falls below this threshold, all its funds are lost, and the account is removed by the network.

In the EVM template, ED is set [14] to zero for no benchmark feature build. A new runtime developer may accidentally set the ED value to zero. This could lead to an attacker creating multiple free accounts, occupying network resources and slowing down the chain. Allowing an account to remain active with zero ED could also lead to a spam attack.

It is recommended to remove the ED value of zero from the runtime template and document in inline comment that its value must be above zero. Every parachain will have its own threshold for ED, either in their native token or DOT. Furthermore, we recommend explaining these two configurations in the inline comment for the ED parameter in the runtime template. This will benefit new runtime developers by helping them avoid misconfiguring this safety-critical parameter.

A guideline on choosing a suitable ED value may be provided as below:
𝐸𝐷 = 𝑀𝑖𝑛 𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑟𝑒𝑑𝑢𝑛𝑑𝑎𝑛𝑡 𝑐𝑜𝑙𝑙𝑎𝑡𝑜𝑟𝑠 × 𝑆𝑡𝑜𝑟𝑎𝑔𝑒 𝑑𝑢𝑟𝑎𝑡𝑖𝑜𝑛 (𝑦𝑒𝑎𝑟𝑠) × 𝑆𝑡𝑜𝑟𝑎𝑔𝑒 𝑐𝑜𝑠𝑡 𝑝𝑒𝑟 𝑦𝑒𝑎𝑟

Summary: Existential deposit set to zero could allow attackers to spam the network by creating multiple free accounts.
Audit finding: Incorrect parameter could lead to runtime panic
Project: PolkadotRunetimeTemplates
Auditor: Security Research Labs
Location: evm-template/runtime/src/configs/mod.rs
Impact: Low
Vulnerability class (Scout): Arithmetic
Status: Fixed [15] [Online]. Available: https://github.com/OpenZeppelin/polkadot-runtime-templates/pull/246.

3.2.4 Incorrect parameter could lead to runtime panic

Attack scenario:
Misconfiguration of dependent critical parameters in runtime

Location:
evm-template/runtime/src/configs/mod.rs

Attack impact:
Runtime crash or wraparound of gas limit ratio causing runtime panics

Severity:
Low

Status:
Fixed [15]

The GasLimitPovSizeRatio [16] is the ratio of the amount of Gas (BlockGasLimit) to the Proof Size (MAX_POV_SIZE) for a block. The GasLimitPovSizeRatio is used in GasWeightMapping [17] to obtain the weight of the corresponding proof size.

In the EVM runtime template, GasLimitPovSizeRatio may reach a large value or wrap to zero causing runtime crash. This can be enabled through setting the dependent parameter BlockGasLimit to zero or Max value in the runtime.

Ensure that GasLimitPovSizeRatio is bounded within U64 data following the implementation in Frontier template from Polkadot [18]. Also consider documenting the risk of deviating outside the range such that the runtime developer is aware of potential risk from misconfiguring this value.

Summary: Misconfigured GasLimitPovSizeRatio could cause runtime crashes or wraparounds due to improper parameter values.
Audit finding: Usage of deprecated CurrencyAdapter in transaction_payment
Project: PolkadotRunetimeTemplates
Auditor: Security Research Labs
Location: runtime/src/configs/mod.rs
Impact: Low
Vulnerability class (Scout): Dependency
Status: Open [19] [Online]. Available: https://github.com/OpenZeppelin/polkadot-runtime-templates/issues/251.

3.2.5 Usage of depreciated CurrencyAdapter in transaction_payment

Attack scenario:
Usage may result in unexpected behavior and future edge-cases.

Location:
runtime/src/configs/mod.rs

Attack impact:
There may be inconsistencies in the computation of transferable balances, and future undefined behavior.

Severity:
Low

Status:
Open [19]

The runtime configuration for pallet_transaction_payment relies on the deprecated (since v1.6.0) CurrencyAdapter [20].

The discrepancy this introduces may result in unexpected behavior and inconsistencies when calculating transferable balances. We recommend migrating to the supported FungibleAdapter and Fungible traits.

Summary: Deprecated CurrencyAdapter may cause inconsistencies in balance calculations and undefined behavior.
Audit finding: Misconfiguration of MaxRemoteLockConsumers in pallet_xcm
Project: PolkadotRunetimeTemplates
Auditor: Security Research Labs
Location: runtime/src/configs/xcm_config.rs
Impact: Low
Vulnerability class (Scout): Error Handling and Validation
Status: Fixed [21] [Online]. Available: https://github.com/OpenZeppelin/polkadot-runtime-templates/pull/268.

3.2.6 Misconfiguration of MaxRemoteLockConsumers in pallet_xcm

Attack scenario:
Misconfiguration may result in unintended side-effects and failed assumptions

Location:
runtime/src/configs/xcm_config.rs

Attack impact:
Unintentional behavior may be present in pallet_xcm

Severity:
Low

Status:
Fixed [21]

In pallet_xcm::Config both MaxLockers [22] and MaxRemoteLockConsumers [23] types have been set to the constant MaxLockers: u32 = 8.

The standard configuration of MaxRemoteLockConsumers is zero [24], which is declared in an unused constant MaxRemoteLockConsumers: u32 = 0.

Based on this analysis and the lack of documentation around the deviation from the standard configuration, we assume this MaxRemoteLockConsumers was misconfigured to 8 not 0.

This may result in unintended side-effects that are unknown to users implementing the template. If this configuration was intentional, the rationale behind it should be explicitly stated.

We recommend configuring MaxRemoteLockConsumers to the declared constant MaxRemoteLockConsumers: u32 = 0.

Summary: Misconfiguration of MaxRemoteLockConsumers may cause unintended side-effects in pallet_xcm.
Audit finding: Missing documentation undermines the templates' use-case
Project: PolkadotRunetimeTemplates
Auditor: Security Research Labs
Location: runtime/src/configs/
Impact: Info
Vulnerability class (Scout): Code Quality
Status: Fixed [25] [Online]. Available: https://github.com/OpenZeppelin/polkadot-runtime-templates/pull/250.

3.2.7 Missing documentation undermines the templates' use-case

Attack scenario:
Novice substrate developers may unknowingly alter sound security design due to ambiguity of rationale

Location:
runtime/src/configs/

Attack impact:
Configuration alteration could result in preventable vulnerabilities being re-opened.

Severity:
Info

Status:
Fixed [25]

Throughout the runtime configurations, design rationale is frequently undocumented. Considering the runtime templates' use-case, to offer an entry point for secure substrate development, we believe the lack of documentation negatively impacts these intentions by introducing design ambiguity.

We recommend documenting all critical configurations to outline: the current design rationale; the security considerations for modification; and disclaimers around incompatible modifications.

Specifically, we have identified the following key areas that require specific justification, although more likely exist:
1. In xcm_executor the mutual exclusivity of IsReserve [26] and IsTeleport [27] should be documented, alongside the importance of non-null FeeManager [28].
2. In cumulus_pallet_xcmp_queue PriceForSiblingParachainDelivery [29], the ramifications of null configuration should be described.
3. The rationale and risk of not including a non-zero ExistentialDeposit [30] in pallet_balances should be fully described.
4. The configuration options for FeeMultiplierUpdate [31] in pallet_transaction_payment should be explained (e.g., SlowAdjusting / FastAdjusting).
5. All pallets' WeightInfo configuration should have a disclaimer to perform benchmarking in the context of the user’s specific runtime.
6. The process for calculating GasLimitPovSizeRatio [16] in pallet_evm should be outlined.

Summary: Lack of documentation for critical configurations may lead to preventable security vulnerabilities.
Audit finding: Sudo is enabled on the Acala chain
Project: Acala
Auditor: Trail of Bits
Location: bin/acala/service/src/chain_spec/acala.rs:164
Impact: Informational
Likelihood: Difficulty-Medium
Vulnerability class (audit): Configuration
Vulnerability class (Scout): Business Logic

2. Sudo is enabled on the Acala chain\nSeverity: Informational\nDifficulty: Medium\nType: Configuration\nFinding ID: TOB-ACA-002\nTarget: Acala/bin/acala/service/src/chain_spec/acala.rs#L164\n\nDescription\nThe Acala chain spec uses the sudo module (Figure 2.1), which allows for robust testing but should not exist in a production network. The existence of a sudo functionality, or, a lack of clear documentation of a sudo removal step may decrease the users' trust in the Acala Network.\n\nacala_runtime::GenesisConfig {\n  // (...)\n  pallet_sudo: Some(SudoConfig { key: root_key.clone() }),\n}\n\nFigure 2.1: The sudo pallet enabled in Acala chain specification (Acala/bin/acala/service/src/chain_spec/acala.rs#L164).\n\nRecommendation\nShort term, either remove the sudo functionality from the Acala chain specification or document how it will be disabled or removed after the network goes live, similarly to what Polkadot did during its launch.

Summary: The sudo module is enabled, which should not be present in a production network due to security concerns.
Audit finding: Changed but unused liquidAmountToBurn value
Project: Acala
Auditor: Trail of Bits
Location: packages/sdk-homa/src/staking-pool.ts:165-179,275-289
Impact: Informational
Likelihood: Difficulty-High
Vulnerability class (audit): Undefined Behavior
Vulnerability class (Scout): Code Quality

3. Changed but unused liquidAmountToBurn value\nSeverity: Informational\nDifficulty: High\nType: Undefined Behavior\nFinding ID: TOB-ACA-003\nTarget: acala.js/packages/sdk-homa/src/staking-pool.ts\n\nDescription\nThere are two places in the acala.js codebase where a variable of liquidAmountToBurn is introduced, used, changed but unused further in the flow (Figures 3.1-2). Those cases should be further investigated as they could be real bugs.\n\npublic getStakingAmountInRedeemByFreeUnbonded(/* (...) */): { /* (...) */ } {\n  // (...)\n  let liquidAmountToBurn = amount;\n  let demandStakingAmount = liquidExchangeRate.times(liquidAmountToBurn);\n  // (...)\n  if (!demandStakingAmount.isZero() && !availableFreePool.isZero()) {\n    if (demandStakingAmount.isGreaterThan(availableFreePool)) {\n      const ratio = FixedPointNumber.fromRational(availableFreePool, demandStakingAmount);\n      liquidAmountToBurn = ratio.times(liquidAmountToBurn);\n      demandStakingAmount = availableFreePool;\n    }\n  }\n  // (...) - the liquidAmountToBurn value is unused\n}\n\nFigure 3.1: The getStakingAmountInRedeemByFreeUnbonded function (acala.js/packages/sdk-homa/src/staking-pool.ts#L165-L179).\n\npublic getStakingAmountInClaimUnbonding(/* (...) */): { /* (...) */ } {\n  // (...)\n  let liquidAmountToBurn = amount;\n  let demandStakingAmount = liquidExchangeRate.times(liquidAmountToBurn);\n  // (...)\n  if (!demandStakingAmount.isZero() && !availableUnclaimedUnbonding.isZero()) {\n    if (demandStakingAmount.isGreaterThan(availableUnclaimedUnbonding)) {\n      const ratio = FixedPointNumber.fromRational(availableUnclaimedUnbonding, demandStakingAmount);\n      liquidAmountToBurn = ratio.times(liquidAmountToBurn);\n      demandStakingAmount = availableUnclaimedUnbonding;\n    }\n  }\n  // (...) - the liquidAmountToBurn value is unused\n}\n\nFigure 3.2: The getStakingAmountInClaimUnbonding function (acala.js/packages/sdk-homa/src/staking-pool.ts#L275-L289).\n\nRecommendation\nShort term, evaluate the change of liquidAmountToBurn value in the getStakingAmountInRedeemByFreeUnbounded and getStakingAmountInClaimUnbonding functions in the acala.js codebase.

Summary: The variable liquidAmountToBurn is changed but remains unused, potentially indicating a bug.
Audit finding: Transferring 'MAX' ACA tokens through Acala-dapp fails and only burns the fees
Project: Acala
Auditor: Trail of Bits
Impact: Low
Likelihood: Difficulty-Low
Vulnerability class (audit): Data Validation
Vulnerability class (Scout): Business Logic

4. Transferring "max" ACA tokens through Acala-dapp fails and only burns the fees\nSeverity: Low\nDifficulty: Low\nType: Data Validation\nFinding ID: TOB-ACA-004\nTarget: Acala / Acala-dapp\n\nDescription\nThe Acala-dapp UI provides a way of transferring all tokens to a given account via the "MAX" button in its "Transfer" dialog (Figure 4.1). However, trying to perform a transfer of ACA tokens with the "MAX" amount always fails with a "balances.InsufficientBalance" result (Figure 4.2) and the sender ends up losing the transfer fees.\n\nFigure 4.1: The "Transfer" dialog with the "MAX" button.\n\nFigure 4.2: The "balances.InsufficientBalance" error displayed in the top right corner of Acala-dapp when attempting to transfer "MAX" ACA tokens amount.\n\nExploit Scenario\nAlice wants to transfer all of her ACA tokens into another account. She uses the "MAX" transfer option through the Acala-dapp application. The transfer fails and Alice ends up with the transfer fees deducted from her ACA tokens balance.\n\nRecommendations\nShort term, fix the inability of transferring "MAX" ACA tokens amount to another account through Acala-dapp. This can be done by adding a special "transfer of all ACA tokens" extrinsic that would first deduct the fees and then perform the transfer of the remaining tokens, and using that extrinsic when sending a "MAX" ACA tokens transfer in the Acala-dapp UI.\n\nLong term, add tests to ensure the "MAX" ACA and other tokens transfer succeeds. This will prevent similar bugs from appearing if the code changes. All financial transactions should be tested with both use cases and misuse cases.

Summary: Transferring the 'MAX' token amount fails, resulting in lost transfer fees.
Audit finding: The Substrate dependency 'chaostests' contain out of date dependencies that have security vulnerabilities
Project: Acala
Auditor: Trail of Bits
Location: Cargo.toml:from,to
Impact: Informational
Likelihood: Difficulty-Undetermined
Vulnerability class (audit): Patching
Vulnerability class (Scout): Dependency

5. The Substrate dependency "chaostests" contain out of date dependencies that have security vulnerabilities\nSeverity: Informational\nDifficulty: Undetermined\nType: Patching\nFinding ID: TOB-ACA-005\nTarget: Acala's dependency substrate/.maintain/chaostests dependencies\n\nDescription\nThe Substrate dependency version 6b600cdeb used by Acala uses two outdated dependencies that contain security vulnerabilities in its testing framework called "chaostests".\n\nThe outdated dependencies are:\n- Node-fetch version 1.7.3, with a DoS vulnerability (CVE-2020-15168), fixed in 2.6.1.\n- Node-forge version 0.8.5, with a prototype pollution vulnerability (CVE-2020-7720), fixed in 0.10.0.\n\nThe severity of this finding is set to Informational as we believe this issue does not impact the security of the Acala blockchain since the vulnerable code is not used by Acala code.\n\nRecommendations\nShort term, update the Substrate dependency used in Acala to the latest version as its newer version doesn't contain the chaostests framework that contains security vulnerabilities in its dependencies.\n\nLong term, implement dependency checks for Acala's dependencies (and their dependencies) as part of the CI/CD pipeline of application development. Do not allow builds to continue with any outdated dependencies.

Summary: The 'chaostests' dependency includes outdated libraries with known security vulnerabilities.
Audit finding: Lack of proper development guidance on using Acala-dapp with Acala
Project: Acala
Auditor: Trail of Bits
Impact: Informational
Vulnerability class (audit): Documentation
Vulnerability class (Scout): Code Quality

6. Lack of proper development guidance on using Acala-dapp with Acala\nSeverity: Informational\nDifficulty: Undetermined\nType: Documentation\nFinding ID: TOB-ACA-006\nTarget: Acala development documentation\n\nDescription\nThe Acala Development Guide lacks proper documentation on how to use a local build of Acala-dapp and Acala node to test or develop the Acala blockchain. It is also not clear how to match the versions of the two, as the git commits that change corresponding dependencies versions are not having clear commit messages.\n\nIn Appendix D we describe steps for testing Acala and Acala-dapp with its test/development accounts (Alice, Bob, etc.) that could be added to the development guide.\n\nRecommendations\nShort term, add steps for testing Acala and Acala-dapp locally with blockchain test/development accounts (Alice, Bob, etc.) into Acala's README or/and Development Guide. This will help developers to bootstrap a working environment and test features faster.

Summary: The development guide lacks clear steps for testing and matching dependencies between components.
Audit finding: CSRF in Acala/apps settings which allows changing the RPC endpoint URL
Project: Acala
Auditor: Trail of Bits
Impact: Informational
Likelihood: Difficulty-Medium
Vulnerability class (audit): Data Validation
Vulnerability class (Scout): Error Handling and Validation

7. CSRF in Acala/apps settings which allows changing the RPC endpoint URL\nSeverity: Informational\nDifficulty: Medium\nType: Data Validation\nFinding ID: TOB-ACA-007\nTarget: Acala/apps\n\nDescription\nThere is a Cross-Site Request Forgery (CSRF) vulnerability in the settings page of the polkadot.js/apps project on which the Acala/apps project is based upon. This allows an attacker to send a malicious link to the victim, which will change the victim's RPC endpoint URL.\n\nThe issue has been reported to the upstream repository in polkadot.js/apps#4465.\n\nRecommendations\nShort term, fix the CSRF issue in Acala/apps which was reported in polkadot.js/apps#4465. This will prevent an attacker from sending a malicious link to its victim that will change the RPC endpoint URL. If possible, send a patch that fixes this issue to the upstream repository.\n\nLong term, keep track of the polkadot.js/apps changes and update the Acala/apps repository regularly. This will help prevent similar issues to occur in the future.

Summary: CSRF vulnerability allows changing the RPC endpoint URL via a malicious link.
Audit finding: Missing security-related HTTP headers in the Acala-dapp application
Project: Acala
Auditor: Trail of Bits
Impact: Low
Likelihood: Difficulty-High
Vulnerability class (audit): Configuration
Vulnerability class (Scout): Error Handling and Validation

8. Missing security-related HTTP headers in the Acala-dapp application\nSeverity: Low\nDifficulty: High\nType: Configuration\nFinding ID: TOB-ACA-008\nTarget: Acala/acala-dapp\n\nDescription\nThe responses from the Acala-dapp website are missing the following security-related HTTP headers:\n● Content-Security-Policy. The lack of this header could allow for an attacker to exploit XSS vulnerabilities that a CSP might otherwise mitigate.\n● X-Frame-Options that can prevent the site from being rendered e.g. in an iframe and mitigates clickjacking attacks. Currently, if the site is rendered in an iframe, it won't work properly e.g. with the Polkadot{.js} extension as it doesn't work in iframes. The extension has an issue for it in polkadot-js/extension#531 and if it gets fixed, it will make Acala-dapp less secure due to lack of the X-Frame-Options setting.\n\nExploit Scenario\nEve finds a bug in Acala-dapp which allows her to trigger an XSS attack on Alice's browser when she executes an action. Eve then prepares a custom-crafted XSS payload. Due to a lack of CSP header, Alice's browser executes Eve’s attack and Eve executes actions on behalf of Alice's account.\n\nRecommendation\nShort term, add the missing security-related HTTP headers to Acala-dapp. Prevent the site from being rendered in iframes with X-Frame-Options: DENY header and implement the CSP policy and validate it with a CSP Evaluator. This will help mitigate the effects of attacks such as clickjacking or XSS.\n\nLong term, track the further developments of CSP and similar web browser features that help with mitigating security risk. As new protections are developed, ensure they are adopted as quickly as possible.\n\nReferences\n● Mozilla developer docs: Content Security Policy\n● CSP evaluator from Google

Summary: Missing HTTP headers such as Content-Security-Policy and X-Frame-Options allow XSS and clickjacking attacks.
Audit finding: Small amounts are not displayed in Acala-dapp or are displayed in a scientific notation
Project: Acala
Auditor: Trail of Bits
Impact: Informational
Likelihood: Difficulty-Low
Vulnerability class (audit): Undefined Behavior
Vulnerability class (Scout): Code Quality

9. Small amounts are not displayed in Acala-dapp or are displayed in a scientific notation\nSeverity: Informational\nDifficulty: Low\nType: Undefined Behavior\nFinding ID: TOB-ACA-009\nTarget: Acala/acala-dapp\n\nDescription\nThe Acala-dapp presents small amounts of values in a scientific notation (Figures 9.1-2) and if a value is too small, e.g. 0.00000001 it may not be presented at all (Figure 9.2). This behavior may be confusing for users who don't understand the rules of displaying the values present in the system.\n\nFigure 9.1: Small amount is displayed in a scientific notation.\n\nFigure 9.2: While the account has 0.00000001 XBTC which can be seen by trying to transfer \"MAX\" XBTC tokens, the UI does not have an option to display this value at all.\n\nRecommendations\nShort term, change the way small values are displayed in the Acala-dapp. Allow the user to specify the amount of decimal places to be displayed and inform the user if they have a small, non-zero value of a given token which is not currently displayed.\n\nLong term, add tests to Acala-dapp to see if it allows the user to see a small amount of tokens.

Summary: Small token values are not displayed or are shown in scientific notation, causing potential user confusion.
Audit finding: Providing too small value renders Acala-dapp unresponsive
Project: Acala
Auditor: Trail of Bits
Impact: Informational
Likelihood: Difficulty-Low
Vulnerability class (audit): Denial of Service
Vulnerability class (Scout): Denial of Service (DoS) and Spamming

10. Providing too small value renders Acala-dapp unresponsive\nSeverity: Informational\nDifficulty: Low\nType: Denial of Service\nFinding ID: TOB-ACA-010\nTarget: Acala/acala-dapp\n\nDescription\nPassing in a too small value into the \"Receive\" form field in the \"Swap\" tab renders the Acala-dapp application unresponsive. This prevents the user from performing an action which is valid within the system.\n\nThis can be reproduced by going to the \"Swap\" tab, choosing e.g. the XBTC currency and pasting in the \"0.000000001\" (or smaller) value into the \"Receive\" form as shown in Figure 10.1.\n\nFigure 10.1: Providing a too small value into the \"Receive\" field caused the page to hang.\n\nRecommendations\nShort term, fix the unresponsiveness of Acala-dapp when a small number is provided into the \"Receive\" form of the \"Swap\" functionality.\n\nLong term, add functional tests against forms in Acala-dapp to see if they correctly handle small values or malicious inputs.

Summary: Providing too small a value causes the application to become unresponsive; fixing this requires updating input validation in the 'Receive' form of the 'Swap' functionality.