+61 2 9043 1246

Knowledge base

GHSA-pcrw-h46h-c93h: the Mongoose countDocuments() filter bypass, explained for website owners

Published · By , Co-Founder, BLACKBX

GHSA-pcrw-h46h-c93h (CVE-2026-125120) is a critical flaw in Mongoose, a database library used inside Node.js web apps. It affects apps that turn on the sanitizeFilter safety setting and count records using visitor input. No exploitation has been reported. Update Mongoose to at least 9.11.4, 8.24.7, 7.8.13 or 6.13.12.

Key fact GHSA-pcrw-h46h-c93h
What Mongoose’s countDocuments() function ignored the sanitizeFilter safety setting, so visitor-supplied values could act as database commands (CWE-943, improper neutralisation of special elements in data query logic).
Affected Mongoose below 6.13.11, 7.0.0 to before 7.8.12, 8.0.0 to before 8.24.3, and 9.0.0 to before 9.9.2, in apps that turn on sanitizeFilter and pass visitor input to countDocuments(). Not a WordPress plugin; apps that do not use Mongoose are not affected.
Fixed in 9.9.2, 8.24.3 and 6.13.11 on 10 August 2026; 7.8.12 (release date not found). Because of a related flaw, today’s minimums are 9.11.4, 8.24.7, 7.8.13 or 6.13.12. Latest is 9.12.0, released 4 November 2026.
Severity CVSS 3.1 score 9.8, Critical, assigned by GitHub as the CVE numbering authority. NVD has not analysed it yet.
Needs a login? No. An attacker does not need an account on the app.
Exploited? Not known. No reports of attacks and no public exploit code found; not in CISA’s Known Exploited Vulnerabilities list as of 9 November 2026 (OffSeq Radar).
Do now Ask your developer which Mongoose version your app runs, and update it to at least 9.11.4, 8.24.7, 7.8.13 or 6.13.12 within its current major version.

Facts checked on 11 November 2026 against the CVE record, OpenCVE’s copy of the NVD data, VulDB, OffSeq Radar, Vulners, Snyk, npm and the Mongoose release notes. Sources are listed at the end.

What is GHSA-pcrw-h46h-c93h?

GHSA-pcrw-h46h-c93h is a security advisory for Mongoose, published through GitHub and given the number CVE-2026-125120. Its official title is “Mongoose: sanitizeFilter not applied on countDocuments”. It is also listed in the European Union’s vulnerability database as EUVD-2026-120503.

Mongoose is a code library that web apps built on Node.js use to store and fetch data in a MongoDB database. Node.js runs JavaScript code on a web server; MongoDB is the database where the app keeps its records. The CVE record lists Automattic as the vendor and describes Mongoose as “a MongoDB object modeling tool designed to work in an asynchronous environment”. It is a building block inside custom-built web apps. It is not a WordPress plugin, and it is not something a site owner installs from a dashboard. It arrives in your app because a developer chose it when the app was built.

Mongoose has an optional safety setting called sanitizeFilter. When a developer turns it on, it stops values supplied by visitors, such as a search term or a form field, from being treated as database commands. The kind of attack it guards against is called query selector injection: sneaking an instruction into what should be plain text.

The flaw sits in countDocuments(), the function that counts how many records match a search. In affected versions, countDocuments() ignored sanitizeFilter altogether.

In plain terms, the developer switched on a safety catch, and one of the doors it was meant to cover was left without it. Values from a visitor that reached a count could act as database instructions rather than plain text, so the count could include records that should not have matched.

The vendor’s changelog entry for the fix reads “apply sanitizeFilter on countDocuments and cursor()”. So the fix also covered a second function, cursor(), which the advisory itself does not mention.

GitHub filed the CVE record. The person or team who found the flaw is not named; the record’s discovery field says “UNKNOWN”. The fixed versions were released on 10 August 2026. The CVE was reserved and published on 9 November 2026 in UTC, which was 10 November in Australian Eastern Daylight Time. GitHub classes the flaw as CWE-943, improper neutralisation of special elements in data query logic. VulDB classes it differently, as CWE-94, code injection.

One naming trap: the aggregator Vulners labels this entry “cesanta mongoose”, a different product with the same name. The CVE record names Automattic as the vendor and the npm package mongoose as the product. This post is about the npm package.

Who is affected?

For an app to be exposed to this flaw, all of these must be true:

  1. The website or web app is built on Node.js and uses the mongoose npm package.
  2. Its Mongoose version is in an affected range: any version below 6.13.11; 7.0.0 up to but not including 7.8.12; 8.0.0 up to but not including 8.24.3; or 9.0.0 up to but not including 9.9.2.
  3. The app has sanitizeFilter turned on.
  4. The app passes values a visitor can control into a countDocuments() call.

The first two points can be answered from the app’s code in a minute. The last two need a developer who knows how the app was written.

What is not affected: apps that do not use Mongoose at all. WordPress sites do not get Mongoose through their plugin list, because it is not a WordPress plugin. Apps on 9.9.2, 8.24.3, 7.8.12, 6.13.11 or later within the same line are fixed for this flaw, although a related issue described below needs slightly later versions. No official list of unaffected products has been published.

Version 5.x needs care. Read literally, “below 6.13.11” takes in every 5.x release, and Mend’s automated scanner is already flagging 5.x versions such as 5.13.14, 5.9.20 and 5.3.16. But no fixed 5.x version is listed, and it has not been confirmed whether 5.x even has the sanitizeFilter setting. If your app runs 5.x, treat it as a question for your developer rather than a clean bill of health.

How many apps use the affected versions is not known.

If your site or web app runs on Node.js and stores its data in MongoDB, assume you are in scope until someone checks the version.

What can an attacker do?

Make the app’s database counts include records they should not, and, where the app makes decisions based on that count, get past checks that were meant to stop them. The CVE record says this could undermine authorisation (the app’s rules about who may see or do what) or other app logic that relies on the count.

How serious that is depends on what the count controls in your app. A count that only drives a number on a page is one thing. A count that decides whether someone has access, or whether a limit has been reached, is another.

Three things make it worse:

  • No login needed. The scoring says an attacker needs no account and no privileges on the app.
  • No interaction needed. Nobody on your side has to click a link or open a file for it to work.
  • Public reach. It is reachable over the network, so any public page or interface that feeds visitor input into an affected count is open to anyone on the internet.

GitHub, as the CVE numbering authority, scored it 9.8 out of 10 on CVSS 3.1, which is rated Critical. CVSS is the standard scale for rating how bad a vulnerability is. The 9.8 reflects that no login, no interaction and network reach are all present, and that the worst case affects confidentiality, integrity and availability of data.

Other numbers are circulating, and they do not change the picture. NVD, the United States’ national vulnerability database, has received the record but not analysed it yet, so it has no score of its own. OpenCVE’s copy of the NVD data shows a “5.9” marked “Secondary” against GitHub as the source; which measure that is has not been explained. Vulners shows an “AI Score” of 5.9, Medium, which is machine-generated by an aggregator and not an official rating. VulDB rates it critical. If your scanner shows 9.8, it matches GitHub’s score.

Is it being exploited?

No attacks have been reported. OffSeq Radar found no evidence of exploitation as of 22:49 UTC on 9 November 2026.

No public exploit code has been found either. VulDB states “There is no exploit available”. OffSeq found nothing in Metasploit or Exploit-DB, two public collections of attack tools, and no template for the nuclei scanner, which is often used to sweep the internet for a known flaw.

The flaw is not on the CISA Known Exploited Vulnerabilities (KEV) list, according to OffSeq’s check on 9 November 2026. The KEV list is the United States Government’s catalogue of flaws confirmed to be used in real attacks. We have not been able to check the catalogue directly today, 11 November 2026.

One point is worth weighing. The code changes that fixed this flaw have been public on GitHub since the fixed versions came out on 10 August 2026. Anyone comparing old and new versions could see what changed, three months before the CVE was announced.

For an Australian business with a custom Node.js app, that means this is not an emergency on the evidence so far, but it is a critical-rated flaw with a public fix and public code changes. It belongs in this week’s work, not next quarter’s.

What should you do now?

In this order:

  1. Find out the version. Your developer can read it from the file node_modules/mongoose/package.json in the app’s code, or by running npm ls mongoose in the project folder. If you don’t have a developer on hand, ask whoever built or hosts the app; it is a quick question for them.
  2. Update within your current major version. The minimums for this flaw alone are 9.9.2, 8.24.3, 7.8.12 or 6.13.11. A related advisory published the same day, CVE-2026-125119 (GHSA-gg4r-jv3p-qx3c), covers another way sanitizeFilter can fail when it is set for the whole database connection, and a third, CVE-2026-125117 (GHSA-8332-j7wj-wjw4), has the same fixed versions. Those need 9.11.4, 8.24.7, 7.8.13 or 6.13.12. So today’s sensible minimums are 9.11.4, 8.24.7, 7.8.13 or 6.13.12. The latest release is 9.12.0, from 4 November 2026. Staying within your major version keeps the change small; moving from, say, 7.x to 9.x is a bigger job that needs testing.
  3. If you run 5.x, get a decision. No fixed 5.x version is listed. Ask your developer to confirm whether the app uses sanitizeFilter at all, and to plan a move to a supported line.
  4. If you can’t update straight away, use the vendor’s workaround. The advisory gives a short piece of code that applies the filter before every count. One caution: in the advisory’s sample, the function does not declare a variable it relies on, so your developer should check it before copying it in.
  5. Check whether the app was exposed. Neither the vendor nor researchers have published signs of compromise for this flaw. Your developer can check whether the app turns on sanitizeFilter, whether any count uses visitor input, and whether that count controls access or limits. If it does, a review of the app’s logs for that feature since 10 August 2026 is worthwhile.
  6. If you find signs of misuse, treat it as an incident. Keep the logs, note what the affected feature controls, and have your developer work out what an attacker could have seen or done through it. The vendor has published no guidance on steps after updating, so this is a judgement for whoever knows the app.
  7. Record what you did. A dated note of the version before, the version after, who did it and what was checked. If a client, insurer or auditor asks, that note is your answer.
  8. Reduce exposure for next time. Tools that watch an app’s code libraries already raised this one: Dependabot opened update requests and Mend’s scanner opened issues in other projects. If your app’s code lives on GitHub, make sure those alerts reach someone who will act on them.

If you can’t find the version, or you’d rather someone else checked, that’s what we do. Details at the bottom.

Why updating is not the whole fix

The update stops the flaw from working from here on. It does nothing about the three months between 10 August 2026, when the fix and its public code changes appeared, and 10 November, when the CVE was announced. Any app still on an older version spent that time with the fix visible to anyone who looked for it.

Nor does the update undo anything that already happened. If a count was skewed and the app acted on it, by letting someone through a check or past a limit, that decision stands until someone finds and reverses it. That is why step 5 above matters for apps where the count controls something.

There is also the knock-on effect of the related advisories. An app updated promptly to 9.9.2 in August is fixed for this flaw but still short of 9.11.4, which covers the connection-level issue fixed on 23 October. Being up to date is a moving target, and a library like this moves several times a month.

That is the pattern with code libraries inside custom apps. The fix arrives quietly in a release note, the CVE arrives months later, and the gap is filled by whoever is actually watching the app.

In many businesses, that is nobody in particular, through no fault of anyone. The host looks after the server. The people who built the app have other work on. And nobody has been told that keeping the libraries inside the app up to date is their job. Mongoose is not visible in any dashboard; it sits in a folder of the app’s code until someone reads its version number.

What this looks like with BLACKBX

BLACKBX reads the exact software versions on every site it looks after each night, and checks new security advisories against them every hour. When GHSA-pcrw-h46h-c93h was published, any client site running an affected Mongoose version would have matched. Because this one is rated critical, our developers patch it immediately; lower-severity items are done at the next service. Every update is dated and recorded in the client’s security logbook, so there is always a written answer to “were we affected, and what was done?”

On the Monitor plan, the finding goes to the client’s own developer with the version numbers and our advice, so the people who know the app can act on it. On Maintenance and Full service, BLACKBX does the work. All plans are monthly, with no minimum term.

Timeline

Date Event
10 August 2026 Mongoose 9.9.2, 8.24.3 and 6.13.11 released, with the changelog entry “apply sanitizeFilter on countDocuments and cursor()”. The release date of 7.8.12 was not found.
23 October 2026 Mongoose 6.13.12 and 8.24.7 released, and 9.11.4 published, fixing the related connection-level issue (CVE-2026-125119).
4 November 2026 Mongoose 9.12.0, the current latest version, released.
9 November 2026 CVE-2026-125120 reserved at 17:45 UTC and published by GitHub at 22:36 UTC (10 November in Australian Eastern Daylight Time). Listed in NVD at 23:17 UTC.
9 November 2026 OffSeq Radar reports no evidence of exploitation and no CISA KEV listing, as of 22:49 UTC.
10 November 2026 VulDB entry updated.
11 November 2026 This article published.

Sources

Common questions

What is GHSA-pcrw-h46h-c93h?

GHSA-pcrw-h46h-c93h, also known as CVE-2026-125120, is a critical flaw in Mongoose, a database library used inside Node.js web apps. In affected versions, the countDocuments() function ignored the sanitizeFilter safety setting, so visitor-supplied values could act as database commands and make counts include records they should not. BLACKBX checks new advisories like this against the exact versions on every site it looks after.

Does CVE-2026-125120 affect my WordPress site?

Not through WordPress itself. Mongoose, the library behind GHSA-pcrw-h46h-c93h and CVE-2026-125120, is an npm package for Node.js apps, not a WordPress plugin. If your business also runs a custom web app or portal built on Node.js and MongoDB, that app may use it. BLACKBX reads the exact software versions on each site it looks after every night, so clients get a direct answer for each site.

Which Mongoose version fixes GHSA-pcrw-h46h-c93h?

GHSA-pcrw-h46h-c93h is fixed in Mongoose 9.9.2, 8.24.3 and 6.13.11, released on 10 August 2026, and in 7.8.12. A related flaw published the same day needs 9.11.4, 8.24.7, 7.8.13 or 6.13.12, so those are the sensible minimums today. The latest version is 9.12.0. On BLACKBX’s Maintenance and Full service plans, our developers make the update and record it in the client’s security logbook.

Is CVE-2026-125120 being exploited?

No attacks using CVE-2026-125120 have been reported, and no public exploit code has been found. OffSeq Radar reported it was not on the CISA Known Exploited Vulnerabilities list as of 9 November 2026. The fix has been public since 10 August 2026, so it is still worth updating promptly. BLACKBX checks advisories every hour and patches critical matches on client sites immediately.

How do I check which Mongoose version my app uses?

A developer can read the version from node_modules/mongoose/package.json in the app’s code, or run npm ls mongoose in the project folder, then compare it with the affected ranges for GHSA-pcrw-h46h-c93h. If nobody on your team works on the app’s code, ask whoever built or hosts it. For BLACKBX clients, we read these versions every night and match them against advisories.

Is Mongoose 5.x affected by GHSA-pcrw-h46h-c93h?

Possibly. The affected range for GHSA-pcrw-h46h-c93h, “below 6.13.11”, takes in 5.x, and some scanners flag 5.x versions. But no fixed 5.x version is listed, and it has not been confirmed whether 5.x has the sanitizeFilter setting. Ask your developer to check whether the app uses it and to plan a move to a supported line. On BLACKBX’s Monitor plan, findings like this go to your own developer with the version numbers and our advice.

Is this your site?

Does your app run an affected version of Mongoose?

Tell us which site or app you’re thinking of, and we’ll tell you whether GHSA-pcrw-h46h-c93h applies to it. If it does, we’ll fix it and record what was done in your security logbook.

Ask us if this applies to you Get these alerts by email

Or call +61 2 9043 1246. Monthly plans, no minimum term.