🚨 CRITICAL VULNERABILITY - upgrade immediately to v260215 or a newer patched version

#1

Hi @clavaque, is it true that any s2member sites running code older than the most recent release are vulnerable to their administrator accounts being taken over?

I got this security alert from Wordfence:

https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/s2member/s2member-260127-unauthenticated-privilege-escalation-via-account-takeover

The s2Member plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 260127. This is due to the plugin not properly validating a user’s identity prior to updating their password. This makes it possible for unauthenticated attackers to change arbitrary user’s passwords, including administrators, and leverage that to gain access to their account.

Can you comment on this? The changelog for 260215 has a very long list of fixes, and all I could find that seems to reference this alert is this:

(Framework) Security: Harden the registration password handler.

If everyone needs to update immediately to avoid the possibility of their website being taken over, I think that should be made extremely clear at the very top of the changelog for this release.

I have updated my own site, but I wanted to post here for others who may not be subscribed to get security alerts from a third party.

#2

Hi Bill. It’s not every site, but some could be vulnerable. The best is always to stay up-to-date, and wordpress notifies everyone of available updates.

I put the fix out the very same day I got notice of the vulnerability found, and didn’t make it so obvious to avoid hackers getting a heads-up before more sites could update to it. Normally the security site would have taken longer to publish it and more sites would have updated before it got broadly known, but looks like they put it up as soon as the fix was out.

Most people don’t read the changelog, they just update when available, but someone that’s looking for clues to abuse a plugin could more likely study those, so it felt safer to not make it so clear to bad hats. Do you think I should have been more descriptive and risk it being abused more before more sites updated? I’m open to changing how I publish these, but so far it has seemed safer to make it less descriptive, just encourage updating.

:slight_smile:

1 Like
#3

Hi @clavaque! Thank you for the quick and thoughtful reply.

I can understand that it must be very stressful on your end to deal with a problem like this, and I appreciate very much how you put out the fix so quickly.

My personal opinion is that, yes, it is best to be clear about the nature and severity of the problem. I am pretty sure I have seen plugin changelogs where they even link directly to the CVE.

This is not only to encourage updating ASAP, but also to give enough detailed information that a site owner can test for themselves that they have not already been compromised. It’s not just about updating, it’s about knowing what bad things might already have happened, and what remediation we might need to do.

I am not an expert on best practices for plugin development, so it’s possible that experienced plugin developers would disagree on this. But I think a motivated bad hat is probably quite likely to subscribe to security feeds, to get the most possible information, so I don’t see much of an argument for withholding information from your plugin changelog once it is publicly available elsewhere.

I totally get keeping the information private until a fix is published and the CVE has been released. After that? Not really.

All this said, I agree that probably most people just update right away, or even leave plugins to auto-update. (In my experience, auto-updates lead inevitably to unexpected site breakage, if a site has any real complexity.)

But for those (few?) users who do read the changelog, I think it is better to get the bad news directly from the plugin author, rather than hear the full details from a third-party security service.

But I’m open to hearing what others think here.

Thanks!

2 Likes
#4

Thank you, Bill!

I agree.

I totally get keeping the information private until a fix is published and the CVE has been released. After that? Not really.

Exactly. Unlike previous fixes that came after the vulnerability was public, this fix came before and I didn’t want to be alerting them earlier. The details of the vulnerability would come out eventually, as you saw.

I understand your viewpoint as the site owner, too. I had to consider all viewpoints, because what I put out would be read by you and everyone else, and came up with what I felt was the best compromise at that point.

But for those (few?) users who do read the changelog, I think it is better to get the bad news directly from the plugin author, rather than hear the full details from a third-party security service.

I totally get you. I’m sorry that I didn’t find a better way to handle it. I did what I thought would be best given the situation. I’ll see what I can do to improve it in the future.

I’m also looking forward to other’s opinions and preferences, and will take each one into account.

:slight_smile:

1 Like
#5

If the CVE is public it’s essential to publish exactly which kind of website is vulnerable. I’m now in a bit of a mess with the he new version still incompatible with my custom PayPal checkout, but at least I know I need to act immediately.

So if user can set a password in the pro-form while paying the site is vulnerable? And/or also if payment is done via PayPal button and then user can set password on first registration?

#6

If you can’t update the plugin yet, best is to at least not allow custom passwords, then you’re not vulnerable. Wp Admin > s2Member > General Options > Registration/Profile Fields & Options > Allow custom passwords during registration

We’ve always recommended that for other reasons, like having the user validate the email address because they need the link sent to them, but now it has a security reason until you apply the fix.

:slight_smile:

#7

Luckily the newest version works fine - the older one had some bug that took down my payment website even in legacy mode.

But explaining this kind of information who is affected and who is not is really important in the changelog. Bad hats gonna know what to attack anyhow - but users of the plugin need to know if they are affected or not.

There is a very easy reason why I want to allow users to setup a password - often users mistype their email address and s2 doesn’t allow for repeat email address field with a check - so if they set up a username and password but wrong email they can login to correct their email even if mistyped. Saves me support time. Also emails end up in spam folders or are outrightely blocked - so it really means less trouble if there is no two step process in the registration, that needs clicking on an email verfication link before allowing the registration to continue - and enables users to try several email addresses. Such a way would be best.
And no open registration before payment is really unsuitable to many websites and creates loads of additional work with user problems.

1 Like
#8

Yeah, I see your point, too. And I’m very glad the newest version works well for your setup.

:slight_smile:

#9

EVERYONE PLEASE UPDATE YOUR INSTALLATION WITHOUT WAIT.

I’ve already seen a couple of sites attacked successfully using this in the last two days. It seems like attackers are very happy that they got notified about it so quickly, before more sites could update and benefit from the fix. :expressionless:

2 Likes
#12