Updated.

Yes, I can use this link to make victim redirect to my website Via Trusted Wikimedia Domain

https://embed.wikimedia.gr4vy.app/start-method.html?authUrl=https://api.wikimedia.gr4vy.app/three-d-secure-auth?&redirectUrl=https://evil.com

Yes, I can use this link to make victim redirect to my website Via Trusted Wikimedia Domain

That link does not call any Trusted Wikimedia Domain. That link does not call donate.wikimedia.org at all.

Please explicitly tell us which domain controlled by Wikimedia you are talking about, and clear steps to reproduce some problem with a Wikimedia domain. Thank you!

In T395195#10855236, @Aklapper wrote:

Yes, I can use this link to make victim redirect to my website Via Trusted Wikimedia Domain

That link does not call any Trusted Wikimedia Domain. That link does not call donate.wikimedia.org at all.

I can't really tell from all of the obfuscated js they load in their test url, but I believe their example is creating an html post (with an evil redirect value as they show in F60509722) and submitting it to the di_donate_gravy action for https://payments.wikimedia.org/api.php. This isn't exactly an open redirect in the traditional sense which begs the question of how this would actually be exploited in the wild. If an attacker is going to socially engineer some url for a victim to click, as is necessary in this example, why not just do the bad stuff with that url? The reputational exploit of an open redirect isn't present here, since the victim would never even see or know they were passed through payments.wikimedia.org, unless they themselves were proxying or monitoring their web requests (quite dubious). What other threats might exist? The victim is never prompted for their own payment information, so forcing some unauthorized transaction seems unlikely or impossible. And again, if the attacker had a victim's payment information, why not just use it? I'll add Wikimedia-Fundraising to get their opinion on this, but I'm really not sure it's even worth the effort to build an allow-list for the various redirects payments.wikimedia.org might use.

I just expected to exploit this in phishing attacks as i saw Wikimedia name in that URL , i made these steps to explain how to get that link but anyway if you see that its not a vuln no problem you can close the report i just wanted to help.

Agreed with sbasset, it looks like this is not an issue on donate nor on paymentswiki, but might be something the payment processor (gr4vy) should mitigate. I'll pass this along to them!

Thanks @Ejegg and @sbassett!

In T395195#10865547, @Speedios999 wrote:

I just expected to exploit this in phishing attacks as i saw Wikimedia name in that URL , i made these steps to explain how to get that link but anyway if you see that its not a vuln no problem you can close the report i just wanted to help.

That's fine. I'd agree that this isn't an amazing thing for the payment processor (gr4vy) to allow, but given our threat model and the way this would need to be exploited, I wouldn't rate it more than a very low risk. And we'd certainly always encourage folks to report anything they think might be a security issue within Wikimedia code.

Maybe this is neither here nor there, but its kind of shocking to me that wikimedia uses a payment processor with a 1337-speek name.

I must admit, when i originally read this report, i thought gr4vy.app was the reporter's website, since i assumed no legitament company (or at least not one in the financial space) would use a name like that.

Yes, Payment gateway security is very weak no encryption no limit at least a google captcha it’s vulnerable for credit cards checking so attacker can know the live credit cards from a list of credit cards (of course I don’t mean random credit cards, I mean like dump,leaked data,bin generating, ….)

In T395195#10866455, @Bawolff wrote:

I must admit, when i originally read this report, i thought gr4vy.app was the reporter's website, since i assumed no legitament company (or at least not one in the financial space) would use a name like that.

Oh yeah, oof, that's not great. I thought it was some kind of test site. I still believe that the reputational portion of a traditional open redirect isn't really present here. But as @Ejegg noticed, we should at least report this to gr4vy as something they could certainly tighten up.

Do I have a chance to earn a spot in the Hall of Fame, or is it out of reach this time?

In T395195#10867777, @sbassett wrote:

But as @Ejegg noticed, we should at least report this to gr4vy as something they could certainly tighten up.

We're setting up a call with them shortly. We already made them aware of the issue and they are investigating their solution options.

And no comment on the name spelling ;)

In T395195#10867855, @Speedios999 wrote:

Do I have a chance to earn a spot in the Hall of Fame, or is it out of reach this time?

Possibly, though I'd prefer to wait on a response from gr4vy before completing resolving this issue. Thanks.

In T395195#10868460, @sbassett wrote:

In T395195#10867855, @Speedios999 wrote:

Do I have a chance to earn a spot in the Hall of Fame, or is it out of reach this time?

Possibly, though I'd prefer to wait on a response from gr4vy before completing resolving this issue. Thanks.

Any news?, the bug is fixed

In T395195#10875543, @Speedios999 wrote:

Any news?, the bug is fixed

Ok, sorry for my first response, I misread your comment. I'd like fr-tech (@Ejegg) to respond with any update they received from the vendor (or at least a summary or acknowledgement) and then we can resolve this task.

Ok, I've confirmed with @Ejegg that the vendor was extremely responsive and did end up hardening their code last Friday (2025-05-29). They have also promised to expand their security and pen-testing efforts to better catch issues like this in the future. I'm going to make this task public now and will work to add @Speedios999 to the Wikimedia security hall of fame.

sbassett opened https://gitlab.wikimedia.org/repos/sre/miscweb/security-landing-page/-/merge_requests/15

Add Speedios999 to Wikimedia security hall of fame

sbassett merged https://gitlab.wikimedia.org/repos/sre/miscweb/security-landing-page/-/merge_requests/15

Add Speedios999 to Wikimedia security hall of fame

Change #1153360 had a related patch set uploaded (by SBassett; author: SBassett):

[operations/deployment-charts@master] Add Speedios999 to security.wikimedia.org hall of fame

https://gerrit.wikimedia.org/r/1153360

Change #1153360 merged by jenkins-bot:

[operations/deployment-charts@master] Add Speedios999 to security.wikimedia.org hall of fame

https://gerrit.wikimedia.org/r/1153360