If you received an email from me pointing you to this page, it is because your website appears to be running a version of Depicter Popup & Slider Builder (the WordPress plugin by Averta, which lives in your files at /wp-content/plugins/depicter/) 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, because there is no fixed version yet, what you can do in the meantime.

The issue is CVE-2026-66622, an SQL injection. It affects every release from 3.5.0 onward, including the current release, 4.8.0. The published severity is CVSS 7.5 (High), from Patchstack, the organisation that reported it. I am not aware of any public exploit code for it.

There is, at the time of writing, no fixed version. This is the unusual part, and I want to be plain about it: the plugin’s own vendor has not yet released a version that closes this issue, and the latest release (4.8.0, from 15 August 2026) is still affected. So unlike most notices of this kind, this one cannot end with “update to version X”. It ends with some interim steps and a recommendation to watch for a release newer than 4.8.0. I will update this page if and when a fixed version appears.

Older releases, before 3.5.0, are not affected by this issue. Unlike some flaws, this one was introduced at a specific point in the plugin’s history: the vulnerable database code first shipped in version 3.5.0 (September 2024). If you are running something older than 3.5.0, this particular issue does not apply to you, though a plugin that many releases behind is worth updating for other reasons.

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 is a stored, second-order issue, which means two things have to be true for it to bite:

  1. Your site collects entries through a Depicter form. Depicter can build sliders, popups and notification bars that do nothing but display content, and if that is all you use it for, this issue does not reach you. It only matters if you use a Depicter form (a subscription, contact or lead-capture form) that stores what visitors submit.
  2. An administrator later opens or exports those entries. The malicious input is planted by an anonymous visitor through the form, but it does not do anything at the moment it is submitted. It only runs later, when you or another administrator open or export the collected entries on the plugin’s Leads screen in your WordPress dashboard.

So this is not a flaw that a stranger can use to read your database directly, and it is not something that attacks your site’s visitors. It runs inside your own admin area, and only if you are collecting form entries and then viewing them. I can read your plugin version from a public file, but I cannot see whether you run a Depicter form or whether you ever open its entries, so this notice is a precautionary heads-up rather than a confirmed finding about you.

It is worth being precise about what this issue is and is not. It lets input that an anonymous visitor planted through a form read data out of your site’s database when an administrator views the collected entries: data such as password hashes and secret keys that the query was not meant to expose. That is worth taking seriously. But it is not a takeover of your administrator account, and it is not remote code execution. I mention the boundary because security notices are easy to over-read, and I would rather you know the real shape of it than assume the worst.

What you can do while there is no fix

Because there is no patched version to install, this is about reducing exposure until one arrives. In rough order of how directly they help:

  • If you do not use Depicter to collect form entries, you are not exposed through this path. Using it only for sliders, popups or notification bars that display content is fine.
  • Limit who can open the Leads screen. The issue only runs when an administrator views the collected entries. If you can avoid opening or exporting Depicter’s Leads while a fix is pending (or restrict that screen to as few trusted people as possible), you reduce the window in which it could run.
  • Consider whether you need the form at all right now. If a particular Depicter lead form is not essential, removing or disabling it removes the input path.
  • If Depicter is not doing anything important on your site, removing the plugin closes the issue entirely. That is the most complete step, and reversible: you can reinstall once a fixed version ships.
  • Watch for an update above 4.8.0 and apply it promptly when it lands. This is the real fix, whenever the vendor releases it.

None of these is a perfect substitute for a patch, which is why the main advice is to keep an eye out for a fixed release.

How to read your version without being misled

If you want to confirm which version you are running, do not rely on the version number that appears in the little ?ver= tag on the plugin’s asset URLs in your page source. For Depicter, that number is a file timestamp, not the plugin version: it is generated from when the file was last written on your server, so it will not match the release you actually have and can look like almost anything.

The reliable way to read your version is the plugin’s own readme.txt, which ships inside the plugin folder and is served as a plain text file. Visit:

https://your-site.example/wp-content/plugins/depicter/readme.txt

(replacing your-site.example with your own domain) and look at the Stable tag: line near the top. That is the installed version. You can also see it in your WordPress dashboard under Plugins, where “Depicter Popup & Slider Builder” will show its version number.

How I know, and what I did not do

I looked only at pages and files your site already serves to every visitor: your homepage, the asset URLs written into it, and the public readme.txt inside the plugin folder. That is how I read the version and confirmed the plugin is present.

I did not access your WordPress admin area, your database, or any private part of your site. In particular, I did not submit any form, did not open or export the entries your forms collect, and did not send anything to the affected feature. Nothing was tested or exploited. Exercising this issue would mean planting an injection payload in someone’s database, which is exactly the thing this notice exists to help you avoid, so of course I did not do it to you.

Verify all of this independently

You do not have to take my word for any of it. These are independent sources:

If you are not the person who maintains this site, please forward this to whoever does. If you have questions, you are welcome to reply to the email that brought you here.