Prepared by:
HALBORN
Last Updated 06/11/2025
Date of Engagement: May 21st, 2025 - May 30th, 2025
100% of all REPORTED Findings have been addressed
All findings
5
Critical
0
High
0
Medium
3
Low
2
Informational
0
TAC
engaged Halborn
to conduct a security assessment of their smart contracts from May 21st, 2025 to May 30th, 2025. The assessment focused on specific changes made to a Cosmos module provided to the Halborn
team. Commit hashes and additional details are available in the Scope section of this report.
The Halborn team assigned two full-time security engineers to evaluate the security of the merge requests. These engineers are experts in blockchain and smart contract security, possessing advanced skills in penetration testing, smart contract auditing, and extensive knowledge of multiple blockchain protocols.
The objectives of this assessment were to:
Verify that the Golang components function as intended.
Identify potential security vulnerabilities within the Cosmos application.
In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were acknowledged by the TAC team
. The main ones were the following:
Reverse the condition so that TxHash consistently reflects the intended header.
Assign rpcAddr directly from cfg.JSONRPC.Address to ensure the server binds to the configured host and port.
Assign each CommissionRates field from its corresponding Commission field.
Halborn employed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy within the scope of the custom modules. Manual testing was used to uncover logical, procedural, and implementation flaws, while automated testing enhanced coverage and quickly identified deviations from security best practices. The following phases and tools were utilized during the assessment:
Research into architecture and purpose.
Static analysis of the scoped repository and imported functions using tools such as staticcheck
, gosec
, unconvert
, codeql
, ineffassign
, and semgrep
.
Manual assessment to identify security vulnerabilities within the codebase.
Verification of codebase correctness.
Dynamic analysis of files and modules within scope.
CosmosEVM
security assessment is limited to the files directly affected by the four Pull Requests listed in the Sources section. Only changes introduced or modified in this comparison were considered; any pre-existing vulnerabilities or issues outside these specific files are beyond the scope of this review. Additionally, the audit does not cover dependencies, configuration files, or runtime environments. Therefore, findings and recommendations apply solely to the code and files added, removed, or modified in this branch comparison.
TacChain
is a fork of Cosmos EVM with minimal changes. This audit focused exclusively on the following modifications:
Custom Inflation Formulas
ERC20
WASM Removal
EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
---|---|---|
Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
---|---|---|
Confidentiality (C) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
---|---|---|
Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
Severity | Score Value Range |
---|---|
Critical | 9 - 10 |
High | 7 - 8.9 |
Medium | 4.5 - 6.9 |
Low | 2 - 4.4 |
Informational | 0 - 1.9 |
Critical
0
High
0
Medium
3
Low
2
Informational
0
Security analysis | Risk level | Remediation Date |
---|---|---|
Incorrect TxHash assignment in EthHeaderFromTendermint leads to malformed headers | Medium | Risk Accepted - 06/10/2025 |
Misassignment of CommissionRates fields in NewMsgCreateValidator | Medium | Risk Accepted - 06/10/2025 |
Hardcoded loopback binding in NewWebsocketsServer prevents intended network exposure | Medium | Risk Accepted - 06/10/2025 |
Using vulnerable dependencies | Low | Acknowledged - 06/10/2025 |
Division by Zero in Custom Inflation Formulas | Low | Acknowledged - 06/10/2025 |
//
The EthHeaderFromTendermint
function, located in the rpc/types/utils.go file, converts a Tendermint header into an Ethereum header.
func EthHeaderFromTendermint(header cmttypes.Header, bloom ethtypes.Bloom, baseFee *big.Int) *ethtypes.Header {
txHash := ethtypes.EmptyRootHash
if len(header.DataHash) == 0 {
txHash = common.BytesToHash(header.DataHash)
}
The function initializes txHash
with ethtypes.EmptyRootHash
and overwrites it only when the block contains no transaction data. As a result, blocks with transactions retain the empty root value, while empty blocks receive a non-empty hash derived from header.DataHash
. This causes Ethereum headers to have an incorrect TxHash
field for non-empty blocks, which can disrupt the header Merkle-proof validation process.
It is recommended to reverse the condition, so TxHash
always reflects the intended header.
txHash := ethtypes.EmptyRootHash
if len(header.DataHash) != 0 {
txHash = common.BytesToHash(header.DataHash)
}
RISK ACCEPTED: The TAC team accepted the risk with the following comment - "This logic comes from the original Cosmos/EVM codebase, which we have not modified. We have informed the ICL team, who confirmed it will be addressed in their next release; we have not observed any issues with TxHash handling during empty blocks."
//
The NewMsgCreateValidator
constructor is intended to translate a provided Commission
(with Rate
, MaxRate
, and MaxChangeRate
values) into the SDK’s CommissionRates
. However, the code uses commission.Rate
for all three fields, instead of taking commission.MaxRate
and commission.MaxChangeRate
.
msg := &stakingtypes.MsgCreateValidator{
Description: stakingtypes.Description{
Moniker: description.Moniker,
Identity: description.Identity,
Website: description.Website,
SecurityContact: description.SecurityContact,
Details: description.Details,
},
Commission: stakingtypes.CommissionRates{
Rate: math.LegacyNewDecFromBigIntWithPrec(commission.Rate, math.LegacyPrecision),
MaxRate: math.LegacyNewDecFromBigIntWithPrec(commission.Rate, math.LegacyPrecision),
MaxChangeRate: math.LegacyNewDecFromBigIntWithPrec(commission.Rate, math.LegacyPrecision),
},
MinSelfDelegation: math.NewIntFromBigInt(minSelfDelegation),
DelegatorAddress: sdk.AccAddress(validatorAddress.Bytes()).String(),
ValidatorAddress: sdk.ValAddress(validatorAddress.Bytes()).String(),
Pubkey: pubkey,
Value: sdk.Coin{Denom: denom, Amount: math.NewIntFromBigInt(value)},
}
return msg, validatorAddress, nil
}
type CommissionRates struct {
// rate is the commission rate charged to delegators, as a fraction.
Rate cosmossdk_io_math.LegacyDec `protobuf:"bytes,1,opt,name=rate,proto3,customtype=cosmossdk.io/math.LegacyDec" json:"rate"`
// max_rate defines the maximum commission rate which validator can ever charge, as a fraction.
MaxRate cosmossdk_io_math.LegacyDec `protobuf:"bytes,2,opt,name=max_rate,json=maxRate,proto3,customtype=cosmossdk.io/math.LegacyDec" json:"max_rate"`
// max_change_rate defines the maximum daily increase of the validator commission, as a fraction.
MaxChangeRate cosmossdk_io_math.LegacyDec `protobuf:"bytes,3,opt,name=max_change_rate,json=maxChangeRate,proto3,customtype=cosmossdk.io/math.LegacyDec" json:"max_change_rate"`
}
As a result, validators cannot set distinct upper bounds on their commission rate, effectively neutralizing the purpose of those configuration parameters.
It is recommended to assign each CommissionRates
field from its corresponding Commission
field.
RISK ACCEPTED: The TAC team accepted the risk with the following comment - "This behavior is inherited from the original Cosmos/EVM implementation. We notified the ICL team, who confirmed it will be fixed in a future release; in practice, this has no effect on our chain, as our validators do not use this precompile path to create validators."
//
The NewWebsocketsServer
function, implemented in websockets.go file, is intended to initialize a WebSocket server that listens on the exact host and port defined in the user’s JSONRPC configuration.
func NewWebsocketsServer(clientCtx client.Context, logger log.Logger, tmWSClient *rpcclient.WSClient, cfg *config.Config) WebsocketsServer {
logger = logger.With("api", "websocket-server")
_, port, _ := net.SplitHostPort(cfg.JSONRPC.Address) // #nosec G703
return &websocketsServer{
rpcAddr: "localhost:" + port, // FIXME: this shouldn't be hardcoded to localhost
wsAddr: cfg.JSONRPC.WsAddress,
certFile: cfg.TLS.CertificatePath,
keyFile: cfg.TLS.KeyPath,
api: newPubSubAPI(clientCtx, logger, tmWSClient),
logger: logger,
}
}
However, it discards the configured host, extracts only the port from cfg.JSONRPC.Address
, and prepends localhost:
, forcing the server to bind only to the loopback interface. This behavior prevents the server from being reachable on any other network interface, breaking any external connectivities.
It is recommended to assign rpcAddr
directly from cfg.JSONRPC.Address
so the server binds to the configured host and port.
RISK ACCEPTED: The TAC team accepted the risk with the following comment - "This is part of the original Cosmos/EVM logic, which we have not changed. We consulted the ICL team, who confirmed it will not impact our deployment and will be corrected upstream; we have not encountered accessibility issues with JSON-RPC nodes."
//
The project utilizes dependencies with known vulnerabilities, which could expose the application to various attacks. Specifically:
golang.org/x/net@v0.34.0:
CVE-2025-22870 (CVSS 6.9 - Medium): Improper input interpretation in proxy pattern matching for IPv6 zone IDs. This could lead to requests incorrectly bypassing the proxy, potentially exposing internal services or leading to unintended network behavior.
CVE-2025-22872 (CVSS 6.3 - Medium): Incorrect parsing of HTML tags with unquoted attribute values ending in a solidus (/) character. This can lead to misinterpretation of the DOM structure, potentially resulting in unexpected behavior or cross-site scripting (XSS) vulnerabilities if user-controlled data is involved in the malformed tags within foreign content (e.g., <math>, <svg>).
golang.org/x/crypto@v0.32.0:
CVE-2025-22869 (CVSS 6.9 - Medium): Denial of Service (DoS) vulnerability in SSH servers implementing file transfer protocols. Clients that complete the key exchange slowly or not at all can cause the server to read pending content into memory without transmitting it, potentially leading to resource exhaustion.
It is recommended to update these dependencies to patched versions to mitigate these risks.
ACKNOWLEDGED: The TAC team acknowledged the finding.
//
In inflation.go
, both custom inflation formulas (TacParabolicInflationFormula
and TacLinearInflationFormula
) contain division by zero vulnerabilities that can cause complete chain halt when triggered through governance parameter changes.
// Parabolic Formula - Line 19
delta := bondedRatio.Sub(params.GoalBonded).Quo(params.GoalBonded) // Fails if GoalBonded = 0
// Linear Formula - Line 58
ratio := bondedRatio.Sub(params.GoalBonded).Quo(math.LegacyOneDec().Sub(params.GoalBonded)) // Fails if GoalBonded = 1
Impact:
Chain Halt: Network becomes completely unresponsive when inflation calculation fails.
Consensus Failure: All validators crash simultaneously during block processing.
Recovery Complexity: Requires coordinated hard fork with fixed binary to restore operation.
Attack Vector: Malicious governance proposal setting GoalBonded
to 0% or 100%.
Add proper validations:
func TacParabolicInflationFormula(_ context.Context, _ minttypes.Minter, params minttypes.Params, bondedRatio math.LegacyDec) math.LegacyDec {
// Add bounds validation
if params.GoalBonded.IsZero() || params.GoalBonded.LTE(math.LegacyZeroDec()) {
return math.LegacyZeroDec() // Safe fallback
}
// Clamp bondedRatio to valid range [0,1]
if bondedRatio.IsNegative() {
bondedRatio = math.LegacyZeroDec()
}
if bondedRatio.GT(math.LegacyOneDec()) {
bondedRatio = math.LegacyOneDec()
}
delta := bondedRatio.Sub(params.GoalBonded).Quo(params.GoalBonded)
deltaSquared := delta.Mul(delta)
adjustment := math.LegacyOneDec().Sub(deltaSquared)
return params.InflationMax.Mul(adjustment)
}
func TacLinearInflationFormula(_ context.Context, _ minttypes.Minter, params minttypes.Params, bondedRatio math.LegacyDec) math.LegacyDec {
// Add bounds validation
if params.GoalBonded.IsZero() || params.GoalBonded.GTE(math.LegacyOneDec()) {
return params.InflationMin // Safe fallback
}
// Clamp bondedRatio to valid range [0,1]
if bondedRatio.IsNegative() || bondedRatio.GT(math.LegacyOneDec()) {
return params.InflationMin
}
// Existing logic continues safely...
if bondedRatio.LTE(params.GoalBonded) {
ratio := bondedRatio.Quo(params.GoalBonded)
return params.InflationMin.Add(params.InflationMax.Sub(params.InflationMin).Mul(ratio))
}
ratio := bondedRatio.Sub(params.GoalBonded).Quo(math.LegacyOneDec().Sub(params.GoalBonded))
return params.InflationMax.Sub(params.InflationMax.Sub(params.InflationMin).Mul(ratio))
}
ACKNOWLEDGED: The TAC team acknowledged the finding with the following comment - "This scenario is not possible in practice due to Cosmos-SDK validation of goalBonded (always >0) and the natural limits of bondedRatio (always between 0 and 1). Our inflation formula implementation already ensures this logic is safe and efficient, and additional checks would add unnecessary overhead to per-block execution."
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
EVM
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed