Note: not exploitable in WMF's config, see bottom for details why.

Consider a URL like https://en.wikipedia.org/w/api.php?action=query&uselang=en&maxage=6000&smaxage=6000&uselang=en

If you are logged in, the response body will contain your edit token (Inside a blob of JS on the page).

It will also contain the header cache-control: s-maxage=6000, max-age=6000, public even if you are logged in

This is a signal to proxies that this response is safe to cache in a shared cache.

We should not be sending public cache headers for any request with private user data in it.

In theory, the vary: cookie header should stop compliant proxies from doing anything bad, but often people disable varrying on all cookies.

This is not exploitable on WMF as far as i can tell because CDN servers refuse to cache anything where the request has a cookie with session or token in the name. I believe this might be exploitable in other configurations of MediaWiki with different varnish configs. You can get around that using centralauthtoken parameter, however this puts RL into safe mode, and i couldn't find anything useful to do with a cached safemode request where the URL is unguessable (POST of course, also causes it to become uncacheable).

Anyways, i don't think this is exploitable, but definitely not best practise. Anything using a "formatted" output should be marked 'anon-public-user-private' similar to how uselang=user is handled.