XRPL EVM Details the Security Audit
The XRPL EVM team has disclosed the results of an AI-assisted security audit that contributed to the network’s v11 node release. The review identified 24 accepted findings across validator management, IBC infrastructure, internal module wiring, dependencies and the software supply chain. All were addressed through 22 merged pull requests before the fixes shipped in node v11.0.0.
The findings were classified into five high-severity issues, nine medium-severity issues, seven low-severity issues and three informational findings. The project said every finding went through human triage before a fix was accepted, highlighting the role of engineers in validating AI-generated observations rather than treating automated review as a replacement for security expertise.
The audit builds on XRPL EVM v11, a security-focused upgrade that was released in July. The earlier release increased the staking unbonding period from one day to seven days, disabled the Interchain Accounts host feature and added rate limiting to outbound IBC transfers. It also tightened Proof-of-Authority validator management.
One of the more significant findings involved outbound IBC transfers. Rate limiting was already applied to incoming transfers, but outbound packets could bypass the middleware before reaching the channel keeper. The fix changed the transfer path so outbound transactions pass through the rate-limit layer, creating a more consistent control on value leaving the network.
Another issue concerned the Interchain Accounts host module. It had been configured with a wildcard message allowance that could let a connected chain request arbitrary messages. XRPL EVM disabled the ICA host module through the v11 upgrade, removing functionality that the network said it did not currently need. The change leaves ordinary IBC token transfers available.
Validator management also received additional safeguards. XRPL EVM uses a Proof-of-Authority model in which validator changes are controlled through the PoA module. The audit identified a need to explicitly block the standard Cosmos validator-creation path after genesis and corrected a related check involving unbonding delegations.
Build Pipeline and Node Configuration Get More Attention
Several findings were not directly related to transaction processing but instead involved how the node was configured and assembled. One issue caused the EVM governance precompile to receive a zero-value copy of the governance keeper before it had been initialized. Reordering the keeper construction restored the expected connection between the components.
The audit also targeted configuration defaults that could conceal problems. A malformed EVM chain ID could previously trigger a hardcoded fallback value of 9999, while the keyring configuration could default to a test backend using unencrypted JSON files. The fixes make these conditions surface as configuration errors rather than allowing the node to continue with potentially unsafe assumptions.
The security work extended into GitHub Actions and Docker builds. XRPL EVM tightened workflow permissions, pinned third-party actions to immutable commit SHAs and removed an old SSH key from the build process. The Docker base image was also pinned by SHA-256 digest, reducing the possibility that a mutable image tag could unexpectedly change the software being shipped.
A release workflow that placed user-controlled input directly into a shell command was also hardened. The input was moved into an environment variable so it would be treated as data rather than executable shell content. The project additionally removed outdated Cosmovisor tooling and addressed dependency and testing issues involving IBC-Go, Cosmos SDK components and the Go mock framework.
Related: XRPL 3.4.0 Goes Live With New Lending Protocol and Network Upgrades
The audit produced a broader lesson about blockchain security: vulnerabilities do not always appear as obvious transaction exploits. Configuration mistakes, incorrect module wiring, dependency drift and weaknesses in build infrastructure can also create risks for a network. XRPL EVM’s approach therefore examined the node beyond its core Go code and included the surrounding systems used to compile and release it.
AI played a significant role in expanding the scope of that review, but the project emphasized that the technology was not operating independently. Separate AI reviewers examined different areas using a defined scope and threat model, while engineers reviewed, deduplicated and confirmed the findings before fixes were merged. The team also acknowledged that some AI-generated findings did not apply after closer human inspection.
For XRPL EVM users and developers, the practical impact of the work is largely behind the scenes. The v11 changes do not represent a major user-facing feature release, but they strengthen validator controls, cross-chain transfers, configuration handling and the software supply chain that operators rely on. The earlier v11 release also increased the staking unbonding period from one day to seven days as part of its economic-security changes.
The disclosure gives developers and security researchers a clearer picture of how XRPL EVM approaches recurring node security reviews. Rather than presenting the audit as proof that future vulnerabilities have been eliminated, the process shows an effort to identify weaknesses across multiple layers and address them before they become operational problems. The project says security reviews will continue as the network evolves.
About The Author
