CVE-2026-112862: Participants Database Flaws, No Patch Yet

If you run the Participants Database plugin on WordPress, CVE-2026-112862 is the one to check tonight. It is a critical PHP object injection flaw, scored 9.8 out of 10, affecting every version up to and including 2.7.8.5 — and as of the evening of 24 October 2026, I could not confirm a vendor patch release for it. Worse, it did not arrive alone: the same plugin, in the same version range, carries a second critical flaw the same week, a blind SQL injection tracked as CVE-2026-112860. Both are unauthenticated, both hit the same installs, and both leave you with the same awkward decision: wait for a fix that has not been confirmed, or take the plugin offline until one appears. This guide walks you through checking your site in under two minutes, deciding what to do, and protecting the site if you cannot switch the plugin off.

Table of Contents

What was disclosed, in plain terms

Two CVE records for xnau webdesign’s Participants Database plugin were published on 23 October 2026. Here is the short version:

CVE	Flaw	CVSS score	Affected versions
CVE-2026-112862	PHP object injection (CWE-502, deserialization of untrusted data)	9.8 Critical	Through 2.7.8.5
CVE-2026-112860	Blind SQL injection	9.3 Critical	Through 2.7.8.5

The object injection record carries the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Read it piece by piece and it is stark: network-accessible, low complexity, no privileges required, no user interaction required, and high impact on confidentiality, integrity and availability. The blind SQL injection record is nearly as bad — also unauthenticated and network-accessible, with a scope change (S:C) and high confidentiality impact. In both cases the attacker does not need an account on your site. That is what separates a “patch when convenient” plugin bug from a “check tonight” one.

One important restraint: the public records are sparse. They do not disclose the vulnerable endpoint, the parameter, or a working exploit. For the object injection flaw, independent summaries are careful to say that code execution is not independently established by the sparse record alone — it depends on a suitable gadget chain being present in the site’s code. Do not read “object injection” as “instant RCE on every site”, and do not read the missing details as “probably safe”. The honest reading is: a severe, unauthenticated deserialization flaw in a plugin that handles other people’s personal data, with no confirmed fix.

What PHP object injection actually means

PHP object injection happens when an application takes data supplied by an attacker and feeds it to PHP’s unserialize() (or an equivalent deserialization routine) without strict controls. Serialized PHP data is not just text — it describes objects, their classes and their properties. When PHP rebuilds those objects, it can run special “magic” methods such as __wakeup() and __destruct() on the classes involved. An attacker who can control the serialized string can therefore pick which classes get built and with what properties.

That alone does not hand over the server. The injected objects only do damage if the site already contains a “POP chain” — a sequence of classes whose magic methods, chained together, reach something dangerous, such as file deletion, file inclusion or command execution. Patchstack’s own glossary puts it the same way: object injection can lead to code injection, SQL injection, path traversal or denial of service if a proper POP chain is present. WordPress sites are a rich place to look for one, because a site typically runs dozens of plugin and theme classes alongside the vulnerable plugin. So the correct mental model is not “exploitable everywhere, guaranteed” but “unauthenticated, and the blast radius depends on what else is installed”. That is exactly the kind of flaw you do not leave exposed while you wait.

Participants Database makes the stakes higher than a typical plugin bug. It exists to hold databases of people — members, volunteers, supporters, constituents — with configurable fields, signup forms, searchable lists and CSV import and export. A flaw that can reach the database, or the files around it, therefore risks personal data, not just a defaced homepage. If your site collects signups through this plugin, treat the data-protection angle as seriously as the takeover angle.

What blind SQL injection means

Blind SQL injection is the quieter cousin of the classic kind. In an ordinary SQL injection, the attacker injects SQL into a query and sees the result on the page. In a blind injection, the result is not returned — but the attacker can still extract data by asking the database yes-or-no questions and watching how the page behaves: a slightly different response, a page that loads, a page that does not, a query that takes longer. Asked thousands of times, those yes-or-no answers spell out usernames, hashes and record contents character by character.

Blind does not mean slow enough to ignore. Automated tools do the asking, and the CVE-2026-112860 record is rated 9.3 precisely because it is unauthenticated. For a plugin whose whole job is storing other people’s records, an unauthenticated route to the database is a data-breach risk even before anyone talks about admin accounts. The two flaws together also matter for defence: fixing only one, if a fix appears, still leaves the other. Check for both, and do not close the ticket until both are covered.

Are you affected? The two-minute check

Start in the WordPress dashboard. Go to Plugins > Installed Plugins and look for Participants Database. The version number sits in the plugin’s description block. If it reads 2.7.8.5 or anything lower, you are in the affected range for both CVEs. If it reads higher than 2.7.8.5, check the changelog on the plugin page before relaxing — the version number alone does not tell you whether that release fixed these two flaws.

If you have WP-CLI access, the same check is one command from your site root:

wp plugin list --format=csv | grep participants-database
wp plugin get participants-database --field=version

Also check for the plugin on sites you have forgotten about: staging copies, old client sites, multisite subsites, and any install where the plugin is installed but deactivated. A deactivated plugin is not exploitable through its normal routes, but it becomes a risk the moment someone reactivates it without checking, and it still counts as unpatched software in an audit. Make a list of every install that has it, active or not.

While you are there, note whether the plugin is actually load-bearing. Participants Database is often installed for one directory, one signup form or one member list. If the site no longer uses it, the answer is easy: remove it. If it does use it, the next section is your decision tree.

The patch-status confusion, stated plainly

You may see conflicting advice on whether a fix exists, so here is what the sources I checked on 24 October 2026 actually say. Patchstack’s entry for CVE-2026-112862, dated 21 October, says it has issued a mitigation rule “to block any attacks until an official patch becomes available, can be tested and be safely applied”. That wording — until an official patch becomes available — is the language of a fix that had not been confirmed at the time of the entry. The CVE summaries I checked likewise list no fixed version for either flaw; the blind SQL injection record explicitly shows its “fixed in” field as blank.

One aggregator, CVEFeed, lists “update to version 2.7.8.6 or later” as its solution for CVE-2026-112862. I could not confirm that version against the vendor changelog or the Patchstack entry, so do not treat 2.7.8.6 as a confirmed fix on that basis alone. The practical rule is simple: open Plugins > Installed Plugins and see whether WordPress offers you an update above 2.7.8.5. If it does, take it, then check the changelog to confirm it mentions these CVEs. If it does not, act as though no patch exists yet — because, on the evidence available tonight, that is the safe assumption.

What to do tonight: the decision tree

1. If an update above 2.7.8.5 is offered, install it. Back up first — files and database — then update from the dashboard or with wp plugin update participants-database, and confirm the version number changed. Test the signup form and the list display afterwards; a security fix should not change behaviour, but a broken form is how a quiet update becomes a Monday-morning support ticket.

2. If no update is offered and the plugin is not essential, deactivate and delete it. This is the strongest move available while no patch is confirmed, and it is the one Patchstack’s general guidance points to for unpatched components: replace or remove the component. Export your records first if you need them — the plugin supports CSV export — then deactivate, then delete, so the code is not sitting on disk waiting to be reactivated.

wp plugin deactivate participants-database
wp plugin delete participants-database

3. If no update is offered and you cannot switch it off, put a virtual patch in front of it. Patchstack has issued a mitigation rule for the object injection flaw; if you run Patchstack, or another WordPress firewall that has shipped a rule for these CVEs, enable it. A web application firewall rule is not a fix — it is a filter that blocks known attack patterns while the vendor works — but for an unauthenticated flaw, a filter tonight beats a perfect fix next week. Keep the rule in place until a confirmed patched version is installed, and remove or review it afterwards rather than letting stale rules accumulate.

4. In every case, watch for the patch. Check the Plugins page again over the next few days, and subscribe to the plugin’s changelog or the Patchstack entry if you can. When a fixed version does land, update promptly and re-test. A flaw this severe, in a plugin handling personal data, is the kind that attracts mass scanning once exploit details circulate — Patchstack itself warns that vulnerabilities of this class are used in mass-exploit campaigns against thousands of sites at a time, regardless of traffic size.

If you cannot disable it: reduce the blast radius

Sometimes “just turn it off” is not a real option — the member directory is live, the signup form feeds an event, and nobody will thank you for a blank page. In that case, shrink what an attacker can reach. First, make sure the database user WordPress runs as does not have more privileges than the site needs; a dedicated application user limited to its own database contains a SQL injection far better than a root-level connection. Second, limit who can reach the plugin’s front-end forms: if signups are closed, close the form; if the directory is members-only, keep it behind login. Third, turn on logging and actually look at it — unusual bursts of requests to plugin URLs, odd serialized-looking payloads, and repeated failed form submissions are the early signs of probing. None of this replaces a patch, but each step raises the cost of an attack.

Also review the accounts on the site. Look for admin or editor accounts you do not recognise, and for recently changed passwords or email addresses on existing accounts. Object injection and SQL injection both end, in the worst case, at admin access — and the first sign is often a new account, not a defaced page. If you find one, treat it as a compromise, not a curiosity: preserve logs, reset credentials, and work through the malware-removal checklist linked below.

Exploitation status: what is known, and what is not

As of 24 October 2026, I found no confirmed report of either flaw being exploited in the wild. The object injection record’s CISA assessment lists exploitation as “none”, and the blind SQL injection record is not in CISA’s Known Exploited Vulnerabilities catalog, with no exploitation reported. One independent tracker puts the 30-day exploitation probability estimate (EPSS) for the object injection flaw at 0.3% and for the SQL injection flaw at 0.2% — low numbers, but EPSS is a probability estimate, not a promise, and it moves fast once exploit code appears.

Do not confuse “no exploitation reported yet” with “safe”. Both records were published only a day before this post, the flaws are unauthenticated, and Patchstack’s standing warning for this vulnerability class is that mass-exploitation campaigns follow. The window between disclosure and mass scanning is often measured in days. Acting tonight, while the record is still “no exploitation reported”, is the whole point.

What not to do

Do not hand-edit the plugin’s code to “fix” the deserialization yourself unless you genuinely understand the code path — a half-fix that still accepts serialized input, or that breaks the plugin’s legitimate data handling, leaves you with a false sense of safety and a broken site. Do not assume a small site is safe: mass-exploit campaigns scan indiscriminately, and a member database is valuable precisely because it holds other people’s details. Do not leave the plugin installed-but-deactivated as a permanent answer either — delete it, or set a calendar reminder to revisit it, so a future reactivation does not quietly reintroduce two critical flaws. And do not wait for a vendor announcement in silence: if you run a firewall with virtual patching, enable the rule now, and if you do not, the disable-or-delete decision is the protection.

Bottom line

Two critical, unauthenticated flaws in Participants Database, both affecting versions through 2.7.8.5, both published 23 October 2026, and no vendor patch confirmed as of this evening. Check your version, take an update if one is offered above 2.7.8.5, otherwise deactivate and delete the plugin — or, if you truly cannot, put a firewall rule in front of it and watch for the patch. The check takes two minutes. The regret, if a mass-scanning campaign reaches your member list first, takes considerably longer.

CVE-2026-112862: The Participants Database Flaws With No Patch Yet (2026)