If you received an email from me pointing you to this page, it is because your website appears to be running a version of Content Views – Post Grid & Filter (the WordPress plugin by Content Views / PT Guy, which lives in your files at /wp-content/plugins/content-views-query-and-display-post-page/) that falls within the affected range of a known security issue. This page explains what the issue is, how to work out how much it matters for your site, how to read your version without being misled, and how to update.

The issue is CVE-2026-15361, an SQL injection in the plugin’s preview handling. It affects every release before 4.5 and is fixed in 4.5, released on 28 July 2026. If you are running anything older than 4.5, update Content Views to 4.5.1 or later, which is the current release at the time of writing (4 August 2026). There is no CVSS score published for this issue, so I am not going to quote you one, and I am not aware of any public exploit code for it.

There is no older version that is safe. This is not a flaw that was introduced partway through the plugin’s history and later fixed. I checked every published release tag in the plugin’s history, from the earliest one in 2014 through 4.4, and the affected code is in all of them. “My install is too old to be affected” is not a way out here. The only versions that are not affected are 4.5 and newer.

Before anything else, the qualifier that decides how much this matters for your site, because I would rather state it than let the notice sound bigger than it is: this flaw can only be used by someone who is logged in to your site. It does not matter what their account can normally do, and WordPress’s lowest role is enough, but they do need an account. So the question that decides your exposure is not a setting anywhere in the plugin, it is who can get an account on your site. I can read your plugin version from a public file, and I can see whether WordPress serves its standard registration page, but I cannot see who holds accounts on your site, so this notice is a precautionary heads-up rather than a confirmed finding about you.

Note what that qualifier is not. There is no option to switch off, no feature to un-publish, and no configuration that takes you out of range. The affected handler is registered on every install of an affected version, whether or not you have ever placed a post grid on a page. If you go looking for a checkbox to turn off, you will not find one, because there isn’t one. Updating is the fix.

A word on urgency, because this is a conditional notice. If you are the only person with an account on the site and nobody else can obtain one, updating is ordinary plugin maintenance. If your site accepts sign-ups from other people, please treat it as a priority, and note that sign-ups take more forms than the obvious one: a WooCommerce shop, a membership or forum plugin, a multi-author blog, and a custom sign-up page all create accounts without WordPress’s own registration form ever being involved.

If you do have WordPress’s registration page open to visitors and you do not need it, turning it off is a reasonable interim step, because it narrows who can reach this. Please do not read it as a clean bill of health, though. Closing registration only closes one of several doors to an account, and it does nothing about the accounts that already exist. Updating the plugin is what actually removes the issue.

It is also worth being precise about what this issue is and is not. It lets someone with a low-privileged account read data out of your site’s database that their account should not be able to see. That is worth fixing, since a WordPress database holds things like user email addresses and hashed passwords, and on some sites member or customer records. But it is not administrator takeover, it is not a way for someone to hand themselves an administrator account, and it is not remote code execution. It is narrower than the full-compromise issues I write about elsewhere, and I would rather set the scale honestly than leave you with a scarier impression than the facts support.

This is a plugin flaw, not a WordPress core flaw. A fully up-to-date WordPress does not protect you if the Content Views 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, register on it, or exploit anything.

All I did was look at pages and files that your website serves to every visitor (the same way your homepage is public) and note the version number that the plugin publishes. One of the pages I read was your site’s standard WordPress registration page, to see whether it is open to visitors, and reading it is all I did with it. I specifically did not submit that form, did not create an account, did not log in, and did not send anything to the affected feature. 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

Content Views builds post grids, lists and scrollers on your site, so you can display a filtered selection of posts or pages without writing any code. Part of how it does that is a request handler that renders a preview of a grid from the settings it is given.

In affected versions, that handler checks a security token and stops there. It never checks whether the person sending the request is allowed to use it, and the token in question is not a secret: the plugin publishes it to every visitor of the site. The handler then builds a database query out of settings taken straight from the request. The consequence is that somebody holding nothing more than the lowest-privileged account on your site can steer that query and read data out of your database that their account has no business seeing.

The precondition, to repeat it because it is the part most likely to be misread in either direction: an account, not a configuration. Nothing has to be enabled for the handler to be reachable, and there is no setting that takes an affected version out of range. What stands between an affected install and this issue is simply whether somebody other than you can log in. On a site where anyone can sign up, that is not much of a barrier. On a site where you are the only user, it is a real one.

And the flip side, which matters just as much: a site with WordPress’s registration form closed is not thereby safe. Accounts arrive by many routes, and any of them is enough.

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 4.5. I did not test whether your particular site is exploitable, and I cannot see who has accounts on it. All I observed is the version, and whether your registration page is served to visitors.

Am I affected?

It comes down to one question: which version of Content Views are you running?

A quick word on which plugin this is, since the name is shared. This notice concerns the free plugin published on WordPress.org, the one whose folder is content-views-query-and-display-post-page. The same vendor also sells a separate Pro line. If your plugin folder is that one, read on.

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 Content Views – Post Grid & Filter, the entry whose folder is content-views-query-and-display-post-page, and note the version shown beneath its name.

From the public manifest (no login needed): open

yourdomain.com/wp-content/plugins/content-views-query-and-display-post-page/README.txt

in a browser, and read the Stable tag: line near the top. This is one of the two public sources I read.

Mind the capitals in that filename. WordPress plugins conventionally ship a lowercase readme.txt, and that is the URL most people type from habit. The 4.x packages of this plugin ship the file as README.txt in capital letters, so on a case-sensitive host the lowercase address returns a 404 and it looks like the file is not there. It is there. Try the uppercase spelling before concluding anything.

From your page source (no login needed): view the source of your home page and look for the plugin’s own front-end assets at exactly these paths:

/wp-content/plugins/content-views-query-and-display-post-page/public/assets/js/cv.js?ver=...
/wp-content/plugins/content-views-query-and-display-post-page/public/assets/css/cv.css?ver=...

The ?ver= number attached to those files is the plugin’s own version. On a default install they load on every front-end page, whether or not a post grid appears on it, so your home page is usually enough. On very old installs the same two files are named public.js and public.css, and the same rule applies to them.

The trap to avoid here, and it is an easy one to fall into. This plugin ships bundled copies of several third-party libraries inside its own plugin folder, and each of those carries its own, entirely unrelated version number. Your page source may show Bootstrap at 3.3.5 or 3.3.0, Select2 at 3.4.5, html5shiv at 3.7.0, respond.js at 1.4.2, and bootstrap-paginator at 0.5, all of them on paths that begin with the Content Views plugin folder. An operator who searches the page source for the plugin folder and reads the first ?ver= value that turns up can easily come away believing the plugin is on “3.3.5”, and then puzzle over how that compares to 4.5. It does not compare at all. A number like 3.3.5 or 0.5 sitting on a bootstrap or select2 path is the version of a different piece of software. Read the version only off cv.js or cv.css (or public.js / public.css on a very old install), and ignore every other ?ver= in the page.

If you cannot get a readable number out of the page source at all, that is common and is not a sign of anything: caching and optimisation plugins routinely strip the ?ver= value off asset URLs, or bundle the files into a combined script. In that case the README.txt is the reliable public read, and the admin screen in the first check always has the answer.

Then apply this rule, and note that versions compare numerically, not alphabetically, so 4.10 would be newer than 4.9 even though it looks smaller as text:

  • Anything older than 4.5: affected. Update. There is no cut-off below which an older release becomes safe again.
  • 4.5 or newer: already fixed as far as this issue is concerned. The current release at the time of writing is 4.5.1, and taking the latest available version is the best move.

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 Content Views update is listed, install it from here.
  3. If you prefer the command line, WP-CLI does the same thing: wp plugin update content-views-query-and-display-post-page (the command uses the folder name, not the display name).
  4. If no update appears, you can get the latest release directly from the plugin’s page on the WordPress.org directory, Content Views – Post Grid & Filter, and update via Plugins then Add New Plugin then Upload Plugin.
  5. After updating, confirm the new version number (4.5.1 or later) using the steps above, and check that your post grids and any filters on them still display 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 4.5.1 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.

Two small things are worth doing while the update is fresh:

  • Confirm the version actually moved, using whichever of the checks above was easiest, and load a page that shows one of your post grids to make sure it still renders.
  • If you had WordPress registration open and do not need it, consider closing it. That is general hygiene rather than a fix for this issue, which the update has already handled, and it is worth remembering that other plugins on your site may create accounts regardless.

You will notice there is no “assume you have been compromised” checklist on this page, and that is deliberate rather than an omission. What this issue yields is a database read reachable from a low-privileged account. It does not hand anybody an administrator account and it does not run code on your server, so the administrator audit and password-rotation drill I recommend after a takeover-class flaw would not be proportionate here. Update, confirm, and carry on.

What I did and did not do

To be fully transparent about the check behind my email, here is the whole of it. I read pages and files that your site already serves to every visitor:

  • your home page, and the asset addresses written into it;
  • the plugin’s public README.txt inside wp-content/plugins/content-views-query-and-display-post-page/;
  • your site’s standard WordPress registration page at /wp-login.php?action=register, to see whether it is open to visitors. That is a published page, and reading it is all I did.

I did not submit that registration form, did not create an account, and did not log in to your site. I did not send anything to the affected feature. That last point is the one I want to be clearest about: the issue is an SQL-injection sink, and firing a payload at somebody else’s database is not something this project does, in a lab or in production. Nothing was submitted, tested, or exploited, and nothing touched your WordPress admin area, your database, or any private part of the site.

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 4.5. It is not a statement that your site was exploitable at the time I checked. Because using this issue requires somebody to be logged in, and I cannot see who holds accounts on your site, a site in the affected range may well not be exposed at all, and a site in that range may separately be protected by other means such as a web application firewall or a backported fix.

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