If you received an email from me pointing you to this page, it is because your website appears to be running a version of Link Library (the WordPress plugin by Yannick Lefebvre, which lives in your files at /wp-content/plugins/link-library/) 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-16532, an unauthenticated SQL injection flaw reachable through the plugin’s link submission handling. It affects every release before 7.9.3 and is fixed in 7.9.3. The current release at the time of writing is 7.9.4, which also carries the fix. If you are running anything older than 7.9.3, update Link Library to 7.9.3 or later.

One thing to be clear about: 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 vulnerable code is present in every published release I was able to check, all the way back to the oldest version the WordPress.org directory still serves. “My install is too old to be affected” is not a way out here. The only versions that are not affected are 7.9.3 and newer.

Just as important: this notice does not depend on how your site is configured. Link Library includes a form that lets visitors suggest links, and the natural assumption is that a site is only exposed if it has actually put that form on a page somewhere. That assumption is wrong. The affected code runs on every ordinary front-end request, whether or not you have ever published the submission form, and the plugin’s stock settings do not block it. If your site runs an affected version, it is reachable. Full stop.

This is a plugin flaw, not a WordPress core flaw. A fully up-to-date WordPress does not protect you if the Link Library 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 submit anything to the plugin’s link submission feature, on your site or any other, 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

Link Library builds and displays directories of links on your site, and it can accept link suggestions from visitors. The suggestion handling is where this issue lives.

In affected versions, when the plugin processes a submitted link, its check for whether that link already exists builds a database query by pasting the submitted values directly into it. The values are cleaned up for display, but they are not escaped for use in SQL, and the query runs without a prepared statement. The consequence is that a visitor who is not logged in can alter that query and read data out of your site’s database. Version 7.9.3 rewrites the query to use a prepared statement, which closes the issue.

To repeat the point from the top, because it is the one most likely to give false comfort: exposure does not depend on the submission form being published anywhere on your site. The code path that processes submissions listens on every front-end request, and everything a request needs in order to reach it can be obtained from the plugin itself, without any form existing on any page. Whether your site is exposed comes down to one thing only: the version you are running.

It is also worth being precise about what this issue is and is not. It lets an attacker read data from the database. That is serious on its own, since a WordPress database holds things like user email addresses and hashed passwords, and on some sites customer or member records. But it is not, by itself, remote code execution, a site takeover, or a way for an attacker to hand themselves an administrator account. 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.

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 7.9.3. 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 Link Library 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 Link Library, the entry whose folder is link-library, and note the version shown beneath its name.

From the public manifest (no login needed): open yourdomain.com/wp-content/plugins/link-library/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 I verified that it matches the actual released code in every recent release, so it is a reliable check.

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 version numbers on this plugin’s asset URLs are the frozen versions of bundled third-party libraries (values like 4.0.1, 1.0.0, or 1.3.9), or the WordPress core version. None of them is the plugin’s version, and comparing any of them against 7.9.3 is meaningless. Use the admin screen or readme.txt.

One more edge case: some very old installs show Stable tag: trunk in their readme.txt. That is not a version number at all. If you see it, use the admin plugins screen instead, and treat the install as affected until the screen tells you otherwise, since an install old enough to say trunk is certainly older than 7.9.3.

Then apply this rule:

  • Anything older than 7.9.3: affected. Update. There is no cut-off below which an older release becomes safe again.
  • 7.9.3 or newer: already fixed. 7.9.4, the current release, carries the fix too.

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 Link Library update is listed, install it from here.
  3. If you prefer the command line, WP-CLI does the same thing: wp plugin update link-library.
  4. If no update appears, you can get the latest release directly from the plugin’s page on the WordPress.org directory, Link Library, and update via Plugins then Add New Plugin then Upload Plugin.
  5. After updating, confirm the new version number (7.9.3 or later) using the steps above, and check that your link directories still display and behave 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 7.9.3 or later closes the issue: the submission check now runs as a prepared statement, so submitted values are treated as data rather than as part of the query.

What updating cannot do, stated carefully. Updating stops anything being read from your database in the future. It cannot un-read anything that may already have been read while the site was on an affected version. I have no visibility into whether that happened on your site, and I did not look; most sites in the affected range have probably never been touched. But because I cannot tell you that for certain, a little precaution is reasonable, in proportion to what your database holds:

  • If your site is a straightforward publishing site, where the database holds your posts, pages, and a handful of user accounts, the sensible step is to have your users (and especially your administrators) change their passwords. WordPress stores passwords hashed, not in plain text, but hashes of weak passwords can be cracked offline, so a fresh password removes that worry.
  • If your site stores anything more sensitive (member records, customer details, API keys or other credentials kept by plugins), treat those as worth rotating too.
  • 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 and invalidates any stolen session tokens.

To be clear about the framing: this is a precaution, not a declaration that your data was taken. This notice is based on a version number, not on any evidence of an attack.

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.

In particular, I never submitted anything to the plugin’s link submission feature, on your site or anywhere else. Nothing was submitted, stored, tested, or exploited. That matters more here than on most of these pages, because the submission handling 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 7.9.3. 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