I get the same on mw.org and en.wp

Just checked, this happens on enwiki as well, so it's probably been out there for a while now

Calling the generated POST request directly, the following error appears:
'origin' parameter does not match Origin header

This is probably expected because you won't have the same headers anymore. I get the following console error though:

XMLHttpRequest cannot load https://commons.wikimedia.org/w/api.php?origin=https://www.mediawiki.org. Response for preflight is invalid (redirect)

@Esanders I get those as well

This also breaks changing sitelinks on Wikidata. This causes data inconsistencies between Wikidata and the clients (Wikipedias etc.).

This started around 17:45 UTC today, judging by when the cross-wiki uploads stopped happening: https://commons.wikimedia.org/w/index.php?title=Special:RecentChanges&tagfilter=cross-wiki-upload

Worked around for now:

[19:23] <logmsgbot> !log ori@tin Synchronized php-1.27.0-wmf.20/includes/libs/IEUrlExtension.php: Live-hack IEUrlExtension::haveUndecodedRequestUri() to always return true (duration: 00m 33s)
[19:24] <logmsgbot> !log ori@tin Synchronized php-1.27.0-wmf.21/includes/libs/IEUrlExtension.php: Live-hack IEUrlExtension::haveUndecodedRequestUri() to always return true (duration: 00m 33s)

This was indirectly caused by https://gerrit.wikimedia.org/r/#/c/283230/. That patch resulted in a change to the value of SERVER_SOFTWARE variable, which confused MediaWiki's IEUrlExtension::areServerVarsBad() into using QUERY_STRING rather than REQUEST_URI when checking for file extensions in the URL. Apparently, QUERY_STRING is encoded/decoded incorrectly in WMF production (see T132629), which caused the file extension detection to give a false positive (or possibly the code was broken all along, but that seems unlikely to me).

Change 283341 had a related patch set uploaded (by Ori.livneh):
Force $_SERVER['SERVER_SOFTWARE'] to be "Apache"

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

Change 283341 merged by jenkins-bot:
Force $_SERVER['SERVER_SOFTWARE'] to be "Apache"

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

Whether or not QUERY_STRING is encoded incorrectly, that doesn't look like the cause of your problem here. From P2895,

["QUERY_STRING"]=>
string(41) "oxrigin=https://www.mediawiki.org&*"
["REQUEST_URI"]=>
string(52) "/w/api.php?oxrigin=https://www.mediawiki.org&*"

The encoding in both variables matches.

Before the avoid-IE-stupidity redirect, those would have been

["QUERY_STRING"]=>
string(41) "oxrigin=https://www.mediawiki.org"
["REQUEST_URI"]=>
string(52) "/w/api.php?oxrigin=https://www.mediawiki.org"

In REQUEST_URI, IEUrlExtension::findIE6Extension() will see ".php?" in the middle of the string and return "php" as the extension, which is allowed and so results in no redirect. But in QUERY_STRING it sees only the ".org" at the end so it'll return "org" as the extension, which is not allowed. This is specifically noted as the intended behavior when it can't rely on REQUEST_URI accurately representing a request to "/w/api.php?..."

Hmm, okay, looks like I was mostly wrong then.

I think there's a bug in mw.ForeignApi JS code too, it should avoid producing URLs that trigger the IE extension check. mw.Api actually handles this for GET requests.

And I'd say there's another bug in WebRequest::checkUrlExtension(), there's probably no need to perform the check for OPTIONS requests (like the CORS pre-flight one that started this task). AFAIK it's impossible to navigate to a page with the OPTIONS method, it's only used for CORS AJAX.

Change 283487 had a related patch set uploaded (by Bartosz Dziewoński):
ForeignApi: Percent-encode dots in the 'origin' parameter

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

Change 283487 merged by jenkins-bot:
mw.ForeignApi: Percent-encode dots in the 'origin' parameter

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