QRFLOW.codes traced its MCP OAuth exposure to a consent screen that trusted registrant-chosen names

The developer wrote that the report's model of the risk, "open registration means open redirects," "conflated two different things" ^[10]. Registration at POST /api/oauth/register accepts any HTTPS redirect from anyone ^[3]. Authorization is where that redirect gets enforced. The server refuses any redirect a client did not register for itself. It checks on the authorize call and again at the token exchange ^[8]. "Registering a client with your own redirect gets you a client that redirects to you. It does not get you anyone else's authorization code," the developer wrote ^[9].

The second control is one line of the published code. `if (client.dynamic && (!codeChallenge || method !== "S256"))` rejects a dynamically registered client that skips PKCE or asks for the plain method ^[11]. "An intercepted authorization code is worthless on its own," the developer wrote ^[12]. Open Dynamic Client Registration is one of the two modes RFC 7591 defines, and the Model Context Protocol relies on it ^[4]. A redirect allowlist cannot sit on top of that. "You cannot allowlist redirect addresses for applications that do not exist yet," the developer wrote ^[7].

The weak point was the consent page. It dropped the registrant's free-text client_name into "Connect {client_name} to your QRFLOW.codes account?", set in the brand color, with the real destination in small print ^[13]. Anyone could have registered "QRFLOW Official Support", aimed the redirect at their own server, and sent people a link to a consent screen on the real domain, behind the real TLS certificate ^[14]. Every component in that flow behaves exactly as specified ^[14]. It is the least comforting sentence in the post. "Open registration means the name field is attacker-controlled. If you render it, you are part of the attack," the developer wrote ^[15].

The post lists three changes, and none of them touches registration ^[16]. In the first, the redirect host decides whether an app is recognized, and the name is only displayed ^[16]. The reasoning is that an attacker has to actually receive the callback at the host, while the name is entirely theirs to choose ^[18]. The set, KNOWN_CLIENT_HOSTS, holds nine entries, including claude.ai, chatgpt.com, cursor.sh and www.canva.com ^[17][1]. I think hardcoding it is the right tradeoff for a list this short. It changes a few times a year, and the developer argued that a control editable at runtime is a bigger target than one that needs a deploy ^[19].

So the fix is an allowlist after all, applied to what the consent screen trusts. Registration stays open. The second change covers everything off the list. The amber banner used to appear only for loopback clients, and an unknown app at a remote address got no warning at all. Now any unrecognized app gets the banner, with the destination host stated inside it ^[20]. Legitimate clients pay for this too. Oasis and Rayrun are two of the four clients the developer says arrived through open registration, and neither has an entry in the published list ^[6][2]. Unless their callbacks land on a listed host, their users now see the same warning an impostor would get.

The evidence is one developer's account of one service. It shows where this server's exposure sat and how it was closed with registration left open. It does not show how other MCP servers render client_name.