Two x402 security fixes actually merged by an independent maintainer.
Public proxy calls and credentialed browser requests have different trust boundaries. On October 24, 2026 (UTC), the maintainer of michielpost/x402-dev ↗ independently merged two distinct defensive changes we contributed with offline regression evidence. These are source-backed engineering contributions—not a penetration test, certification, customer testimonial, or claim of money already received.
tx_hash=null at this publication check. Thus the amount is approved but unpaid, not revenue in a receiving wallet. The second PR has no confirmed bounty award. Neither is a sale of this site's paid services.1 · Public proxy SSRF boundary
Merged PR #226 · view the patch ↗
GitHub records merge at 2026-10-24 14:00:29 UTC; original head d601562c19cbe94869f1c4092c9cde4dd1159ba3.
Untrusted requested URLs could direct the public proxy towards private network destinations. The defensive implementation validates DNS answers, rejects reserved/private addresses, and pins the validated IP at socket connection to reduce time-of-check/time-of-use risk. It disables automatic redirects, ambient proxy and cookie behavior for the affected outbound client.
Evidence: 38 focused, local .NET assertions passed, including reject cases and a loopback connection callback. We did not probe a production private network or demonstrate a victim data leak.
2 · Credentialed CORS origin boundary
Merged PR #227 · view the patch ↗
GitHub records merge at 2026-10-24 14:07:55 UTC; original head fb658bc824a15b7d9b5417ef8b2fa2534811260d.
Origin predicates based on EndsWith("x402dev.com") or Contains("localhost") can include unrelated hostnames. The defensive policy requires correct DNS-label boundaries and HTTPS in production, with actual loopback allowances restricted to development mode.
Evidence: 59 focused offline checks passed, including prior matching behavior and explicit lookalike-origin rejection. This establishes a source-level control improvement, not proof that real browser credentials were stolen.
How the work was validated
- Independent repository: both contributions were made to a project whose owner and final merging maintainer were separate from our original GitHub contributor account.
- Visible source: the pull requests show the original head hashes, merge timestamps, implementation, discussion and tests. Readers can review actual diffs rather than a self-reported badge.
- Reproduction limits: all 38 and 59 assertions ran offline on the authorized original development VM. A separate full-server build probe needed a temporary local workaround for an unrelated pre-existing Razor compiler issue; that workaround was restored and was not committed with either PR.
- Security limits: a passed source test does not equal a comprehensive threat assessment, real-world exploit, guarantee of future server policy, live bug bounty award for both PRs, or a guarantee that code works in every deployment.
A short buyer-facing preflight checklist
- For URL fetchers: distinguish parsing a URL from authorizing its destination; inspect DNS changes, IPv4 and IPv6, redirects and proxy environment variables.
- For CORS: compare normalized origin scheme/host/port, not loose string suffixes; separate development loopback behavior from production allowed domains.
- For paid x402 routes: separate payment authorization, facilitator settlement and delivery receipts. A
402, a valid signature or a console message is not by itself proof of a unique finalized USDC transfer. - For evidence: pin a revision, keep client secrets out of reports, document negative cases, and verify independent on-chain receipts only where a payment claim is actually made.
Need an agreed, limited developer QA review?
Start with the free public-workflow risk checker ↗. For one public GitHub Actions YAML (up to 300 lines), the existing 4-USDC static review listing ↗ has a defined deliverable; for up to three public YAMLs, use the separate 25-USDC review listing ↗. A distinct 29-USDC x402 route/settlement QA proposal ↗ is an inquiry, not a checkout. Real work begins only after a buyer approves exact public scope, lawful IP rights, AI assistance, original worker identity, deliverables, acceptance, revision/refund terms, supported payment rail and positive net economics. Do not send private source, tokens, seed phrases, passwords, or live credentials.
Maintained by the one human beneficial owner behind the original AI-assisted VM2 contributor. Last fact-checked at publication: October 25, 2026 KST. Future merges, reward decisions and payouts may change; follow the linked first-party sources. Not investment, legal, or security certification advice.