| Daimona | |
| Nov 19 2025, 8:34 PM |
| F71040666: T410560.patch | |
| Dec 12 2025, 11:20 PM |
| F70594562: T410560.patch | |
| Nov 24 2025, 3:25 PM |
| F70594469: T410560.patch | |
| Nov 24 2025, 3:24 PM |
The UI does not let users see an event's meeting and chat URL unless they are a registered participant (and not blocked etc., see e.g. how it's handled in SpecialEventDetails). However, this information is always exposed to everyone via the GET campaignevents/v0/event_registration/{id} REST endpoint (handled by GetEventRegistrationHandler).
Once the fix has been released publicly, the API documentation should be updated.
For the proper fix, we will need to make a few changes to inject various service dependencies (at least PermissionChecker and ParticipantsStore); or factor out the common logic into a different class, which is tricky because of the multiple scenarios that we need to handle (see conditionals); and then add tests. All in all, I think the changes would be too large for a security fix, especially in case of upcoming merge conflicts etc.
So, I am going to attach a patch here that simply drops these fields from the response. Then, once this is made public, I will implement the proper fix.
Whoops, thanks for the heads-up. It's interesting because I originally pasted the patch in the comment textbox and got automatically attached. Then I realized I had extra whitespace, so amended the patch, edited my previous comment and pasted the new file, and apparently it didn't get attached from there. Oh well.
Patch makes sense. Obviously we need to ensure that this patch only ever lives in Wikimedia production and never lands on a release branch. Would you like the Security-Team to deploy this?
Hey @Daimona - the patch should be live in Wikimedia production now. It actually went out with the last scap backport from the backport window: https://sal.toolforge.org/log/6hwGuJoB8tZ8Ohr0kMrS. I'll track this for the next supplemental security release but with a note that we still need to develop the actual security patch.
I think we're good for now, if you'd like to verify that things are now working as expected within Wikimedia production. And then I guess just let us know when the more permanent patch is ready to go, so we can review it and ensure it gets included within the next supplemental security release. Thanks.
Is there a chance the permanent patch could be worked on publicly? That would reduce the likelihood of merge conflicts and the like I think, but if not, I'll be happy to prepare one.
That should be low risk given the likely low 3rd party usage of ext:CampaignEvents and that we're patched in Wikimedia production. If we could get a nondescript, public patch merged in a week or two, I think that would be fine.
Sorry for the delay. I'm not sure how easy it'd be to make a nondescript patch, given we would essentially be adding visibility checks to code that didn't have them. I could avoid language like "leak" and "security" in the commit message in favour of more generic "consolidate visibility checks" and stuff, but anyone who opens the patch would understand what's going on within 5 seconds. I'm not sure if that's fine? If not I'll make a private patch for this task, I think some of the outstanding changes I previously mentioned have since been merged, so the likelihood of merge conflicts should be much lower now.
Generally, I think this is the best we can do in situations like this. I think we're comfortable with this particular issue being fairly low risk (for a number of reasons) and that risk is further lowered by the fact that we're planning to put out the supplemental security release in early January, where we can "re-announce" this issue.
Just to clarify, by "this" you mean fixing publicly or privately? :) My understanding is that I can proceed with the public fix, but I'd like to confirm that.
Yes, fixing publicly.
My understanding is that I can proceed with the public fix, but I'd like to confirm that.
Yes, you can proceed with the public fix.
Bah, I ended up doing this as a non-public fix. Don't ask me why :D I simply avoided injecting stuff to keep the diff minimal, and disabled a unit test that would otherwise fail. So, this is now ready for review:
(Note that this supersedes the currently-deployed patch from T410560#11400896)
Looks reasonable at a glance.
(Note that this supersedes the currently-deployed patch from T410560#11400896)
Can we just use the above patch when we merge to master and various release branches when the next supplemental release comes out (likely early January of 2026)? And then we'll at least get some limited advantages of public code review and CI.
You mean the two-line patch from T410560#11400896 ? Yes, I think so. I don't think there are 3rd party clients using this anyway.
Ah sorry I'm dense. Yes, as soon as the patch in T410560#11456249 is reviewed, the old one can be undeployed (before deploying the new one, to avoid conflicts) and forgotten forevah, and only the new one will remain in production and make it to the supplemental release and gerrit.
Sure, though given the upcoming winter break for most WMF staff (starting pretty much in a couple of days) I figured we would just leave the current security patch in place in Wikimedia production (unless there are strong concerns re: code volatility, etc.) and then remove it once we publish your new patch and release it with the supplemental security release in early January 2026 (likely the first week or so). Does that sound reasonable?
Yep, sorry everyone for the confusion. The current status here is that the patch needs code review, and I am re-linking it below for convenience:
However, I should also note that, holidays aside, the team is currently a bit understaffed and we aren't treating this as the #1 priority.
Ok. We'd really like to get something into the supplemental security release we're trying to get out by the end of this week. Should we use the current production patch instead? Or the updated patch with maybe a note that it isn't completely tested and isn't fully-supported at this time, or something like that?
Gotcha, I'll see what we can do then. If anything, I think including the production patch is fine.
@Daimona I redid the production patch so that it would apply. If you have time to merge it then I'll go ahead and request a CVE and add it to the supplemental release.
Change #1224848 had a related patch set uploaded (by Mstyles; author: Mstyles):
[mediawiki/extensions/CampaignEvents@master] SECURITY: Rest: temporarily exclude meeting and chat URL from GET event
Merged. I suppose this means I can put the new patch from T410560#11497430 on gerrit once the release is out right?
Change #1224848 merged by jenkins-bot:
[mediawiki/extensions/CampaignEvents@master] SECURITY: Rest: temporarily exclude meeting and chat URL from GET event
Hey @Daimona - we try to align gerrit and manage backports before sending the announcement.
But @Daimona is talking about the follow-up patch here, no? We're already including https://gerrit.wikimedia.org/r/224848 in the supplemental release, no?
Change #1225026 had a related patch set uploaded (by Daimona Eaytoy; author: Daimona Eaytoy):
[mediawiki/extensions/CampaignEvents@master] Rest: Apply permission checks to meeting and chat URL in GET event
Patch 01-T410560.patch is currently failing to apply for the most recent code in the mainline branch of extensions/CampaignEvents. This is blocking MediaWiki release 1.46.0-wmf.11(T413802)
If the patch needs to be rebased
A new version of the patch can be placed at the right location in the deployment server with the following Scap command:
REVISED_PATCH=<path_to_revised_patch> scap update-patch --message-body 'Rebase to solve merge conflicts' /srv/patches/next/extensions/CampaignEvents/01-T410560.patch "$REVISED_PATCH"
If the patch has been made public
The patch can be dropped in the deployment server with the following Scap command:
scap remove-patch --message-body 'Dropping patch already made public' /srv/patches/next/extensions/CampaignEvents/01-T410560.patch
Patch 01-T410560.patch is currently failing to apply for version 1.46.0-wmf.11 of extensions/CampaignEvents. MW train cannot move forward until the patch is fixed (T413802)
Please note you can disregard any existing previous messages in this task from SecurityPatchBot concerning version 1.46.0-wmf.11. To unblock the train, run one of the commands in this message
If the patch needs to be rebased
A new version of the patch can be placed at the right location in the deployment server with the following Scap command:
REVISED_PATCH=<path_to_revised_patch> scap update-patch --message-body 'Rebase to solve merge conflicts' /srv/patches/1.46.0-wmf.11/extensions/CampaignEvents/01-T410560.patch "$REVISED_PATCH"
If the patch has been made public
The patch can be dropped in the deployment server with the following Scap command:
scap remove-patch --message-body 'Dropping patch already made public' /srv/patches/1.46.0-wmf.11/extensions/CampaignEvents/01-T410560.patch
commit f6c9b09ffb2aa8d1817eecc4f5657a1d159ede3a (HEAD -> master)
Author: Alexander Vorwerk <zabe@avorwerk.net>
Date: Tue Jan 13 02:36:32 2026 +0000
Scap remove-patch: removed 1 patch
Dropping patch already made public
Removed patches:
next:
- extensions/CampaignEvents/01-T410560.patchClosing this ticket since the basic patch has been pushed through Gerrit and announced on the supplemental release. Any follow up work for a more long term solution can be tracked with a separate ticket and publicly worked through on Gerrit.