Make WordPress Core

Opened 6 weeks ago

Last modified 3 weeks ago

#52003 reopened defect (bug)

Undefined index: PHP_AUTH_PW /wp-includes/user.php on line 469

Reported by: MadtownLems Owned by: TimothyBlynJacobs
Milestone: 5.6.1 Priority: normal
Severity: normal Version: 5.6
Component: Application Passwords Keywords: good-first-bug has-patch has-unit-tests fixed-major
Focuses: Cc:

Description (last modified by SergeyBiryukov)

wp_validate_application_password only checks for the existence of $_SERVER['PHP_AUTH_USER'] before calling wp_authenticate_application_password with both $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'].

In our environment (using Shibboleth-powered Single Sign-on), $_SERVER['PHP_AUTH_USER'] is already set, but $_SERVER['PHP_AUTH_PW'] is not defined.

I believe that this section:

// Check that we're trying to authenticate
if ( ! isset( $_SERVER['PHP_AUTH_USER'] ) ) {
	return $input_user;

should likely be extended to confirm the presence of both variables before calling wp_authenticate_application_password.

(Of course, I'm also now worried about what other problems we'll run into using PHP_AUTH_USER the way we are, but that's for another day!)

Attachments (2)

52003.diff (516 bytes) - added by MadtownLems 6 weeks ago.
Patch of user.php that confirms both variables are set before moving forward with application password authentication
52003.patch (610 bytes) - added by engahmeds3ed 6 weeks ago.
Simply use one isset with two arguments

Download all attachments as: .zip

Change History (14)

#1 @SergeyBiryukov
6 weeks ago

  • Description modified (diff)

#2 @TimothyBlynJacobs
6 weeks ago

Thanks for the ticket @MadtownLems!

To clarify, are you manually setting the $_SERVER['PHP_AUTH_USER'] variable in your site?

#3 @MadtownLems
6 weeks ago

To clarify, are you manually setting the PHP_AUTH_USER variable in your site?

I apologize in advance for not being an expert in this area, and I'll do the best to explain.

Our WordPress installation itself isn't specifically doing anything with PHP_AUTH_USER. Rather, our webserver is a Shibboleth Service Provider and interacts with our University's Identity Provider to authenticate users. (Our WordPress installation then takes that data and uses it to associate the person with a WordPress user account.)

I have confirmed that PHP_AUTH_USER gets set whenever I try to visit a protected directory that is not related to WordPress at all.

I have no idea how common Shibboleth is, so here is a link for reference in case it's helpful:


Always happy to answer any more questions, help look into this more, or test things!

#4 @TimothyBlynJacobs
6 weeks ago

  • Milestone changed from Awaiting Review to 5.6.1

Thanks @MadtownLems! I'm not very familiar with shibboleth either. I'm wondering if we may want to run even if PHP_AUTH_PW isn't set, but set it to an empty string.

But in my testing at least, even if a password is omitted when doing Basic Auth PHP_AUTH_PW is still set, but to an empty string. Does anyone know if that is always the case when a password is omitted? If so, then I would agree we can just also check for PHP_AUTH_PW being set.

#5 @TimothyBlynJacobs
6 weeks ago

Chatting with @richard.tape and doing some research it seems expected that shibboleth wouldn't populate PHP_AUTH_PW. I found this semi related issue https://github.com/symfony/symfony/issues/17345 and https://shibboleth.1660669.n2.nabble.com/Populate-PHP-AUTH-PW-var-td6185938.html

So now the question is just if PHP_AUTH_PW would be omitted by valid usages of Basic auth on some server setups.

#6 @johnbillion
6 weeks ago

If this is allowed it ought to be fixed in places where PHP_AUTH_PW is passed through, for example the site health Ajax checks and the plugin and theme editor syntax checks.

#7 @TimothyBlynJacobs
6 weeks ago

  • Keywords good-first-bug needs-patch added

@johnbillion It looks like the rest of Core is already also looking for PHP_AUTH_PW. So I think @MadtownLems your proposed solution makes sense. Do you want to take a go at making a patch for it?

#8 @MadtownLems
6 weeks ago

Gladly. It's been almost a decade since my last actual patch, but I'm not gonna find an easier one to shake the rust off with!

I'll put something together soon.

6 weeks ago

Patch of user.php that confirms both variables are set before moving forward with application password authentication

6 weeks ago

Simply use one isset with two arguments

#9 @hellofromTonya
5 weeks ago

  • Keywords has-patch added; needs-patch removed

This ticket was mentioned in PR #847 on WordPress/wordpress-develop by TimothyBJacobs.

3 weeks ago

  • Keywords has-unit-tests added

#11 @TimothyBlynJacobs
3 weeks ago

  • Owner set to TimothyBlynJacobs
  • Resolution set to fixed
  • Status changed from new to closed

In 49919:

App Passwords: Only attempt auth if the username and password are set.

Previously, only the username was checked which caused a PHP warning in some server setups, for instance Shibboleth SSO, where the server only populates the PHP_AUTH_USER field.

Props MadtownLems, johnbillion, richard.tape, engahmeds3ed.
Fixes #52003.

#12 @TimothyBlynJacobs
3 weeks ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for backport.

Note: See TracTickets for help on using tickets.