If you received an email from me pointing you to this page, it is because your website appears to be running a version of SMS Alert (the WordPress plugin listed as “SMS Alert – SMS & OTP for WooCommerce, Order Notifications & Abandoned Cart Recovery”, by Cozy Vision Technologies, which lives in your files at /wp-content/plugins/sms-alert/) that falls within the affected range of a known security issue. This page explains what the issue is, how to work out whether it applies to your site at all, and how to update. This is a WordPress plugin throughout.

Before anything else, the most important fact about this notice: a version in the affected range does not by itself mean your site is exposed. The issue below only comes into play where two conditions are both true, and neither of them is visible from outside your site:

  1. Your site has OTP verification switched on for password resets in the SMS Alert settings, and
  2. the account being targeted has a phone number stored against it.

If you use SMS Alert only for order notifications, abandoned-cart messages, or OTP at checkout or registration, and not for verifying password resets, then this issue very likely does not reach your site even on an affected version. I can read your plugin version from a public file, but I cannot see your settings, so this notice is a precautionary heads-up, not a confirmed finding about your site.

The issue is CVE-2026-11387, an unauthenticated account takeover through the plugin’s password-reset flow (CWE-640, weak password recovery). It affects versions 3.0.0 through 3.9.5 and is fixed in 3.9.6. If you are running an affected version, update SMS Alert to 3.9.6 or later. Releases 3.9.7 and 3.9.8 came later and fix different things; both are fine as far as this issue is concerned, and 3.9.8 is the current release. It carries a CVSS score of 9.8 and proof-of-concept code is public, which is why I am writing even though the configuration question above may well settle it in your favour.

A word on urgency, because this is a conditional notice. If you do not use SMS Alert for password-reset verification, updating is routine plugin maintenance. If you do, please treat the update as a priority: in that configuration the flaw could let a remote visitor with no account set a new password for any user who has a phone number on file, including an administrator, which would hand over control of the site.

This is a plugin flaw, not a WordPress or WooCommerce core flaw. A fully up-to-date WordPress does not protect you if the SMS Alert plugin itself is on an affected version.

Is this message legitimate?

Yes. This is a good-faith, responsible-disclosure notice from an independent security researcher. I am not asking you for money, passwords, or access to your site, and I have not attempted to break into it, submit anything to it, or exploit anything.

All I did was look at publicly visible files that your website serves to every visitor (the same way your homepage is public) and note the version number that the plugin publishes in its public readme.txt file. I specifically did not touch the password-reset flow, and nothing about this check touches your data, your admin area, or any private part of your site (more detail under What I did and did not do below).

If you would like to verify who I am, see the contact details at the bottom of this page and the About page.

Why this matters

SMS Alert sends SMS and WhatsApp notifications for WooCommerce stores, and it can also put a one-time code in front of certain user actions. One of the flows it can protect that way is the “lost your password?” reset: the visitor asks for a reset, the plugin texts a one-time code to the phone number on the account, and the new password is only supposed to be set after that code has been entered correctly.

In affected versions, the step that sets the new password did not check that the one-time code had actually been completed. The reset could therefore be carried through to the end without the code ever being entered, by someone who is not logged in and has no account of their own. Version 3.9.6 adds the missing check, so the password-setting step now refuses to run unless the code challenge was passed first.

Two things shape how much this matters for a given site. First, the entry point is that specific configuration: the plugin only runs its own reset flow where an administrator has enabled OTP verification for password resets, and it only has a code to send for an account that has a phone number stored. A site that never turned that feature on is very likely not exposed at all, even on an affected version. Second, where the configuration is in place, the impact is serious rather than marginal, because nothing limits it to low-privilege accounts: any account with a phone number on file can be targeted, administrators included.

If my email cited this issue, it means the version your site reports falls within the affected range. I did not test whether your particular site is exploitable, and I cannot see how your OTP settings are configured; all I observed is that the site reports an affected version.

Am I affected?

Two questions decide it, in this order.

First: do you use SMS Alert to verify password resets? This is the deciding question, and only you can answer it. Checking your own settings is entirely safe and is the whole point of this page.

  • In the WordPress admin, open the SMS Alert menu and go to its settings, then to the section that controls OTP verification. That section lists the flows you can put a one-time code in front of. Look at whether password reset (sometimes shown as “lost password” or “forgot password”) is among the ones you have enabled.
  • If it is not enabled, this issue very likely does not reach your site, even on an affected version. Updating is still recommended, as ordinary maintenance.
  • If it is enabled, the issue applies to you, and you should update promptly.

Please do not try to reproduce the problem against your own site or anyone else’s, and you do not need to in order to answer the question above: reading your settings tells you what you need to know.

Second: which version are you running? You do not have to take my word for it, but for this plugin one of the obvious ways of checking is misleading, so it is worth reading this part carefully.

From the WordPress admin area (authoritative):

  1. Log in to your WordPress dashboard (usually at yourdomain.com/wp-admin).
  2. Go to Plugins then Installed Plugins.
  3. Find the entry listed as “SMS Alert – SMS & OTP for WooCommerce …“ (its folder is sms-alert) and note the version shown beneath its name. This is the real installed version.

From the public manifest (no login needed): open yourdomain.com/wp-content/plugins/sms-alert/readme.txt in a browser. The Stable tag: line near the top is the version your install reports, and this is the same public file I read.

One thing not to trust: the ?ver= number attached to the plugin’s front-end scripts and stylesheets in your page source. SMS Alert stamps those assets from an internal constant that has, at least once, lagged the actual release: version 3.5.0 shipped with its assets stamped 3.4.9. Reading the version that way can therefore show you a release older than the one you are actually running, which at the boundary would turn a patched 3.9.6 install into an apparent 3.9.5. That is exactly why I did not use it to decide who to contact, and why you should judge your version from the admin screen or the readme.txt line instead.

Then apply this rule, and note that versions compare numerically, not alphabetically, so 3.9.10 would be newer than 3.9.9:

  • 3.0.0 through 3.9.5: potentially affected (subject to the OTP configuration question above), update now.
  • 3.9.6 or newer: already fixed. This includes 3.9.7 and 3.9.8, which are later releases addressing unrelated issues; the current release is 3.9.8.
  • Older than 3.0.0: outside what I am prepared to make a claim about. The oldest release the vendor still publishes is 3.0.0, so I have no way to examine anything below it, and I would rather say nothing than accuse a version I cannot check. In practice this case is hypothetical: the oldest install I have seen anywhere is a 3.4.x release.

How to upgrade

The safest path is to update through WordPress itself, and to back up first:

  1. Back up your site (files and database) before making changes. Most hosting providers offer one-click backups, or use a WordPress backup plugin.
  2. In the WordPress admin, go to Dashboard then Updates, or Plugins then Installed Plugins. If an SMS Alert update is listed, install it from here.
  3. If you prefer the command line, WP-CLI does the same thing: wp plugin update sms-alert (the command uses the folder name, sms-alert).
  4. If no update appears, you can get the latest release directly from the plugin’s page on the WordPress.org directory, SMS Alert, and update via Plugins then Add New Plugin then Upload Plugin.
  5. After updating, confirm the new version number (3.9.6 or later) using the steps above, and check that your order notifications and any OTP flows you use still work normally.

While you are in there, it is worth confirming that WordPress core, WooCommerce, and your other plugins are up to date, since the same principle applies to all of them.

After updating

Updating to 3.9.6 or later closes the issue, and for most sites that is the whole task. This page is a precautionary notice, not an incident report: I have no visibility into whether anything happened on your site, and I did not look.

One follow-up is worth considering, and it is conditional on the same configuration question. If your site had OTP verification for password resets enabled while running an affected version, then it was at least theoretically possible for someone to have set a new password on an account with a phone number on file. Updating closes the hole, but it does not undo access that was already taken, so in that case two routine precautions are sensible:

  • Review your administrator accounts, and any other accounts that matter, for entries you do not recognise or role changes you did not make.
  • Look over recent password changes and recent logins for accounts that have a phone number stored, and reset any password that looks like it changed without the account holder asking for it.

If you find something that concerns you, treating it as you would any other suspected unauthorized access is the right response: rotate administrator passwords, and consider regenerating the secret keys and salts in wp-config.php, which signs out every existing session. If your site never had password-reset OTP enabled, updating alone is enough.

What I did and did not do

To be fully transparent about the check behind my email: I only read two public files that your site already serves to every visitor, specifically the plugin’s public readme.txt file and your homepage. I did not access your WordPress admin area, your database, or any private part of the site. In particular, I did not touch the password-reset flow, I did not submit anything to your site, and I did not test or exploit anything.

I am also deliberately not publishing the details that would help someone act on this issue: the page above describes the flaw at the level a site owner needs and no further, and I do not link the public proof-of-concept code.

This is a version-based observation: your site reports a version in the affected range. Because this issue is configuration-dependent, a site in that range may not be exposed at all (if it does not use OTP verification for password resets), and it may also already be mitigated by other means, such as a web application firewall. This notice is not a statement that your site was exploitable at the time I checked.

I do not have a webmaster / I am stuck

If you are not the person who maintains the site, please forward this page to whoever does (your web developer, agency, or hosting provider). They will recognize the steps above quickly.

If you are maintaining the site yourself and get stuck, I am happy to help point you in the right direction at no cost. Reach out using the contact details below.

Contact

Evan Harris, Security Researcher

I reach out about issues like this purely to help operators secure their sites. If you would prefer not to be contacted again, just let me know and I will honor that.

References

Official advisories and tracking

Vendor / plugin