In reply to David Anderson.

Hey David,

Thought I'd try to address a few of your concerns.

And as the advisory notes, if the attacker attacks a particular individual, he can “prime the pump” by sending the intended victim enough mails to fill his mail quota, and thus guarantee a bounce-back “over quota” message. i.e. It’s under his control. The WordPress security contact in the article above doesn’t list this in his list of scenarios, even though the advisory does.

I did in fact mention that the E-Mail box could be "compromised or overloaded". The overloading (or over-filling) would be what you're mentioning here. While it's possible, most modern E-Mail services make this incredibly hard to do. Massive floods of E-Mails are generally rejected and don't fill the mailbox. A successful attack here would have to be a very distributed way of sending "valid" E-Mail (or at least that the systems in place think are valid). It also means you have to know the E-Mail address of the user before you attack, and while this probably isn't difficult in most cases (E-Mail addresses aren't generally private), it does mean simple enumeration isn't as viable of a vector.

All servers that are dedicated to a single website, or which have a default, and which will respond with that website regardless of the host header, are vulnerable. That is also a significant number...

I would generally disagree with this, although it obviously very much depends on your definition of "significant number". Talking with a decent number of hosts, it seems highly unlikely that any shared hosts are affected. As for dedicated boxes, they need to be running Apache not nGinx (and more and more large sites are moving to the latter) and not have a virtualhost directive set up for the site, which is definitely best practice for configuring Apache. I'd say that these larger sites on dedicated Apache boxes are also more likely to know how to properly configure things. While this may potentially still be thousands of sites, which may sound like a "significant number", that is only somewhere in the neighborhood of <0.01% of WordPress site (extremely rough estimate).

The choice of “none of them” instead of “neither of them” to describe this reads like over-eagerness to spin, whether or not it was intended (rather than just poor grammar).

It was not an intentional attempt to "spin" things, nor was it poor grammar (although I'm certainly not a grammar expert). While all the servers I checked ran either Apache or nGinx, the number of servers was greater than two (it was actually seven of my own servers that I had checked). I was referring to the servers not the webserver software, which is why I chose "none" over "neither". Sorry if it caused confusion.

Also, when asked by Sarah I chose to speak to my own personal tests instead of those of hosts and others that I spoke with simply because it was personal first hand knowledge and it seemed like those hosts would be better positioned to speak to their own setups if asked. That doesn't mean that those were the only data points that the team used when triaging the issue.

Can the WP security team document any webserver vendor saying this? Is it advice given in anyone’s documentation anywhere, for that matter?

I don't readily have any documentation around this, but I think having our new hosting-community group include this in what they're building is a great idea.

if you are vulnerable to the issue, then you’re at fault because your server is badly configured, and, you shouldn’t be expecting the WP security team to prioritise a fix because of that

As a team we need to prioritize the most severe and far reaching issues to the top of our list. That's not to the exclusion of other issues like this. In a perfect world we'd have enough people and resources to easily handle all issues, no matter their severity, when they are first reported. Unfortunately this isn't the case. Instead, I think we'd be doing a disservice to our users if we didn't take the time to prioritize the way that we do. It's unfortunate that this issue had to be pushed down the list and it's unfortunate that it was made public before it was fixed, but I also think it was accurately prioritized by the security team.