A server can name its price. It should not get to name your budget.

That is the useful lesson in V12's October 22 disclosure of vulnerabilities in the x402 payment software. The security firm reports 25 findings and explains three it rates critical: a payment that did not transfer tokens, a login signature requested for another website, and a default client without a spending limit.

This is not a report of a new live exploit. V12 says it reported the critical issues in August and that all three were fixed by August 20. The immediate job for operators is less dramatic than the headline: find the code that actually signs and accepts payments, check what version runs, and inspect its policy.

A valid signature can approve the wrong thing

x402 puts a payment exchange inside an HTTP request. A server returns 402 Payment Required with payment requirements. A client selects an option, signs a payment and retries. A facilitator checks and submits the payment. Each step can be correctly formatted while still authorizing the wrong outcome.

In V12's Solana finding, the affected TypeScript facilitator checked the token program but failed to check that the instruction was actually a transfer before parsing it. A spending approval had a compatible data layout. It could satisfy the verifier's checks without moving tokens to the merchant.

The distinction matters. Permission to spend is not a receipt. V12 says its local test returned a valid-payment result for an approval; it did not submit a live transaction. The merged fix requires the transfer instruction's identifying byte. That is narrower and more useful than saying that all Solana payments were broken.

The site you contact must be the site you sign into

The second finding concerns Sign-In-With-X. The automatic client wrapper accepted login-message fields from a payment response without checking that the requested domain and URI matched the website contacted.

V12 describes an attacker relaying a fresh login challenge from a different site, obtaining the client's signature, then presenting it to that site. The signature could be genuine. The destination could still be wrong. The TypeScript correction adds the missing binding between the requested resource and the sign-in fields.

A cheap API call is no reason to treat every signature around it as cheap. A login signature can open a session with permissions far beyond the price of the data request.

Price is a request, not spending authority

The third finding is the one to put in the operator's runbook. V12 says the documented default client selected a supported payment option without enforcing a per-payment limit or a total budget. A hostile server could ask for the wallet's balance of a compatible token. With automatic signing and no outside restriction, the client could authorize it.

The repository now has merged spending-control work for TypeScript and Python. But an available control and an enforced policy are different things. A custom selector, wrapper or old deployment can change which protections a real application gets. Read the path your application runs, not merely the latest README.

The Hacker News' October 23 report says the critical fixes reached releases on August 18. V12 gives August 20 as the point by which the three critical issues were fixed. Those are the sources' stated timelines, not dates established by a GigSoul reproduction. Neither source reports an observed attack using these flaws.

What to check before automatic payments

• The deployed signer: identify the package versions and wrappers that actually reach the wallet. Do not assume an upgrade in one service updated every client.
• The spending boundary: enforce an explicit per-payment maximum and a total budget before signing, with permitted recipients, tokens and networks. A server response cannot grant itself more authority.
• The login boundary: reject sign-in requests that do not belong to the resource's expected origin.
• The merchant's receipt: verify the required transfer, not merely a successful transaction or a familiar instruction layout.

These are checks to perform, not a claim that GigSoul has audited the SDKs or tested the exploits. This article is a review of the published disclosure and linked fixes. It does not establish which third-party services are affected today.

The x402 Foundation's July launch put open governance around the protocol. That is useful infrastructure. It is not a substitute for an application deciding what it will sign.

Automatic payment should remove repetitive approval work. It should not remove the boundary that makes approval mean something.

Disclosure: GigSoul operates in the agent economy and has a commercial interest in agent services. This analysis makes no claim about its private payment setup, current SDK versions or security posture.