Back in March, we announced that Ripple was standing up a dedicated AI-assisted red team to continuously hunt for vulnerabilities in the XRP Ledger. Two months in, we want to give the community a real look under the hood: how the effort is structured, what kinds of bugs we've found, and what we've learned along the way.
The Challenge: Security at Scale
The XRPL has been running continuously since 2012 and has processed over three billion transactions. That track record is something to be proud of, but it also means the codebase carries the weight of a decade of engineering evolution - design decisions made at a different scale, assumptions that predate modern tooling, and legacy patterns that interact in non-obvious ways with newer features.
New features ship regularly, each adding complexity across the core protocol, client SDKs, and the Clio API server. A codebase that has evolved over a decade accumulates subtle interactions between subsystems that no single person can hold entirely in their head.
AI models allow us to go both deeper and broader in larger codebases, at a speed and scale that would otherwise be near-impossible. Teams can thoroughly explore large codebases at a depth and breadth that would be impractical with manual review alone, finding edge cases where subsystems intersect and in sections of the codebase that haven’t been closely scrutinized in years.
Our Multi-Layered Pipeline
The red team combines several complementary techniques, each catching different classes of bugs.
AI bug-finding agents. The core of our approach is custom AI pipelines that analyze the rippled codebase, XRPL client SDKs (xrpl.js, xrpl-py, xrpl4j, xrpl-rust, xrpl-go), and Clio. We run these agents against feature branches, release candidates, and the main codebase on a continuous basis, including scheduled weekly runs against the develop branch to catch bugs introduced by new code.
DepthFirst. We use DepthFirst, an AI-powered vulnerability discovery platform, for deep scans of our repositories. While our custom pipelines are purpose-built around XRPL-specific semantics, DepthFirst brings broader coverage: it traces data flows, business logic, and cross-service interactions across the codebase to find attack paths that span module boundaries. We specifically use their low-level C/C++ model, which is tuned for the memory safety and type-confusion bugs that dominate systems-level code.
Antithesis (fault-injection testing). We use Antithesis, a continuous fault-injection platform, to run rippled under adversarial conditions - exploring behaviors that only emerge under concurrent load, partial failures, or unusual transaction ordering. This catches a different class of bug than static analysis: timing-dependent crashes and assertion failures that only appear when the system is under stress. Antithesis has already caught real bugs that we have shipped fixes for in production releases.
External security research intake. We actively receive and triage reports from external researchers, whether through our bug bounty program or via other channels. These flow through the same triage pipeline as our internal findings.
PR review bots. We run GitHub Copilot and a Ripple-managed Claude-based bot on rippled PRs. Both post inline comments directly on the PRs, catching issues before they can become bugs in the codebase.
From Bug to Fix: The Full Lifecycle
Discovery is only the first step. As Mozilla observed in their similar work hardening Firefox with AI:
"A discovery subsystem is necessary but not sufficient. In order to scale the effort, we needed to integrate it with our full security bug lifecycle: determining what to look for, where to look, and how to handle what it produces."
We've built the same thing for the XRPL. Our lifecycle looks like this:
- Discovery: AI pipelines, DepthFirst scans, Antithesis, and external researchers report candidate bugs.
- Deduplication: Before filing, we cross-check against existing boards to avoid duplicate tickets across our various pipelines.
- AI-assisted triage: An automated triage pass does the first cut: root cause analysis, false positive detection, reproduction test generation, and severity scoring using the OWASP Risk Rating Methodology. This substantially reduces the manual burden on engineers.
- Human expert review: Domain experts validate triage results. AI triage is powerful but imperfect, and human review is essential, particularly for subtle invariant bugs where the AI can misread the intended semantics.
- Escalation and routing: Confirmed bugs are routed to the right engineering team with full triage reports and reproduction tests already attached.
- Fix and release: Fixes are shipped via the amendment system for on-ledger changes, or as direct patches for off-ledger issues.
Coverage spans nearly every major subsystem: the transaction engine, the RPC layer, the peer/overlay protocol, AMM, MPT, Vault, Lending, Permission Delegation, NFTs, and more.
What We've Found So Far
To date, the team has publicly disclosed 287 xrpld issues on GitHub (231 open, 49 closed), with more issues regularly created as triage continues. These issues are mainly code-quality improvements and defense-in-depth enhancements, and none affect system stability, availability, or the safety of funds. The full list is on Github.
What Shipped in 3.1.3
The 3.1.3 release was dedicated entirely to security and bug fixes. No new features, just hardening. It included 20 red-team findings across several categories:
Permissioned Domain + Tickets crash (Critical). A specific combination of a Ticket-based transaction with the PermissionedDomain feature could trigger a keylet collision that would crash the validator. This bug was initially caught by the XRPL Commons team back in March, and an initial fix that fixed the crash but not the root cause (since that required an amendment) was released in 3.1.2. However, during our release testing for 3.1.3 with Antithesis, we caught a second crashing issue with the same root cause. This is exactly the class of issue the red team was built to find, and exactly why we run fault injection against staging before release. The initial PR from 3.1.2 is #6540, and the full fix in 3.1.3 is #7129.
Ledger RPC API v2 crash (High). The Ledger RPC API v2 endpoint had a crash path reachable from any public connection (no authentication required). A malformed request would bring down the node. This is the kind of bug that's easy to miss in code review because the crash condition is a few layers removed from the input handling, yet straightforward to find with systematic adversarial input generation. The fix PR is #7109.
The remaining findings are summarized in the table below:
| Bug | Category | Severity | PR |
|---|---|---|---|
| HTTP Forwarded Header Out-of-Bounds Heap Read | Core / RPC | High | #7126 |
| SHAMap Leaf Node Size Validation Denial of Service | Core | High | #7130 |
| STArray JSON Parsing Lacks Bounds Checking | Core | High | #7112 |
| STIssue Deserialization Crash via noAccount() Issuer | Core | High | #7110 |
| strUnHex Signed Char Out-of-Bounds Array Access | Core | High | #7104 |
| removeEmptyHolding / authorizeMPToken Delete MPToken With Active Escrow (sfLockedAmount > 0) | MPT / Escrow | High | #6635 |
| Stale Read in rippleSendMultiMPT Allows Exceeding MaximumAmount | MPT / Payments | High | #6644 |
| VaultWithdraw Trustline Limit Bypass via Share-Denominated Withdrawal | Vault | Medium | #6645 |
| Zero-Amount ("Clawback All") Fails When Vault Has Outstanding Loans | Vault | Medium | #6646 |
| associateAsset calls skipped for all flag-bearing LoanManage operations | Lending | Medium | #6678 |
| ValidLoanBroker CoverAvailable invariant check is inverted | Lending | Medium | #6678 |
| LoanPay::calculateBaseFee uncapped fee estimation overcharges users | Lending | Medium | #6970 |
| Dry-run transactions can be queued in the real TxQ during fee escalation | Transaction Queue | Medium | #7131 |
removeExpired Silently Ignores deleteSLE Failure |
Core | Low | #6962 |
| ValidLoan invariant emits identical error message for opposite conditions | Lending | Low | #6668 |
| ValidPermissionedDEX invariant does not check for empty AdditionalBooks array on hybrid offers | Permissioned DEX | Low | #6716 |
There were also several assorted smaller fixes included, some of which were found by AI.
Note: this is not an exhaustive list of all bugs fixed in 3.1.3 - only those found by AI red team efforts.
Beyond rippled
The team has also been scanning Clio and several widely-used client libraries (xrpl.js, xrpl-py, xrpl4j, xrpl-go, xrpl-rust). The SDK scan found many issues across multiple language implementations, several of which have already been patched.
We have also publicly disclosed 44 issues in xrpl-py, 48 issues in xrpl.js, and 126 issues in xrpl-rust.
What We've Learned
AI is a force multiplier, but cannot fully replace humans. Our pipelines find real bugs (including Critical and High severity issues), but also produce false positives. Human review of AI verdicts, especially for false positives, is a crucial part of the process. The combination of AI discovery + AI triage + human expert validation is what makes the system work.
A full pipeline beats a great tool. Having a strong bug-finding AI model is necessary but not sufficient. The real value is in how you use it (the prompts and harnesses you use to guide the model to find bugs) and the surrounding infrastructure (issue tracking integration, deduplication, severity standardization, routing to the right teams, and tracking through to the fix).
Cross-feature interactions are the hardest bugs to find. The most significant findings were in the intersections between features that individually worked correctly, rather than in any one single feature. This is where AI-assisted analysis has the clearest advantage: it can explore the full range of possible feature interactions much more exhaustively.
Security transparency requires responsible coordination. Fixing critical bugs while protecting the network and users requires close coordination with validators and ecosystem participants before public disclosure.
What's Next
The 3.1.3 release was the first dedicated security release to come out of this effort. Future planned releases, including 3.2.0, will include more fixes from the backlog of confirmed findings.
We're expanding our analysis to cover cross-feature interactions better, and continuing to run Antithesis fault-injection tests on new release branches. We're also working to run more comprehensive attackathons on new amendments before they're activated on mainnet - the security bar for new amendments is going up.
We also plan on open-sourcing our pipelines as soon as we have fixed all the exploitable bugs.
Responsible Disclosure
If you find a potential vulnerability in the XRP Ledger, please report it through our responsible disclosure process. The red team reviews all incoming reports.
Security at this scale requires the whole ecosystem. We'll continue to keep you posted on what we find.