Page MenuHomePhabricator

CVE-2025-53502: HTML injection in FeaturedFeeds output from i18n message
Closed, ResolvedPublicSecurity

Description

Same issue as T386175: CVE-2025-32072: HTML injection in feed output from i18n message and T392276: CVE-2025-6591: HTML injection in API action=feedcontributions output from i18n message, just in FeaturedFeeds.

A number of messages are output into the RSS/Atom feed using ->text() instead of ->escaped(): https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/FeaturedFeeds/+/5d852c526781e70723c35e81bbbad85d2ae92329/includes/FeaturedFeedChannel.php#150

Screenshot 2025-04-17 at 23-33-05 .png (940×1 px, 157 KB)

I was unable to get any XSS on Special:FeedItem, both the title and body content are go through the parser and appear to be properly escaped. Again, I didn't research whether this would be exploitable in any feed reader (presumably feed readers should be defensive against this), but just copying T386175.

Details

Risk Rating
Low
Author Affiliation
Wikimedia Communities
Related Changes in Gerrit:

Event Timeline

Jly subscribed.

Thanks for raising this. I have made a quick patch, could someone give a code review?

diff --git a/includes/FeaturedFeedChannel.php b/includes/FeaturedFeedChannel.php
index 8cedb04..9be9505 100644
--- a/includes/FeaturedFeedChannel.php
+++ b/includes/FeaturedFeedChannel.php
@@ -147,9 +147,9 @@ class FeaturedFeedChannel {
 		if ( $this->title !== false ) {
 			return;
 		}
-		$this->title = $this->msg( $this->options['title'] )->text();
-		$this->shortTitle = $this->msg( $this->options['short-title'] )->text();
-		$this->description = $this->msg( $this->options['description'] )->text();
+		$this->title = $this->msg( $this->options['title'] )->escaped();
+		$this->shortTitle = $this->msg( $this->options['short-title'] )->escaped();
+		$this->description = $this->msg( $this->options['description'] )->escaped();
 		$pageMsg = $this->msg( $this->options['page'] )->params( $this->languageCode );
 		if ( $pageMsg->isDisabled() ) {
 			// fall back manually, messages can be existent but empty
-- 
sbassett subscribed.

Thanks for raising this. I have made a quick patch, could someone give a code review?

CR+1, untested but LGTM. Often times we push these simple text -> escaped patches through gerrit, but since ext:FeaturedFeeds is Wikimedia-deployed, it should likely be security-deployed this Monday (2025-04-28).

Are you sure all of those should be escaped? Peesumably only the fields that are html embedded in xml should be escaped like this, and not the fields that are considered plain text.

Are you sure all of those should be escaped? Peesumably only the fields that are html embedded in xml should be escaped like this, and not the fields that are considered plain text.

Per https://www.mediawiki.org/wiki/Extension:FeaturedFeeds/WMF_deployment#Message_names, the fields in question are all defined by system messages, no? If we're going to care about the case where a bad browser or feed reader is rendering potentially dangerous html in an XML feed, then I think we'd want to escape these. Most of the time escaped() should just be a noop, as every example message I'm seeing (at least on enwiki) is a simple string without any potentially dangerous chars. I guess this could unintentionally escape ', " and &, since in addition to calling transformText() as text() does, escaped() also passes the data through htmlspecialchars() and Sanitizer::escapeCombiningChar(). But that's probably just a trade-off of having additional defenses against potentially malicious messages.

The atom spec does define some fields as escaped html embedded in xml, so its not just about bad feed readers - compliant readers do render some of these fields as html (but not others), although one hopes they would skip dangerous stuff.

I'm wondering if we should just push this patch publicly through gerrit? I feel like the XSS possibilities are fairly low-risk (message values, bad feed client, etc.) and it might benefit from public discussion as to whether or not this is the best approach. Thoughts?

I should say that the patch only does title, shortTitle and description. It does not affect the <entry> ones which accepts type="html". I'm open to pushing this publicly as I think it's a low-risk issue that applies to feed clients vs a vulnerability with our systems itself.

I should say that the patch only does title, shortTitle and description. It does not affect the <entry> ones which accepts type="html". I'm open to pushing this publicly as I think it's a low-risk issue that applies to feed clients vs a vulnerability with our systems itself.

Any objections to pushing this publicly through gerrit as a more low-risk patch? To get some public CR and see if there are any compelling reasons not to do this?

Change #1149742 had a related patch set uploaded (by Jly; author: Jly):

[mediawiki/extensions/FeaturedFeeds@master] SECURITY: Escape i18n message in action FeaturedFeedChannel

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

Change #1149742 merged by jenkins-bot:

[mediawiki/extensions/FeaturedFeeds@master] SECURITY: Escape i18n message in action FeaturedFeedChannel

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

Jly renamed this task from HTML injection in FeaturedFeeds output from i18n message to CVE-2025-53482: HTML injection in FeaturedFeeds output from i18n message.Jun 30 2025, 7:24 PM
Jly renamed this task from CVE-2025-53482: HTML injection in FeaturedFeeds output from i18n message to CVE-2025-53502: HTML injection in FeaturedFeeds output from i18n message.Jun 30 2025, 7:26 PM
Jly claimed this task.
Jly changed the visibility from "Custom Policy" to "Public (No Login Required)".Jul 7 2025, 6:48 PM
Jly changed the edit policy from "Custom Policy" to "All Users".
Jly changed Risk Rating from N/A to Low.