protecting out of abundance of caution, pending an investigation into whether non-admins can actually edit pages transcluded in a cascade-protected page (or whether it's just the wrong message being shown, or something else)

@codenamenoreste, out of interest, have you noticed if the software's behaviour around this has changed recently? Don't worry if not.

In T409743#11359513, @A_smart_kitten wrote:

@codenamenoreste, out of interest, have you noticed if the software's behaviour around this has changed recently? Don't worry if not.

Possibly, I just noted these issues this morning. I thought it was a complex bug, guess not…

When I go to https://en.wikibooks.org/wiki/Main_Page/Recipe?action=protect , I do see the cascading protection there, so the system does know about it.

And when I try to edit this page as a privileged user, I do get the cascading protection warning:

When editing https://en.wikibooks.org/w/index.php?title=Main_Page%2FSisters&action=edit as an anonymous user, I also see the protection warning, yet I am able to edit. Here's an edit I made anonymously: https://en.wikibooks.org/w/index.php?title=Main_Page%2FSisters&diff=4599423&oldid=4597435 . However, that edit is not effective on the Main Page right now, because it's pending review. So I wonder if FlaggedRevs is messing with this somehow, and is allowing edits to cascade-protected pages (either deliberately on the theory that someone has to approve those edits, or accidentally).

I was not able to reproduce this protection failure locally, or at https://en.wikibooks.beta.wmcloud.org/w/index.php?title=Main_Page/Sisters&action=edit , even though the setup is the same: the Main Page is cascade-protected, the subpage is transcluded, and FlaggedRevs is configured the same. The FlaggedRevs getUserPermissionsErrors hook also doesn't contain any code that would override a permission decision from "not allowed" to "allowed", only the other way around. So something else is going on here, and I don't know what that is yet. I'll keep investigating.

It looks like the core behavior of cascading protection is broken, and only cascades the protection for one action. Most pages are protected against two actions (edit and move), and in this case only the move protection is being cascaded, and the edit protection is erroneously not being cascaded. This regression appears to be caused by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1193936 , which splits the protection query into two queries, and makes the incorrect assumption that each page will only have one corresponding row in the page_restrictions table (but most pages have two, one for an edit restriction and one for a move restriction). I'll work on a patch to fix this now.

(FYI)

An additional complication: MediaWiki no longer writes rows with pr_cascade=1 unless pr_type='edit', and hasn't done so since September 2008. However, the page affected by this bug hasn't had its protection settings changed since March 2008, so it still has a legacy protection row with pr_type='move', pr_cascade=1. The number of affected pages is probably pretty small: I looked at a few large wikis and saw only this one on enwikibooks, 30 on enwiki, 0 on dewiki, 0 on commonswiki and 1 on metawiki.

Quick patch to fix the immediate problem:

Once the security patch has become public, we should consider restructuring this code to handle multiple rows correctly, instead of hackily restricting it to edit only. Here's what that could look like (but we should do this later):

In T409743#11361312, @Catrope wrote:

Quick patch to fix the immediate problem:

0001-SECURITY-Handle-legacy-non-edit-cascading-protection.patch1 KBDownload

CR+2, this makes sense to me and I think it should be safe to deploy.

In T409743#11361300, @Catrope wrote:

An additional complication: MediaWiki no longer writes rows with pr_cascade=1 unless pr_type='edit', and hasn't done so since September 2008. However, the page affected by this bug hasn't had its protection settings changed since March 2008, so it still has a legacy protection row with pr_type='move', pr_cascade=1. The number of affected pages is probably pretty small: I looked at a few large wikis and saw only this one on enwikibooks, 30 on enwiki, 0 on dewiki, 0 on commonswiki and 1 on metawiki.

Thanks for catching this.

IMO the fixes could just go through gerrit once deployed since there is no release branch affected yet (since 1.45 is not released yet).

In T409743#11361366, @Zabe wrote:

IMO the fixes could just go through gerrit once deployed since there is no release branch affected yet (since 1.45 is not released yet).

+1; the timing here feels slightly similar to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1140545 / T385792, in that the security bug was patched relatively close to (but still before) the first release it would otherwise be present within.

It looks like this problem has potentially affected other projects too, see https://en.wikiquote.org/w/index.php?title=Module:Shortcut&action=edit for example.

The patch is now deployed.

In T409743#11361366, @Zabe wrote:

IMO the fixes could just go through gerrit once deployed since there is no release branch affected yet (since 1.45 is not released yet).

I will submit to Gerrit and backport to REL1_45 tomorrow, because it's getting late.

In T409743#11361612, @codenamenoreste wrote:

It looks like this problem has potentially affected other projects too, see https://en.wikiquote.org/w/index.php?title=Module:Shortcut&action=edit for example.

Yes, that's right. I didn't check all ~1000 wikis, only a couple of the biggest ones to get an idea of the extent of the problem. There were two affected pages on enwikiquote, and Wikiquote:Protected_titles (which transcludes Module:Shortcut) was one of them.

Thank you for catching this. Sorry. I should have caught it in review.

fake gerritbot: https://gerrit.wikimedia.org/r/q/Iec8d9490e000fccd7340681617a88e3d0afabdca

Thank you all :)
To confirm, is there anything now preventing this task from being resolved & made public?

Change #1206954 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] RestrictionStore: Handle multiple rows per page correctly

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

Change #1206954 merged by jenkins-bot:

[mediawiki/core@master] RestrictionStore: Handle multiple rows per page correctly

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

^ The sec patch can be removed from prod since it got trough Gerrit.

In T409743#11391179, @Zabe wrote:

^ The sec patch can be removed from prod since it got trough Gerrit.

We will ensure it's removed during this afternoon's security deployment (~ 22:00 UTC) if it isn't removed before then.

The sec patch will and must get removed before 22:00, as it will block proceeding with the train at 19:00 UTC.

In T409743#11392822, @Aklapper wrote:

The sec patch will and must get removed before 22:00, as it will block proceeding with the train at 19:00 UTC.

Fair enough, relevant patches have been removed in Wikimedia production:

$ git show --name-only 070b73dcd8

commit 070b73dcd8 (HEAD -> master)
Author: Scott Bassett <sbassett@wikimedia.org>
Date:   Thu Nov 20 16:10:33 2025 +0000

    Remove publicly-merged patches
    
     * https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1204676
     * https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1206954 (follow-up)
    
    Bug: T409743

1.46.0-wmf.3/core/21-T409743.patch
next/core/21-T409743.patch