Make WordPress Core

Opened 13 months ago

Closed 9 months ago

Last modified 9 months ago

#58305 closed defect (bug) (wontfix)

Login page title text is filterable but not escaped

Reported by: mahamudur78's profile mahamudur78 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Login and Registration Keywords: has-patch dev-feedback close 2nd-opinion
Focuses: coding-standards Cc:

Description (last modified by sabernhardt)

I have identified an issue with echoing a dynamic value of an HTML element in the /wp-login.php file while reviewing its code. The problem is located on line 209 of the file.

I believe there is a potential security risk associated with this issue, as the dynamic value is being loaded from the apply_filters() function.

To ensure the security and validity of the code, it is crucial to properly escape the dynamic value and prevent any potential security vulnerabilities. Therefore, it is important to address this issue by properly escaping the value on that line.

Change History (9)

This ticket was mentioned in PR #4452 on WordPress/wordpress-develop by @nazmulhudadev.

13 months ago

  • Keywords has-patch added

The variable $login_header_text escaped by esc_html at

I'm no sure that is it should be escaped by esc_html or any other escaping function. So, I'm open for any suggestion to make changes.

Trac ticket:

#2 @sabernhardt
13 months ago

  • Description modified (diff)
  • Milestone changed from Awaiting Review to 6.3
  • Summary changed from This Dynamic Value is From the "apply_filters()" Function not Escaped While Echoing. to Login page title text is filterable but not escaped

@SergeyBiryukov commented on PR #4452:

13 months ago

Hi there, thanks for the PR!

We may find esc_js() or a selective KSES function to be of use here. Curious what others think may be appropriate.

It looks like esc_js() is generally not used outside of JavaScript context, as it escapes text strings specifically for echoing in JS, and is intended to be used for inline JS.

wp_kses() with a list of allowed tags might be more appropriate, but I wonder what would that solve in practice, as if someone has access to add arbitrary code via the login_headertext filter, they can use pretty much any other filter to execute any code, for example login_message directly below. So I'm not sure if escaping is necessary here. Curious to see what others think.

#4 @oglekler
11 months ago

  • Keywords dev-feedback added

#5 @oglekler
11 months ago

  • Milestone changed from 6.3 to 6.4

The login page is often modified to have a styling alongside the rest of the site. Enqueued styles can be removed and by using login_headertext filter any HTML can be added into h1, an image for example. Excepting HTML will break this page branding and can cause problems.

Due to the lack of concrete decision about this issue, I am moving it to the 6.4 milestone.

#6 @rajinsharwar
10 months ago

I do agree with @oglekler, escaping HTML could potentially break the styling. I think escaping won't really help much other than conflicting with themes or plugins that are using the login_headertext filter.

#7 @sabernhardt
10 months ago

  • Keywords close 2nd-opinion added

Then I'll mark this for close consideration.

#8 @rajinsharwar
9 months ago

  • Milestone 6.4 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Let's close this then with the "wontfix" tag. If anyone feels any string reason for reconsidering this, we can again re-open it.

#9 @swissspidy
9 months ago

#59257 was marked as a duplicate.

Note: See TracTickets for help on using tickets.