x402 Protocol: 25 Vulnerabilities in AI Agent Payments Explained

Security researchers disclosed on 22 October 2026 that they found 25 vulnerabilities in x402, the HTTP payment protocol AI agents use to pay for APIs. Three were critical. The TypeScript fixes shipped in the @x402 npm packages at 2.23.0 on 18 August. Anyone running x402 clients, facilitators or Sign-In-With-X should upgrade every @x402 package together.

The three critical bugs each broke a different promise. A Solana payment check accepted a token approval as if it were a transfer, so a merchant could hand over a paid resource and receive nothing. An agent could be led to sign a wallet login for a website it never visited. And the documented default client had no spending limit, so a hostile server could ask an agent to authorise its whole token balance.

This post covers what the researchers published, a release timeline from the npm registry, affected and fixed versions per package, each bug class in plain language, how to check what you have installed and what to change in your code beyond the version bump. There is no exploit code here. For the same theme from the infrastructure side, autonomous agents running without limits, see our post on the Skynet LLMjacking agent.

What the researchers reported

The research team reviewed the x402 codebase and published a write-up focused on the three critical findings. In their words, each issue "crossed a different trust boundary": what counted as a payment, which website a signature was for, and who decided how much the wallet could spend.

The write-up describes local tests, not attacks on live systems. For the Solana bug, the researchers say their test used the real token encoders and parser and confirmed the verifier returned a valid result for an approval, but did not submit a live transaction. For the login bug, they confirmed the real Sign-In with Ethereum library produced a correctly formatted message for an unrelated domain.

Only the three critical findings are described. The 13 high and 9 medium or low issues are counted but not detailed, so we cannot map them to specific changelog entries.

Timeline

Times are UTC. Package publish times come from the npm registry's time field. Pull request dates come from the GitHub pull request pages.

One timing detail: the spend controls pull request was opened on 11 August, a day before the date the researchers give for their report, and neither the pull request nor the changelog credits the research. It may have been work already in progress or earlier informal contact. It does not change what you should install.

How x402 works, briefly

x402 revives HTTP status 402, Payment Required. Per the project README and the v2 specification:

1. A client, often an AI agent, requests a resource.
2. The resource server answers 402 with a base64 encoded PaymentRequired object in the PAYMENT-REQUIRED header, listing accepted options: scheme, network, token, amount and recipient.
3. The client picks an option, signs a payment payload and retries with it in a PAYMENT-SIGNATURE header.
4. The server asks a facilitator to verify the payload, usually through its /verify endpoint.
5. If valid, the server does the work and settles, often through the facilitator's /settle endpoint, which submits the transaction on chain.

The x402 documentation describes the facilitator as optional but recommended, so resource servers do not have to run blockchain infrastructure. Sign-In-With-X (SIWX) is an extension that lets a client prove it controls a wallet, so a returning agent can authenticate instead of paying again. On Ethereum chains it builds a standard EIP-4361 message.

The README says schemes "must not allow for the facilitator or resource server to move funds, other than in accordance with client intentions." The specification lists budget management for AI agents as "implementation-specific." The three critical bugs are three ways those intentions were not enforced in code.

The three critical findings

We describe each bug at the level a defender needs, without attack steps.

1. An approval was accepted as a payment

Where: the TypeScript Solana facilitator for the exact scheme, v1 and v2, per the researchers. This is facilitator side code in @x402/svm.

What should happen: the client builds a transaction that moves tokens to the merchant with the token program's TransferChecked instruction. The SVM exact scheme specification requires that "exactly one" transfer match the requirements: correct mint, correct destination token account, amount at least the price.

What went wrong: the fast path verifier read a fixed instruction position, confirmed it called an allowed token program, then decoded it as a transfer without first confirming it was one. Solana's documentation describes ApproveChecked as recording a delegate and an allowance on a token account. It grants permission to spend and moves nothing. Per the researchers, the two decode to the same fields, and the delegate landed where the verifier expected the destination. An approval naming the merchant's token account passed every check.

Impact, per the researchers: "a complete payment bypass." A merchant could deliver a paid resource and receive no tokens. The attacker needed a valid token account but no balance, and the facilitator paid the network fee, so repetition could drain both the merchant's resources and the facilitator's fee budget. The settlement code also skipped its post settlement payment check on this path.

The fix: pull request 3132 adds an explicit check that the first byte of the instruction data equals 12, the TransferChecked discriminator, matching what the Python and Go implementations already did. It shipped in @x402/svm 2.23.0.

2. A server could get a login signature for another website

Where: the SIWX client wrapper in the TypeScript SDK (@x402/extensions, used through @x402/core and the HTTP client packages).

What should happen: EIP-4361 says the domain in a Sign-In with Ethereum message "MUST correspond to the origin from where the signing request was made," and that wallets must verify it to prevent phishing. In a browser, the wallet reads that origin from the page. An automated x402 client has no browser, so the SDK has to play the wallet's role.

What went wrong: the automatic wrapper copied domain and uri from the server's 402 response straight into the message it signed, without checking them against the host the client had contacted.

Impact, per the researchers: session takeover. A hostile data server could relay a fresh login challenge from a site that accepts wallet sign in, collect the agent's signature and use it to log in there as the agent's wallet. The target's checks would pass, because the message really named the target and the signature was genuine. The damage is whatever that session allows, unrelated to the price of the original API call.

The fix: pull request 3133. From 2.23.0, createSIWxPayload takes a required third argument, the final URL of the 402 response after redirects, and refuses to sign when the challenge domain or uri origin does not match it. The SIWX specification now says the client "MUST refuse to sign" in that case.

3. The default client setup had no spending limit

Where: the TypeScript x402 client in its documented default configuration.

What went wrong: per the researchers, the default applied no per payment cap and no total budget. It selected the first supported option the server offered, and the server's amount, token, recipient and network flowed into the signing code. The HTTP decoding path also skipped the SDK's own schema validator, though the researchers stress that validation alone would not fix spending, since a well formed request can still ask for too much.

Impact, per the researchers: a hostile API could turn a routine data request into an authorisation for the wallet's full balance of a compatible token. With an automatic signer and no application policy, the client would sign it. The practical limits were the wallet balance and any external signer restrictions.

The fix: pull request 3124 adds client spendControls in 2.23.0. Per the changelog, by default only recognised pegged assets are allowed, with a $1 USD cap per payment. Teams opt into other tokens through allowedAssets, with an optional integer per asset cap in atomic units, or disable controls with spendControls: false. The paywall package disables them because a human approves in its UI; the MCP client forwards the setting.

Other payment bypass fixes from the same weeks

The @x402/core changelog lists more fixes in this period where a protected route could be reached without paying: a wildcard regex missing the dotAll flag (2.21.0), a backslash in a route parameter on Express and Hono (2.22.0), and an encoded path separator such as /api%2Fpremium reaching a literal route (2.27.0, credited to other contributors). The write-up does not say whether any of these are among its 25. The pattern is familiar from web frameworks: when the middleware that decides "is this route paid" parses a path differently from the router, requests fall through the gap. If you use the x402 HTTP middleware, go to the latest release, not the minimum fix for the three criticals.

Technical details

Values come from the research write-up, the x402 changelogs, the pull request pages and the npm registry, as attributed.

Affected and fixed versions, TypeScript

The write-up gives no version ranges. These are inferred from the changelogs: the fix commits landed in 2.23.0, so earlier 2.x releases lack them. Read "affected" as "lacks the fix," not as an advisory statement.

The @x402 packages release in lockstep. A 2.28.0 @x402/core beside a 2.22.0 @x402/svm still lacks the Solana guard.

Other runtimes

The bug classes, conceptually

All three trust a field supplied by the other side. As the researchers put it, these checks "must run before the client signs or the facilitator accepts a payment."

The two Solana instructions

API changes that come with the fixes

• createSIWxPayload(serverExtension, signer, requestUrl): the third argument is new and required. Two argument calls must change.
• x402HTTPClient.handlePaymentRequired now accepts the response URL and passes it to hooks as PaymentRequiredContext.requestUrl.
• spendControls: default allows recognised pegged assets with a $1 USD cap. Payments outside it are dropped unless you opt in through allowedAssets. A non integer per asset cap is a configuration error.
• Renamed constants: DEFAULT_STABLECOINS, USDC_CONFIG and DEFAULT_ASSET_BY_NETWORK became DEFAULT_ASSETS; identifier fields address and asaId became asset.

Identifiers and advisories

We found no CVE and no GitHub security advisory for these findings. The repository lists two older, unrelated advisories that are easy to confuse with this story:

The practical consequence: npm audit will not flag a vulnerable @x402 version for these findings, because there is no advisory record to match.

Who is affected

Detection: step by step

1. Find every @x402 package

# Installed versions, including transitive ones
npm ls --all @x402/core @x402/svm @x402/evm @x402/extensions @x402/fetch @x402/axios @x402/mcp

# Every installed @x402 package and version, via npm's selector query
npm query '[name^="@x402/"]' | jq -r '.[] | "\(.name)@\(.version)"' | sort -u

# Why a package is present
npm explain @x402/core
pnpm why @x402/core
yarn why @x402/core

Across many repositories, read the lockfiles:

for f in $(find . -name package-lock.json -not -path '*/node_modules/*'); do
  echo "== $f"
  jq -r '.packages | to_entries[]
         | select(.key | contains("node_modules/@x402/"))
         | "\(.key)  \(.value.version)"' "$f"
done
grep -rn --include=pnpm-lock.yaml "'@x402/" .

Also list the legacy v1 package names (x402, x402-fetch, x402-axios, x402-express); see Open questions.

2. Compare against the fixed versions

npm view @x402/core version
npm view @x402/svm time --json | jq -r '."2.23.0"'
npm outdated '@x402/core' '@x402/svm' '@x402/extensions'

Below 2.23.0 lacks the three critical fixes; below 2.27.0 lacks the encoded path fix; mixed @x402 versions need fixing even if @x402/core is current. Do not rely on npm audit here.

3. Search for patterns the upgrade does not fix

# SIWX payload creation still using two arguments
grep -rnE "createSIWxPayload\([^,()]+,[^,()]+\)" --include=*.ts --include=*.js src/

# Spend controls switched off
grep -rn "spendControls: *false" --include=*.ts --include=*.js src/

# Custom selectors or policies that may widen what gets signed
grep -rnE "paymentRequirementsSelector|policies *:" --include=*.ts --include=*.js src/

spendControls: false in a paywall where a human approves each payment is intended. The same line in an unattended agent is a finding.

4. Facilitators: reconcile settlements on chain

If you ran a TypeScript Solana facilitator below 2.23.0, compare what it recorded as settled with what arrived in merchant token accounts:

# Show a settlement transaction and its instructions
solana confirm -v <SIGNATURE>

# Show a merchant token account, including any delegate recorded on it
spl-token display <TOKEN_ACCOUNT_ADDRESS>

A "settled" payment whose transaction holds an approval instead of a transfer, or a merchant balance that did not move, is the mark of the first bug. Also review facilitator fee spend for unexplained spikes.

5. Agent wallets and wallet logins

For each agent wallet, list outgoing transfers since deployment and compare amounts and recipients with what the agent was meant to buy. If you run a site that accepts Sign-In with Ethereum, look for sign ins from agent wallets that do not follow the agent's normal pattern, and confirm your server validates the SIWX domain against its configured origin, as the specification requires.

Remediation: step by step

TypeScript and Node.js

1. Upgrade every @x402 package to the same current version.

npm install @x402/core@2.28.0 @x402/svm@2.28.0 @x402/evm@2.28.0 \
  @x402/extensions@2.28.0 @x402/fetch@2.28.0 @x402/mcp@2.28.0
# Add any other @x402 packages you use (@x402/axios, @x402/express, @x402/hono, @x402/next)

# pnpm and yarn: same package list, same version
pnpm add @x402/core@2.28.0 @x402/svm@2.28.0 @x402/evm@2.28.0 @x402/extensions@2.28.0
yarn add @x402/core@2.28.0 @x402/svm@2.28.0 @x402/evm@2.28.0 @x402/extensions@2.28.0

2. Pin transitive copies with overrides (npm), pnpm.overrides or resolutions (yarn), then rerun npm ls.
3. Fix SIWX call sites. Pass the final URL of the 402 response, after redirects, as the third argument to createSIWxPayload.
4. Set explicit spend limits for agents. Keep the default cap unless you need more, and raise it per asset with allowedAssets rather than switching controls off.
5. Add a policy in MCP bridges. The x402 MCP documentation recommends policies on createx402MCPClient, which run after built in spend controls and before the wallet signs. A defensive example:

import { createx402MCPClient } from "@x402/mcp";
import { ExactEvmScheme } from "@x402/evm/exact/client";

const MAX_ATOMIC = 250_000n; // 0.25 of a 6-decimal stablecoin
const ALLOWED_PAY_TO = new Set(["0xYourTrustedMerchant..."]);

const client = createx402MCPClient({
  name: "research-agent",
  version: "1.0.0",
  schemes: [{ network: "eip155:8453", client: new ExactEvmScheme(account) }],
  policies: [
    (_version, reqs) =>
      reqs.filter(
        (r) => BigInt(r.amount ?? "0") <= MAX_ATOMIC && ALLOWED_PAY_TO.has(String(r.payTo))
      ),
  ],
  maxRequestTimeoutSeconds: 120,
});

6. Run your tests. 2.23.0 renamed asset constants, and 2.25.0 made buildPaymentRequirements() throw when no scheme server is registered. Fix the errors rather than pinning back.
7. Rebuild, redeploy and confirm the running version inside the image:

docker run --rm --entrypoint node <your-image> -e "console.log(require('@x402/core/package.json').version)"

Solana facilitator operators

1. Upgrade @x402/svm and @x402/core together and restart every replica.
2. Reconcile pre upgrade settlements, as in detection step 4.
3. Keep fee payer accounts funded only for expected volume, and confirm the fee payer isolation and compute price limits the SVM scheme specification requires.
4. Tell the merchants you serve which version you run and when you upgraded.

Python, Go and agent wallets

1. Upgrade: pip install -U x402 (check with pip show x402); go get github.com/x402-foundation/x402/go/v2@latest (check with go list -m github.com/x402-foundation/x402/go/v2). Configure spend controls explicitly, and confirm from release notes that SIWX client origin binding is in your version.
2. Give each agent its own small working wallet, topped up on a schedule, so a missing cap is bounded by the balance.
3. If an agent ran below 2.23.0 with an automatic signer and SIWX, treat its sessions on sites that accept its wallet login as suspect.

What changed since first reports

• The fixes predate the write-up by two months: npm releases on 18 August, write-up on 22 October. Teams on a monthly upgrade cadence are probably past 2.23.0 but should check pinned and transitive copies.
• No CVE or GitHub advisory had appeared as of 23 October, so advisory based scanners stay quiet.
• The SIWX specification now carries the client origin rule as a MUST, so the fix is part of the protocol, not just one SDK.
• The repository now lives at x402-foundation/x402. Older links and forks may point to its previous home, so read the current changelogs.

Open questions

• Which of the 25 are which? Only three are described.
• Legacy v1 packages. The researchers say the Solana bug affected v1 and v2 exact schemes in the TypeScript facilitators. The fix landed in @x402/svm. Whether the separately published legacy x402 package (latest 1.2.0, April 2026) carries the flaw is not stated.
• Python and Go SIWX client binding. Pull requests are referenced but we could not match them to released versions.
• Hosted facilitators. Their upgrade dates are not public.
• Schema validation on decode. We did not find a changelog entry that clearly addresses the skipped validator.

What would have helped

Each bug is a missing check at a boundary with a well known counterpart in ordinary web and payment security. That makes them good teaching cases for any team building agents that pay.

Practices for teams building agent payments

1. Treat every field in a 402 response as hostile input. Amount, token, network, recipient and SIWX domain come from the server. Validate them against your own configuration before signing.
2. Make the budget part of the agent's identity. Per payment caps, daily totals and allowed tokens, networks and recipients belong in configuration reviewed like any permission. "Implementation-specific," in the specification's words, means it is your job.
3. Bind every signature to an origin you chose. EIP-4361 asks wallets to check origin; an agent SDK is the wallet.
4. Check type before content. Confirm what kind of instruction, message or token you hold before trusting its fields.
5. Reconcile on chain. "Settled" from a facilitator is a claim; compare it to actual token movements on a schedule.
6. Keep lockstep packages in lockstep, with a CI check that fails when @x402 versions differ.
7. Do not wait for an advisory. These fixes never got one. Track release notes for security sensitive SDKs and upgrade on a short cadence.
8. Keep a human in the loop for anything unusual: a payment above the cap, a new recipient, an unexpected sign in.

Where Safeguard fits

Safeguard does not sit in the payment path. It does not verify x402 payments, watch wallets, inspect Solana transactions or decide whether an agent should sign. Those checks belong in the SDK, the facilitator and your application.

Where it helps is the software that carries the bugs:

• Knowing what you run. SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output). The platform shows which projects contain a given component and version, so "which services ship @x402/svm below 2.23.0" is a query, including transitive copies inside images.
• Matching and ranking. Vulnerability matching against vulnerability databases, with reachability analysis. Honest caveat: matching needs a record, and these findings have none, so a version based policy is the control that catches them.
• Stopping regressions. Policies and gates evaluated in the platform at build, CI and release can fail a build on any @x402 package below 2.28.0.
• Fixing with approval. Autonomous remediation opens fix pull requests and ships switched off, with every category set to Manual. The Safeguard CLI's assistant can edit code and run commands with your approval, which matters here because the upgrade changes the createSIWxPayload signature and renames constants. /permissions offers Ask, Accept edits, Plan, Auto (the default) and Strict, and the desktop and phone apps can approve each command remotely.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, issues findings as SGZ advisories before they reach public CVE databases, and covers seven package ecosystems. We make no claim that it found any of these x402 issues or that an SGZ advisory exists for them; an outside research team found and disclosed them.

Gold Open Source shows known CVEs, fixed versions and a recommended safe version for free, and Gold Registry supplies hardened, signed components and images; both are described below. We do not claim Gold holds a hardened @x402 build or had one before the public fix. The habit that matters is general: pull patched, signed components from a curated source and rebuild fast when a fix lands.

Common mistakes

• Upgrading @x402/core alone. The Solana guard is in @x402/svm and the SIWX binding in @x402/extensions.
• Trusting npm audit to tell you. There is no advisory for it to match.
• Turning off spend controls to make tests pass. Opt specific assets in instead; never set spendControls: false in an unattended agent.
• Passing the wrong URL to createSIWxPayload. It must be the final URL of the 402 response, not a hard coded base URL.
• Stopping at the minimum fixed version. 2.27.0 fixed a further route bypass. Go to the latest.
• Forgetting the container. A lockfile change does nothing until the image is rebuilt and redeployed.

FAQ

What is x402?

An open standard for paying for web resources inside an HTTP exchange. A server answers 402 Payment Required with payment options, the client signs a payment and retries, and a facilitator verifies and settles it, often on chain. It targets automated clients and AI agents.

Which versions fix the critical bugs?

For TypeScript, 2.23.0 of @x402/svm, @x402/extensions and @x402/core, published on 18 August 2026. We recommend the latest, 2.28.0 at the time of writing, across every @x402 package.

Is there a CVE or GitHub advisory?

We found neither as of 23 October 2026. The repository's two published advisories are older and unrelated, which is why npm audit will not flag these versions.

Was anyone attacked?

The write-up describes local tests and reports no exploitation, and nobody has publicly reported losses. If you ran an affected Solana facilitator, reconcile settlements on chain to confirm it for yourself.

I only run a client. Do I need to upgrade?

Yes. The Solana bug is facilitator side, but the spending limit and SIWX bugs are client side. An agent with an automatic signer and no policy could authorise its whole balance of a supported token.

Does the spend control default break my integration?

It may. From 2.23.0 the default allows only recognised pegged assets with a $1 cap per payment. Opt other tokens or larger amounts in through allowedAssets with a per asset cap.

Does this affect MCP servers that pay for tools?

If the MCP server pays through @x402/mcp, it uses the same client and defaults. Upgrade it and add policies to createx402MCPClient so payments are filtered before the wallet signs.

Are Python and Go clients affected?

Per the TypeScript fix's pull request, Python and Go already checked the Solana instruction type. Both added client spend controls on 18 August. SIWX client binding pull requests are referenced but we could not match them to releases, so upgrade and check the release notes.

Would Safeguard have stopped this?

No. It shows every project and image carrying an affected @x402 version, lets you gate builds on a minimum version, and helps make the upgrade, including the code changes, with approval at each step.

Fix it without waiting for upstream

In this case upstream moved quickly: the critical fixes were released six days after the report. The gap that remains is between that release and your production builds, and with no advisory to trigger alerts, that gap can stay open for months.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples. None of them shows x402, a payment, a wallet or these findings.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, runs install and tests with your approval, and pushes nothing. For x402 you would run safeguard scan --dir . in the agent's repository and ask the assistant to move every @x402 package to the same version and update the createSIWxPayload call sites, approving each step.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a folder choice, and Approve or Deny on each command and file edit, ending with the upgrade done and tests passing. Here you would pick the facilitator or MCP bridge repository and ask for the @x402 upgrade plus explicit spend policies, approving each edit yourself.

Click through it at your own pace, or open it full screen.

The mobile demo shows a real Android session: work is sent to a computer running the CLI, and each command is approved on the phone with Allow once, Allow for turn or Deny. For a Solana facilitator you would send the upgrade and restart to the build machine and approve the steps from your phone: a human decision before anything with consequences runs, which is exactly what the missing spend limit removed.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and read the CLI documentation. Related reading: CERT-In's advisory on AI agent attack vectors, what AI-found bugs like PHP2Shell and PwnEscape mean for defenders, the incident response playbook for a compromised dependency and October 2026 security incidents and what would have helped.

Quick check

Sources

• Original research write-up: 25 Vulnerabilities in the x402 Protocol (primary)
• x402 repository README
• x402 protocol specification v2
• x402 Sign-In-With-X extension specification
• x402 exact scheme on Solana (SVM) specification
• @x402/core changelog
• @x402/svm changelog
• @x402/extensions changelog
• @x402/fetch changelog
• @x402/mcp changelog
• @x402/evm changelog
• Python x402 changelog
• Go x402 changelog
• Pull request 3124: spend controls
• Pull request 3132: require TransferChecked discriminator in svm exact
• Pull request 3133: bind SIWX client challenge to the request origin
• x402 security advisories
• GHSA-qr2g-p6q7-w82m (March 2026, unrelated)
• GHSA-3j63-5h8p-gf7c (August 2025, unrelated)
• npm registry: @x402/core
• npm registry: @x402/svm
• npm registry: @x402/extensions
• npm registry: @x402/mcp
• npm registry: x402 (legacy v1 package)
• x402 documentation: MCP Server with x402
• x402 documentation: Facilitator
• Solana documentation: Transfer Tokens
• Solana documentation: Approve Delegate
• EIP-4361: Sign-In with Ethereum
• Safeguard: Skynet LLMjacking Agent: How Exposed AI Models Get Hijacked

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.