31 Vulnerabilities in x402 Protocol Expose 99% of Transactions to Theft Risks

Key Takeaways

Researchers identified 31 critical flaws in the x402 payment protocol, threatening nearly all transactions. The findings highlight a structural deficit in open protocols, necessitating a centralized accountability layer to manage trust, settlement costs,

Woofun AI reports that a comprehensive security audit of the x402 payment protocol has uncovered 31 previously unknown vulnerabilities, placing 99% of transactions at immediate risk of asset theft and exploitation. This critical exposure was detailed in a report compiled by AididiaoJP and Foresight News, based on research by @Jun__Yoo and Akiba from CryptoSlate (@akibablade). The core thesis, articulated in Akiba’s article "31 Newly Discovered Vulnerabilities Put 99% of x402 Cryptographic Payments at Risk of Asset Theft and Free Shopping," challenges the inherent security assumptions of decentralized payment infrastructures.

The investigation stems from a peer-reviewed paper titled "When HTTP 402 Meets Blockchain: Risks of the Emerging x402 Payment System," which has been accepted for presentation at USENIX Security 2026. This academic work scrutinizes the architectural decision to delegate payment verification and on-chain settlement to third-party CDP Facilitators, a design that concentrates trust and verification logic onto a shared infrastructure serving multiple independent merchants. The implication is stark: a single vulnerability in a facilitator can cascade across numerous services, undermining the entire ecosystem's integrity.

The scope of the research was rigorous, defining eight specific security rules that facilitators must adhere to in order to maintain system integrity. Violations of these rules were mapped to four distinct categories of attacks: free shopping, asset theft, service denial, and gas fee abuse. To quantify the prevalence of these risks, the researchers evaluated 15 major facilitators operating within the x402 network. The results were alarming, revealing 49 rule violations and the 31 new vulnerabilities mentioned earlier. These flaws are not theoretical; they represent executable vectors that attackers can exploit to drain assets or disrupt services.

The methodology relied on the open nature of the protocol, allowing researchers to derive security rules from publicly available protocol specifications and reference SDKs. By constructing test merchants and utilizing open-source SDKs, the team was able to simulate real-world attack scenarios. This approach demonstrated that while openness does not eliminate vulnerabilities, it provides a critical pathway for externally discovered flaws to be transformed into shared security standards, rather than remaining hidden until exploited at scale.

In response to these findings, significant remediation efforts have been initiated, leveraging the open-source benefits of the x402 ecosystem. The research findings were privately shared with relevant operators, leading to immediate fixes for some issues and ongoing repairs for others. This collaborative response is facilitated by the protocol's governance structure; the x402 protocol was transferred to the Linux Foundation on April 2, and the x402 Foundation officially began operations on July 14 with 40 members. This foundation provides an official forum for discussing findings at both the specification and reference implementation levels, moving beyond the fragmented patching efforts of individual vendors.

Furthermore, the researchers released a public version of x402scope, with sensitive exploitation code removed, to aid in community-wide security auditing. They are currently in discussions with Coinbase and other key ecosystem participants to integrate their rule checks into pre-development and deployment validation processes.

This shift towards standardized security validation marks a pivotal moment for the protocol, aiming to institutionalize security practices rather than relying on ad-hoc fixes.

However, the technical fixes do not address the fundamental trust gap inherent in the x402 architecture. The system is not entirely trustless; the paper defines facilitators as "intermediaries who assume responsibility for trust." Once verification and settlement are delegated to these entities, users must place considerable trust in the facilitator’s ability to verify signatures, balances, nonces, and expiration times accurately. The critical issue is that while trust is concentrated in these intermediaries, the protocol does not require corresponding capital backing, accountability mechanisms, or payment certainty.

This asymmetry creates a significant risk profile. Facilitators operate servers and manage the verification process, but they are not financially liable for the outcomes of their verifications in the same way traditional financial institutions are. This lack of capital backing means that if a facilitator fails or is compromised, there is no reserve fund to cover losses, leaving merchants and users exposed. The protocol’s design assumes that technical correctness equates to security, ignoring the economic incentives and risks associated with holding such power without corresponding responsibility.

This trust gap is exacerbated by specific technical design flaws, particularly the separation of state between verification and settlement. The intended workflow is verify → business logic → settle, a sequence designed to protect consumers and merchants by ensuring that business logic is only executed after verification.

However, the protocol lacks a mechanism to tie verification and settlement together through shared state. If a merchant acts based on the facilitator’s verification result and subsequent settlement fails, the merchant bears all the losses. This is a critical vulnerability because the verification step does not lock up funds or consume nonces; it merely predicts that "settlement is still feasible at this time." Consequently, the balance, nonce, or validity period may change between verification and settlement. If a server performs irreversible operations before settlement, merchants may suffer losses due to double-spending or expired credentials. On Solana (SOL), this risk is further compounded by the potential for attackers to trick a facilitator into paying rent for accounts under their control, adding another layer of financial exposure to the facilitator’s operations.

Woofun AI data shows that a comparison with traditional credit card systems highlights the missing guarantees in the x402 model. Credit card payments also separate authorization from deduction, but the issuing bank reserves part of the cardholder’s credit limit or funds during authorization. This reservation provides merchants with a certain degree of payment certainty, backed by the bank’s capital. Network rules then provide additional protections, including options such as authorization reversal, chargeback, merchant sanctions, and dispute resolution procedures.

These mechanisms ensure that if something goes wrong, there is a clear path for recourse and loss allocation. X402 lacks an issuing bank to lock up funds and guarantee payments. As a result, servers check payment feasibility through verify, execute business logic, and then call settle, but the two ends do not share state. This absence of a central guarantor means that the costs of trust—such as fraud prevention and dispute resolution—are not covered by any entity, leaving them to be borne by the most vulnerable party in the transaction, typically the merchant.

To address these systemic risks, the researchers propose the implementation of a centralized accountability layer on top of the open protocol. This does not mean centralizing the x402 protocol itself, but rather establishing a clear responsible party for each payment route. Multiple operators can still compete under the same open standard, and users can switch facilitators, but the operational responsibilities are centralized to ensure accountability. One possible example is Cloudflare’s Monetization Gateway, which retains x402’s programmable payment format while handling payment strategies, verification, and access control at a single control layer.

Another approach involves using professional facilitators that offer service level agreements, gas limits, re-verification before settlement, and incident response. These models introduce a layer of financial and operational liability that is currently missing. By requiring facilitators to adhere to strict service level agreements and provide re-verification before settlement, the system can mitigate the risks associated with state separation and ensure that gas fees and other costs are managed responsibly. This centralized accountability layer would act as a buffer, absorbing the costs of security incidents and providing a clear path for dispute resolution.

Critiques of this approach often point to alternative standards and reputation systems, such as ERC-8004, as sufficient solutions.

However, reputation systems are merely an additional signal for assessing risk; they neither reserve funds nor provide payment guarantees. Reputation alone cannot fill the accountability gap because it does not create a financial obligation for the facilitator to cover losses. In the event of a security breach or settlement failure, a high reputation score does not compensate the merchant for lost assets. Therefore, while reputation can inform user choices, it cannot replace the need for a structured accountability mechanism that includes capital backing and legal liability.

This perspective requires reevaluating the role and structure of the discovery layer, which could evolve from simply listing available services to becoming a trust and routing layer. This layer would filter which resources and facilitators meet established security standards, clearly distinguishing between centralized operators that provide guarantees and those that do not. By integrating these standards into the discovery process, the ecosystem can promote transparency and encourage the adoption of more secure, accountable facilitators.

Strategic integrations by key ecosystem players are already moving in this direction, laying the groundwork for a centralized accountability layer. CDP (@CoinbaseDev)’s integration strategy combines Agentic Wallets, CDP Facilitators, and Bazaar to offer wallet, payment, compliance, and discovery functions within a single technology stack. This consolidation reduces the complexity of managing multiple providers and payment methods, bringing fragmented functions under a single operator. Similarly, Orthogonal (@orthogonal_sh)’s integration strategy unifies service discovery, API key management, response standardization, and billing under one account, one balance, and one invoice.

It supports credits, x402, and MPP, further centralizing the operational aspects of payment processing. While these strategies currently do not offer payment guarantees or loss absorption, they create the necessary infrastructure for a centralized accountability layer to emerge. By aggregating wallet, verification, billing, and discovery functions, these operators are positioned to assume the role of the issuing bank, providing the capital backing and risk management capabilities that are currently missing from the x402 ecosystem.

If centralized accountability layers become common, the payment structure itself may undergo a fundamental transformation. One possible model is to replace the current verify → business logic → settle workflow with verify → settle → business logic. The current order protects consumers assuming settlement is irreversible, but once operators accept responsibility for refunds and dispute resolution, this assumption changes. Settlement can be confirmed first to eliminate merchants’ risk of unpaid transactions.

If execution fails later, operators can refund consumers, bearing the liquidity needs and settlement obligations before final settlement. This model makes the operator’s capital and accountability structures more important, as they must have the resources to cover potential refunds and disputes. X402 will continue to serve as an open interface for communicating payment terms and authorization data, but operators will aggregate actual fund flows and complete final settlement on-chain.

Individual payment records will remain in the operator’s internal ledger, while the blockchain records the aggregated final settlement. Since the internal ledger is reversible, this structure reduces the issue of irreversible payments, allowing operators to handle refunds and disputes like issuing banks. The blockchain will effectively become a shared settlement ledger recording the final balances between operators, while individual payments remain off-chain.

This hybrid approach leverages the low settlement costs and programmable nature of blockchain while providing the security and accountability required for mainstream adoption.

Vote

Does x402 need a centralized accountability layer?

0 people voted

Comments

Me
Replying to @User
0/800

No comments yet.

Notifications

Sign in to view messages
View all messagesManage subscriptions