If you received an email from me pointing you to this page, it is because your website appears to be running a version of Blog Floating Button (the WordPress plugin by sunhaengsa / kuma-chan, which lives in your files at /wp-content/plugins/blog-floating-button/) that falls within the affected range of a known security issue. This page explains what the issue is, how to check which version you have, how to update, and what to do afterwards.

The issue is CVE-2026-15383, an unauthenticated stored cross-site scripting flaw in the plugin’s click-tracking and reporting feature. It affects every release before 1.4.21 and is fixed in 1.4.21, published on 31 July 2026. If you are running anything older than 1.4.21, update Blog Floating Button to 1.4.21 or later.

One thing to be clear about, because it differs from some of the other notices I have sent: there is no older version that is safe. This is not a flaw that was introduced at some point in the plugin’s history and then fixed. The missing protection was present in every release the plugin has ever published, right through to 1.4.20, so “my install is too old to be affected” is not a way out here. The only versions that are not affected are 1.4.21 and newer.

This notice also does not depend on how your site is configured. There is no setting that has to be switched on for the affected code to be present.

This is a plugin flaw, not a WordPress core flaw. A fully up-to-date WordPress does not protect you if the Blog Floating Button 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. I specifically did not send anything to the plugin’s tracking feature, 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

Blog Floating Button adds a floating button to your posts and pages, and it keeps its own record of clicks and visits so you can review them later in an access analytics report inside the WordPress admin area. Both halves of that feature are involved here.

In affected versions, the plugin accepts tracking data from anyone, with no login required, and stores part of what the visiting browser reported about itself in its own database table exactly as received, without cleaning it up. Later, when the report screen displays those stored rows, it writes them into the page as-is. The consequence is that text stored by an anonymous visitor can be treated as code when the report is displayed.

Where that code runs is the part worth being precise about, and it is not what the wording of the public advisory suggests. The report screen is in the WordPress admin area. So the code would run in the browser of a logged-in administrator who opens the plugin’s access report, not in the browsers of your ordinary site visitors. If you were worried that people browsing your site are being attacked through this: they are not, and I would rather say so plainly than leave you with a scarier impression than the facts support.

That also sets the scale of it. This is a real unauthenticated stored flaw and it is worth fixing promptly, but it is narrower than the account-takeover and remote-code-execution issues I write about elsewhere. It does not by itself hand anyone an administrator account, and it does not by itself give anyone control of your server. It needs an administrator to open one particular screen before anything happens at all.

A second fix rides the same release. The 1.4.21 changelog also records that it fixed a SQL injection vulnerability in the report screen’s search and filter parameters. No separate advisory or CVE identifier has been published for that one as far as I can tell, so I am not going to attach an identifier to it; I mention it because updating to 1.4.21 addresses it too. The same release additionally fixed an error-reporting problem that could reveal server file paths, and the vendor carried out a plugin-wide review of output escaping and input sanitization. All of which is to say: 1.4.21 is a security release, and it is worth taking even if the headline issue reads mildly to you.

I am describing this at the level a site owner needs in order to act, and no further. I am not publishing the details that would let someone reproduce it, and I would ask you not to try it against your own site or anyone else’s. Reading your version number, as described below, tells you everything you need to decide what to do.

If my email cited this issue, it means the version your site reports is older than 1.4.21. I did not test whether your particular site is exploitable; all I observed is the version.

Am I affected?

It comes down to one question: which version of Blog Floating Button are you running?

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 Blog Floating Button, the entry whose folder is blog-floating-button, and note the version shown beneath its name.

From the public manifest (no login needed): open yourdomain.com/wp-content/plugins/blog-floating-button/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. For this plugin it agrees exactly with the version shown in the admin area, in every release it has published.

One check that does not work for this plugin, so please do not rely on it. If you are used to reading plugin versions out of the ?ver= number attached to a script or stylesheet in your page source, that will mislead you here. The plugin does not stamp its own version onto those files, so WordPress fills in the WordPress core version instead. A number like 6.8.5 or 7.0.1 next to one of this plugin’s files is your WordPress version, not your plugin version, and comparing it against 1.4.21 is meaningless. Use the admin screen or readme.txt.

Then apply this rule, and note that versions compare numerically, not alphabetically, so 1.4.21 is newer than 1.4.9 even though it looks smaller as text:

  • Anything older than 1.4.21: affected. Update. There is no cut-off below which an older release becomes safe again.
  • 1.4.21 or newer: already fixed.

How to upgrade

The plugin is free, still published, and actively maintained, so the fix is a normal update. 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 a Blog Floating Button update is listed, install it from here.
  3. If you prefer the command line, WP-CLI does the same thing: wp plugin update blog-floating-button.
  4. If no update appears, you can get the latest release directly from the plugin’s page on the WordPress.org directory, Blog Floating Button, and update via Plugins then Add New Plugin then Upload Plugin.
  5. After updating, confirm the new version number (1.4.21 or later) using the steps above, and check that your floating button still appears and behaves normally.

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

After updating

Updating to 1.4.21 or later closes the issue: the report screen now cleans up every value before displaying it, so stored tracking data is shown as text rather than treated as code.

What may already have happened, stated carefully. Anything an anonymous visitor stored before you updated is still sitting in the plugin’s tracking table, but it would only ever have done anything if one of your administrators actually opened the plugin’s access report while the site was on an affected version. If nobody used that screen, nothing had the chance to run. Updating stops it running in future; it does not undo anything that already ran.

If your administrators do use that report regularly, or you simply want to be thorough, these are reasonable and low-cost checks:

  • Review your administrator accounts. In the WordPress admin, go to Users, filter to Administrator, and confirm that every account listed belongs to someone who should have that access, with the email address it should have.
  • Look over recent changes to your site’s users, settings, and content for anything you do not recognise.
  • If anything looks wrong, resetting administrator passwords is a sensible next step, and regenerating WordPress’s secret keys and salts in wp-config.php (new values are one click away at the official secret-key generator) signs all users out once.

I have no visibility into whether anything actually happened on your site, and I did not look. This is a precautionary notice, not an incident report.

What I did and did not do

To be fully transparent about the check behind my email: I only read 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, and I have never opened your plugin’s report screen, which I could not do anyway without an account on your site.

In particular, I never sent anything to the plugin’s tracking feature. Nothing was submitted, stored, tested, or exploited. That matters more here than on most of these pages, because the tracking feature is the exact thing this issue concerns, so “I did not touch it” is the whole difference between a disclosure and an intrusion.

I am also deliberately not publishing the details that would help someone act on this issue. The description above stops at the level a site owner needs, and I do not link any proof-of-concept code.

This is a version-based observation: your site reports a version older than 1.4.21. A site in that range may already be protected by other means, such as a web application firewall or a backported fix. 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