Last known occurrence was 2016-02-22. Since then a number of defense mechanisms were added against the assumed causes:, rMW8b413431d760: Guard against allowing intermediate caching when cookies are present, rMWb84fae0173b2: Use header_register_callback to avoid caching responses with Set-Cookie headers
Three reports so far:
- Matiia was recognized as Schexnayder on commonswiki on 2016-01-29
- Matanya as Pas99 on hewiki on 2016-01-30
- FallingGravity as 023yangbo on enwiki on 2016-02-22
Outreach/report collection task is T126069: Collect information about session pollution during the previous SessionManager rollouts.
Hypotheses so far:
- Set-Cookie header gets cached (has happened in past)
- SessionManager emits Set-Cookie in some cases old code did not (when $wgUser is not unstubbed during the request, or when cookies are inconsistent in certain ways)
- varnish nukes everything with a Set-Cookie, but has an exception for Special:HideBanner
- all pages should vary on cookie, and they should set Cache-control: private if the session is persisted (and it must be persisted if Set-Cookie is output for session things). RawAction did not do that (now patched), load.php and similar secondary endpoints still don't (but see T127233). HideBanners disables vary headers, but only sets cache-control:public for anons.
- if Set-Cookie gets cached, shouldn't there be lots of incidents with the same user?
- job runner does multiple importScopedSession calls in same request which somehow leak through
- doesn't seem to be any leak
Other things looked at:
- no obvious pattern in user ids (such as having the same id on different wikis)
- session id generation was guarded with an extra check in case there is some sort of random generator failure, that didn't help
- added logging for same session or user account being used from lots of different IPs simultaneously, didn't find anything interesting