What is the status of the fixes for these?
All Versions Critical Vulnerability
I moved your message back here, so you could find the answer above.
I am unlocking the topic for the time being. Just in case anybody wants to talk about it. I thought I was helping by closing it, but maybe it was a bad idea, sorry.
The report says the user needs to have admin privileges to be able to use that new “vulnerability”. It’s my understanding that if you’re an admin you’re supposed to have full control no matter what. What am I missing here?
Also, this is a feature of the plugin. We can inject php code. Not only use shortcodes.
What changed now, from before?
I have to check this a bit longer - but I think since I applied this change - My stripe subscription cancellations didn’t go through anymore. I did it however on the up to date s2member pro with one version back s2member main version.
I will downgrade to one version back plus fix to check.
New user registrations with Stripe did go through. I had enough cancellations/new users to know this was not by chance but clearly related to changes I have done since mid March!
Can other people check if Stripe cancellations due to failed payment cause EOT? Failed Payment is the ultimate status in Stripe, the long term problem that accounts stay active while payments are tried of course still active. This is after Stripe gives up (I set it to 4 tries within 1 month)
1 Like
I have my own system modified, to be honest.
I neutered all cancellation routines from s2Member on my own install because Stripe would send two or three notifications for each subscription, s2Member thought there were duplicates and cancelled new subscriptions right away, for example.
I also made a few changes so users are demoted o s2member as soon as a payment fails (I could not hack the code to give them a grace period, so I just had to compromise and do that instead).
I also have no cancel buttons that automatically cancel, instead I have a link that sends me an email asking me to cancel, the user puts some data as desired, I quickly cancel manually and double check the user won’t be charged against their will.
I have my Stripe set up to try 8 times for 30 days, I used to have it trying 8 times for 60 days but I notice it’s not common for people who went more than 30 days overdue to fix their payment methods.
I also try all pending invoices manually, from time to time, to see if I can recover them. Even with a tiny user base (hence why I can do things manually), that method of recovery is very effective reducing involuntary churn.
The modifications I showed above I applied on my version. I had shared my modifications with @clavaque so he could look at them and maybe use some of those ideas, but since he seems to be unable to reach us out (I send him my best wishes, wherever he is), we might have to work those things out in another manner.
I am a bit overwhelmed right now with taxes and a couple of personal issues but I believe May will be a calmer month where I will be able to think of, at least, share some pieces of modified code here. That also gives @Clavaque a few more weeks to say something.
I don’t want to abandon the plugin and move on to another, so I will try to see what’s possible (at least minor tweaks).
I think that it’s against our interest to have s2Member cancelling subscriptions via API by mistake and that’s what I experienced before neutering cancellations from s2Member towards payment processors altogether. Plus, having no cancellation button that’s automated means users can’t say they used it and that it “failed” when they, instead, just forgot to cancel timely. I understand that larger sites with lots of users might be unable to keep up with demand.
Well, just to report. The older version from 24.12 with the above patched file works fine and Stripe cancellations work as expected.
So the reason for Stripe messing up just like paypal IPN messing up is in the botched version from February.
Now yesterday a new version came out - I don’t know about it working or not. I just made sure that both Paypal IPN messages with redirection as well as Stripe work well on the patched version from 24.12.
New version: https://s2member.com/changelog/
- (Pro) Enhancement : Improved the new coupon code limit per user which prevents a user from applying a coupon code unlimited times, Instead of single use, it can now be limited to more uses, e.g. 3. It’s been renamed from “User Once” to “User Max”, max number of times a user can use that coupon. This is optional and leaving it blank will give the default “no limit”.
- (Pro) Enhancement : Improved validation of the template attribute in the s2Member-List-Search-Box shortcode.
- (Framework) UI : Temporary admin notice about Easter promo for Pro add-on at 20% off.
Note that it doesn’t say anything about the new vulnerability being patched or not. I haven’t check the source code yet.
1 Like
WordFence recognizes the latest update as being “safe” - both vulnerabilities don’t come up for it. Thanks for the update, but I hope next time we can get some immediate feedback about the status of fixes - I imagine this has caused a bunch of folks to start considering alternative membership plugins/systems - I know I have.
1 Like
There’s even a topic about it, already.
We’re back in the saddle again as of this morning:
2 Likes
I guess the issue wasn’t fixed, after all.
We need to mod it ourselves.
I don’t think @clavaque is visiting the forum at all, otherwise he’d be well aware of it.
That only reinforces the idea it might be unwise to update the plugin to any 2025 version without comparing the code.
I am sorry for not looking into it yet, even though it’s not my responsibility, I want to help but I am still overwhelmed with personal stuff.
Of course, you can apply the information already in the topic to patch your own and you’re welcome to list the affected files and the segments of code to be replaced, if you’d like, numbering the lines, if you feel that can be helpful (I think it’s just the two files mentioned above and the segments are already mentioned too, you can use your text editor to change those files then upload the patched versions to your own server via FTP).
Alternatively, if you can’t or don’t want to use FTP you can use do it using WordPress’ Plugin File Editor (under Plugins Tab inside your admin, but you can only make changes if you first disable s2Member, edit, save, re-enable). I’d rather make changes locally, though, and reupload whatever needs to be updated. Easier to keep track of things this way too and you can use tools like FreeFileSync (Windows) to compare unchanged with changed versions, as it will show the files with different contents, which you can open with NotePad++, which also allows you to compare two files line by line, side by side, also useful to see what’s modified when a plugin is updated, for example.
I hope the information helps somehow.
At least until we figure out what to do next.
I would really like to know how to exploit the bug. Luckily the big 9.8 bug is fixed. Surely the text description of the current one is wrong - it cannot be administrator but must be subscriber or moderator/contributor level.
I guess it’s subscriber or above can execute any php file that is on the server and not prevented by nginx or similar rules. And so thereby with enough knowledge of other plugins or general wordpress php files escape the prison by uploading their own php files to folders from which nginx does not prevent running them.
So like upload a new plugin to plugin folder and then run it.
If it were only for contributor/author ranks or above I would not be worried. But if subscriber is enough (and s2member_level1 and so on in my opinion is just a subscriber with additional rights) it would really be worrysome. Especially if you have a bigger website where surely someone can find an account with leaked username/password data.
I.e. - I had an author level user taken over after his password leaked that posted a lot of spam in some articles - and that automatically even worse got sent out in the newsletter integration before I could fix it. Bad enough but that’s not a takeover of your website.
I don’t want to force everyone to use 2factor authentication - because it causes a lot of support problems. I did after that problem not only enable 2factor on my own account, but all with editor/autor rights.
From some other bugs with similar description and CVSS level - it seems like the attack would try to find out the database password - and then if that is somehow accessible (some plugins may store it so they can do operations on the wordpress database) use it to ultimately take over your site. It’s not very likely to succeed but possible with enough knowledge and effort.
1 Like
s2Member Pro v250424that just came out is not showing a vulnerability in WordFence (but the change notes don’t seem to address the previous issues) - so I guess we’re good right now?
Last time it took a couple of days for the vulnerabilities to show up again. Maybe there’s a delay?
If it’s not mentioned in the changelog there’s a high chance it wasn’t addressed.
The changelog does mention a security hole, logfile viewer had unlimited access, so it maybe really was only about admin level which I don’t understand why it would then still get a 7.2 rating…
But yeah clearly that first 9.8 bug was way more serious and after being published an not unrealistic danger to have your website taken over
From changelog:
- (Framework) Enhancement : Added additional sanitation/validation to the Logs Viewer, although only Administrators have access to it.
1 Like