So apparently, when a global block is disabled on one wiki but remains active on Loginwiki, it could lead to this exact problem.

Reminder: Once this gets fixed, don't forget to re-enable the global flag on filter 328 @metawiki (I just disabled it).

In T402142#11092766, @Joe wrote:

I should also add - if this has happened in the last week, that might be connected to T400119

I’m guessing this is being caused by this edit: https://en.wikipedia.org/wiki/Special:AbuseFilter/history/1371/diff/prev/36589

Malicious usage/misuse of MergeHistory will always be a PITA to clean up, regardless of whether bigdelete was needed in the first place.

This got brought up on the Wikipedia-en-editfilters mailing list.

What if someone adds a blacklisted link via a transcluded template (not necessarily in the template namespace)? AFAIK not even AbuseFilter can catch that without basically SALTing the entire mainspace page after the fact.

Checkusers and oversighters are now required to use 2FA. See: https://meta.wikimedia.org/wiki/Mandatory_two-factor_authentication_for_users_with_some_extended_rights

This does indeed seem to be caused by an autoblock, which can cause exactly the behavior described. Boldly closing, as no further action is needed.

I’ve noticed that Special:AutoBlockList (https://login.wikimedia.org/wiki/Special:AutoblockList) does correctly hide the autoblock, but Special:BlockList and the Blocks API show it with no issue. Possibly MediaWiki-Blocks -related? Tagging for visibility.

In T397595#10937278, @kostajh wrote:

Thanks for filing this. I don't see block ID 9694 in the output of https://login.wikimedia.org/w/api.php?action=query&format=json&list=blocks&formatversion=2&bkshow=temp, are you saying that you see block 9694 in the ouptut when making that query as a logged-out user?

Note that this occurs on every wiki where the suppressed user has an account. Loginwiki is simply the easiest place to find this information.

In T396636#10913069, @matej_suchanek wrote:

How fresh are the rows (days vs. months)?

There are several days in between them, totalling for about 3 weeks.

In T396750#10911879, @kostajh wrote:

@XXBlackburnXx could you please disable https://nl.wikipedia.org/wiki/Speciaal:Filter/114 until we have pushed a fix for this issue? We should be able to do that early next week.

done.

Anything else that needs to be done here? I can no longer reproduce this now that T389028 is complete.

I'd also like to point out that filters using user_age > 0 and user_age == 0 will need to be updated as well. These don't appear to be included in the list given to us.

This is something that T383362: Provide special page to show warning to users clicking on external or non-forwarded interwiki links could fix, though it's seeing some opposition.

Confirming that I can no longer reproduce the issue. Thank you very much!

I think it's worth noting that this specific vandal is using automation tools to carry out the vandalism, which explains why they are being blocked at such a high rate.

Just a note: users with WebAuthn enabled who registered that method on a group1 wiki are unable to authenticate with auth.wikimedia.org (just had this myself using Yubikey on meta.wikimedia.org).

In T387659#10614918, @Dreamy_Jazz wrote:

One thing I'd say is it seems the bot flag appears to work for local blocks, because we have a test for this: https://gerrit.wikimedia.org/g/mediawiki/extensions/GlobalBlocking/+/7eec35cd53e844937fc87a2b2def5d397b8021be/tests/phpunit/Integration/Special/SpecialMassGlobalBlockTest.php#440

So apparently, the mobile app sets user_mobile==false but user_app==true, which is why it didn't match the filter. You'll probably need to account for this discrepancy in the filter.

MediaWiki message delivery has the sboverride right on all WMF wikis, which is how it bypasses the blacklist.

In T380711#10356369, @kostajh wrote:

Do you think it would be easier and safer for AbuseFilter authors if ip_reputation_tunnel_type is populated only when tunnels[].anonymous property is true?

Agreed. Definitely a better and safer approach :).

Just a note, in case this wasn't already known: Filtering on 'VPN' will also include non-anonymizing VPNs (e.g., school or workplace VPNs), which isn't covered by our NOP policy.
So, I would really encourage to introduce the tunnels[].anonymous variable in abusefilter (as ip_reputation_tunnel_anonymous?) alongside this one to filter specifically for anonymizing VPNs.

Querying the blocked account on Special:BlockList does reveal the IP though: https://cs.wikiversity.org/w/index.php?title=Speci%C3%A1ln%C3%AD:Blokovan%C3%AD_u%C5%BEivatel%C3%A9&wpTarget=%7E2024-9642. It's likely the most recent IP used when the SBL hit happened.

Note unprotecting an filter will also make older versions of it visible.

I created a global filter on Meta to test this: https://meta.wikimedia.org/wiki/Special:AbuseFilter/361 it does seem to work, but I noticed one problem: whenever i tried to create an empty page (so no content at all), its keeps bouncing me back and forth to the warning that the page I will create is blank, and then to the captcha over and over again, without saving the edit.