Crucible Active

Vulnerability research against the WordPress plugin ecosystem, disclosed through the channels that assign CVE identifiers.

Crucible is an independent vulnerability research programme aimed at WordPress plugins — finding security defects, confirming they are real, and disclosing them so they get fixed and catalogued.

WordPress runs a large share of the web, and most of the code an ordinary site actually executes is not WordPress. It is plugins: the contact form, the file manager, the membership gate, the checkout extension. That is where the interesting failures are, and it is where this project looks.

How a finding is handled

Everything here is disclosed through a CNA — a body authorised to assign CVE identifiers — which runs the coordination with the vendor. That choice is deliberate. A CNA has an established channel to maintainers, a public catalogue that outlives any one researcher's website, and a disclosure process that does not depend on a stranger being trusted.

The sequence is always the same:

1. Confirm before claiming. A defect is reproduced on a clean, current installation before it is written up. If it cannot be reproduced, it is not reported — however good the reasoning looked.
2. Claim exactly what was demonstrated. Not the worst case the mechanism suggests, and not less than what was actually shown. Both directions are errors.
3. Report, then wait. The CNA coordinates with the vendor. Timing is theirs.
4. Publish only after. A finding appears on this site once the CVE is public and the coordinating body confirms disclosure is complete.

That last point is a condition, not a waiting period. There is no number of days that makes an embargoed finding safe to talk about, so there is always a gap — sometimes a long one — between the work and anything written about it here. A quiet page is what the process looks like from outside.

What this project will not do

• No selling. Findings go to the coordinating body and the vendor. Not to a broker, not to a buyer, not to anyone who wants them unfixed.
• No pressure. No self-imposed deadline used as leverage, no "disclose or else". If a vendor is slow, that is between them and the CNA.
• No exploitation. Nothing is tested anywhere but a disposable local installation built for the purpose. No live site, ever, including sites that look abandoned.
• No hinting. An embargoed finding is not teased, not described by mechanism, and not alluded to in a post about something else.

On AI assistance

This research uses AI tooling, and that is disclosed on every submission, because the bodies receiving these reports are entitled to know how they were produced.

It is worth being precise about what that does and does not mean. A model is useful for reading a lot of code carefully and for arguing against a conclusion until it breaks. It is not a source of truth: a plausible, well-written, entirely fictional vulnerability report is exactly the thing these tools produce most easily. So nothing reaches a submission on the strength of an argument alone — every claim is checked against the code, and the impact is demonstrated rather than described.

Advisories

Listed here once the CVE is public and the coordinating body confirms disclosure is complete. Findings that are still in coordination do not appear, in any form.

Each entry names the release the vendor published as carrying the fix. For CMB2, HivePress, FluentCart and the WP File Manager trio that release has been read against the vulnerable one — checking that the specific defect is gone, that the new guard refuses rather than merely computing a verdict, and that the diff did not visibly trade one problem for another. That is a reading, not a re-test, and it covers the named defect only.

FluentCart's reading is worth a sentence of its own, because we got it wrong first and the correction is the useful part. We compared the two newest releases, found the files we had cited byte-identical across them, and read that as the defect still being present. It was not: those two releases are both after the fix, and byte-identity with an already-fixed version means still fixed. The fix sits at the boundary we had not looked at. We had concluded in writing that a correction was owed asking the coordinating body to widen the affected range to cover releases that were in fact patched, and that conclusion was refuted before anything was sent by the adversarial review we route such claims through, rather than by any check of ours. Had it gone, this row would carry a permanent, credited claim that a fixed release was vulnerable. The range you see here is the coordinating body's own, and it is correct.

The title is theirs too, and the exchange behind it is worth recording because it ran the opposite way to the one people expect. We submitted a long heading that led with provisioning an account on an email address the attacker does not control. The coordinating body shortened it to a plain account takeover, which claimed more than we had shown. We wrote back to say so and asked them to keep the limit our own report already stated, that somebody who already holds an account on that address cannot be targeted. They restored it. The published title is narrower than either of the two that preceded it, the bound was ours to volunteer, and the wording is theirs.

About the severity scores. Each CVSS above is the one shown by the body named in the "Coordinated by" column, not a score of ours. That matters more than it sounds, because the same defect can be scored by several parties independently, and they do not always agree.

CVE-2026-77826 is the clearest case here. The database that assigned the identifier shows 8.8; the Wordfence database, which keeps its own record of the same defect, publishes 9.8. Those fall either side of the boundary between high and critical, so a reader checking one source would reasonably conclude the other had it wrong.

Neither has it wrong. Comparing the full vectors, they agree on every metric but one: whether exploitation requires the victim to do something. One says it does and reaches 8.8, the other says it does not and reaches 9.8. That single judgement is the whole gap.

Two things about this surprised us enough to be worth stating. The vector explaining the difference is not published on the page showing the score; it is in the underlying CVE record, which is a different document in a different place. And in that record the 8.8 is not attributed to the assigning database at all, but to a separate enrichment programme, with the assigner's own metrics left empty. So the number a reader sees beside an advisory is not always that publisher's own assessment, and nothing on the page says so. We show the coordinating body's figure in every row, which here is the lower of the two, and we would rather point at the disagreement than quietly pick whichever reads better.

About that last column. These are not the time spent writing the reports up. They are the work inside our sessions that we can attribute to that plugin — the read of the code and the trace from the entry point to the sink — up to an anchor we record ourselves. That anchor is a proxy for the moment of submission, and on both published rows it lands hours early: Masteriyo's precedes the commit recording the submission by three hours, Relevanssi's by four, with six rounds of adversarial review committed in between. So confirmation, gauntlet and report-writing time can fall outside the figure rather than inside it. We would rather publish that than a clean-looking number.

Masteriyo's 77 minutes were a plugin we had never looked at before, and all of it happened on one day; the vendor shipped the fix three days later, in 3.4.0. Relevanssi's 233 ran across two days. Neither number includes the work that came after the anchor — 437 further minutes for Masteriyo and 422 for Relevanssi — because that is not what this column measures.

Active time is wall-clock time inside our research sessions, attributed to that plugin, with any gap over five minutes treated as idle and not counted. It is pipeline time, not human hours. This is an AI-assisted pipeline and every report we file says so. It also leaves out everything that happens outside a session — filing the form, recording the video, and any reading done outside the tooling. Read it as a floor. Figures are given to the nearest minute.

Both figures are anchored at the end on our own record of having submitted, rather than on the coordinating body's ticket number, and that makes them weaker than an anchor a reader could check. We would rather say so than quietly present the two kinds as the same thing.

The reasons differ. WPScan does not acknowledge a submission at the moment you make it, so for Masteriyo there was no ticket to anchor on until triage some days later — the weaker anchor is forced. Relevanssi went to Wordfence, which does issue a number immediately, so there the weaker anchor is ours: the ticket exists and our records simply do not tie it to the minute the report went in. One is a limit of the venue and the other is a limit of our bookkeeping, and only the second is ours to fix.

Where a row shows nothing, the reason differs, and the differences are worth stating rather than letting one word cover all of them.

For RegistrationMagic and HivePress our records do hold time against the plugin — 93 minutes and 166 minutes respectively — and it appears to fall after the report had gone in, on the re-checks, the debrief and the follow-up. We say appears deliberately: neither row has a real anchor. Both fall back to a synthetic midday placeholder on the submission date, and RegistrationMagic's own commits from that day straddle it. So the partition into before and after is an inference on these two rows, not a measurement.

Part of that is a fact about the work and part is a fact about our instrumentation, which only begins on 30 July 2026. HivePress was reported eleven days before that date, so there is no pre-submission window for it to measure at all. Either way none of it measures the thing this column is about, so publishing it as a figure would describe the wrong work.

CMB2 and FluentCart are blank for a stranger reason. The measurement has to decide when the sustained run started, and that decision has parameters: how many minutes in a day count as working on it, how many quiet days end the run. Vary those across a reasonable range and either start date moves by more than a day. A figure that swings on a parameter nobody chose is not a measurement of the work, it is a measurement of the setting, so the tool declines to print one. Every other row that has a start date at all holds still across the same range.

FluentCart fails a second, independent test as well, and it is the one worth being plain about because it is the newest row here and the temptation was to treat it as the best-instrumented one. Our records hold a substantial amount of time against that plugin — enough that quoting it would have been flattering rather than modest. But the end of the run resolves only to the calendar day we recorded the report as sent, with no sighting of the coordinating body's ticket near it and no recorded moment of submission. A start that moves with the settings and an end known only to the day do not combine into a duration. The end anchor is one we record ourselves, and on this row we did not record it, so the gap is in our bookkeeping rather than in anything the coordinating body did. That makes it ours to fix, and it is not fixed yet.

Relevanssi we did get wrong, and the correction is worth recording rather than quietly fixing. This page said for two weeks that all of its recorded time fell after the report went in. That was true of most of it and not all: 422 minutes do fall after, and 233 fall before, across the two days leading to the submission. What changed is not our opinion but our evidence — the earlier reading was taken while a chunk of our own session records had become unreadable to the tool, and recovering them put the pre-submission work back in view. The figure in the table is those 233 minutes.

The last row is the awkward one, and it is awkward because it is three plugins rather than one. The three answer differently, and no single number describes the row.

One of them we can measure: 37 minutes, on one day. One of them we cannot, because that plugin carries more than one submission of ours and nothing in our records partitions a plugin's time between them — the measurement credits it once, to the earliest, and crediting it again here would publish one stretch of work twice as two achievements. The third falls in between: there is a run, but the record of when it ended is too coarse to turn into a figure we would defend.

So we could print the 37 and we have chosen not to. It is a real measurement covering one of the three plugins, and set alone in a row covering three plugins over three weeks it would read as the cost of the whole thing. A number that flatters us by omission is worse here than no number, and the reader loses nothing they were entitled to: the work is described above, and this column has never claimed to price it.

Proof-of-concept detail is withheld by the coordinating body on six of these, so that sites have time to update. The dates it set are 17 September 2026 for CVE-2026-82846, 3 October 2026 for CVE-2026-77826, 6 October 2026 for CVE-2026-80338, 12 October 2026 for CVE-2026-100143, 15 October 2026 for CVE-2026-92437, and 24 October 2026 for CVE-2026-85081. Once one of those dates passes, WPScan's own page governs what it shows from then on. All three Wordfence advisories — CVE-2026-18056, CVE-2026-19985 and CVE-2026-93428 — carry no proof-of-concept section at all, so no date attaches to any of them.

We check that by opening the advisory page and reading it, rather than by assuming a venue's habit holds. That is not a formality. One of these dates was found by a person reading the page while a draft was being written, against an automated read of the same page that had reported no restriction at all, twice. The page is the authority and a tool's summary of it is not.

Those dates bind the coordinating body. They do not describe what we do, because we do not publish proofs of concept at all — not for any finding, not at any remove, and not once a date passes. The coordinating bodies carry that detail where they judge it right to. Nothing on this site goes further into mechanism than the advisories themselves.

What that check is not. It covers the one defect named in the row, in the one release named in the row. It is not an audit of the plugin, not a statement about any other version, and not an endorsement of the software or its vendor. A plugin appearing in this table is a plugin that had a defect reported and fixed — which is how it is supposed to work, and says nothing about what else may be in it. If you need assurance about a plugin, this table is not that, and nothing on this site should be read as a reason to skip your own review.

If you maintain a plugin and want to reach us about something, see Disclosure.