Summary

I'm unsure of how to classify this, as it may be out of scope, but in terms of severity I believe it to be a low level risk as an exploitable arithmetic overflow or underflow scenario.

The HelperConfig script hardcodes the price feed from Chainlink for DSC/USD as always having 8 decimals.
It's important to be aware the number of decimals can vary and this could lead to false calculations that might be exploited in the DSCengine contract.

Vulnerability Details

HelperConfig.s.sol

Given how the HelperConfig interacts with the protocol, in the DSCengine contract, this would effect functions: getTokenAmountFromUsd and getUsdValue, involving the calculations fetched from the Chainlink oracle.

For example: if the price feed returned a price of $1 as 1 (without decimal places), the calculations performed by these functions would be off by a factor of 100 million (10^8), resulting in token amounts and values significantly higher or lower than expected.

Recommendations

The contract should include checks/effects/interactions to validate the number of decimal places in the price feed to match the expected number.

An example implementation could be:

This would ensure 8 decimal places in the price feed aren't hardcoded.