MariaDB connector CVE-2026-55215: check if you're exposed

Short answer: On 28 August 2026, three CVEs were published for the mariadb npm package (MariaDB Connector/Node.js, ~834k weekly downloads). The worst, CVE-2026-55215 (High, CVSS 7.5), means that if you connect with ssl: true but no CA certificate, the connector sends your database password before it verifies the server, so an on-path attacker can capture it. You are exposed if you run mariadb below 3.2.4, 3.3.3, 3.4.6 or 3.5.3. Upgrade to the patched release on your branch (3.5.3 is current on npm), and rotate the database password if that connection ever crossed a network you don't control.

This post is a defensive explainer: what the three advisories say, how to check whether your project pulls a vulnerable version, what to do about it, and where a registry firewall fits so the next flagged version never reaches npm install.

What was disclosed in the MariaDB connector on 28 August 2026?

The GitHub Advisory Database published three reviewed advisories for the mariadb npm package on 2026-08-28. All three were fixed in the same set of releases: 3.2.4, 3.3.3, 3.4.6 and 3.5.3. The fixes actually shipped in June 2026 (the 3.5.3 release notes list them as CONJS-349, CONJS-350 and CONJS-353); what's new is the public CVE assignment, which is why npm audit and your SCA scanner only started flagging it this weekend.

Affected version ranges across all three: < 3.2.4, 3.3.0 – 3.3.2, 3.4.0 – 3.4.5, 3.5.0 – 3.5.2.

Why does CVE-2026-55215 matter more than its score suggests?

Because it breaks an assumption most teams make: "I turned on ssl: true, so the credentials are protected." In the affected versions, that is only true if the server's identity was checked before the password left the client. When no CA is configured, the connector falls back to fingerprint validation, and that check runs too late. The TLS tunnel is real, but it's a tunnel to whoever answered first.

Where this bites in practice:

• Managed databases reached over the public internet with a connection string that sets ssl=true but ships no CA bundle.
• Kubernetes and VPC setups where "internal" traffic still crosses shared network gear or a compromised node.
• CI jobs and AI coding agents that connect to staging databases from ephemeral runners with copied-in connection strings.

The attacker needs an on-path position, so this is not a drive-by internet exploit. But a captured database password is a persistent credential: it keeps working after the attacker leaves the network. That is why the remediation below includes rotation, not just an upgrade.

How do you check if your project is exposed?

Work through these in order. Steps 1–2 tell you whether you install a vulnerable version; steps 3–4 tell you whether your configuration actually triggers each bug.

1. Find every resolved version of mariadb

# npm
npm ls mariadb --all

# pnpm
pnpm why mariadb

# yarn
yarn why mariadb

# Or read the lockfile directly
grep -A3 '"node_modules/mariadb"' package-lock.json | grep '"version"'

Any result below 3.2.4, or inside 3.3.0–3.3.2, 3.4.0–3.4.5, or 3.5.0–3.5.2, is affected. Check transitive paths too: ORMs, query builders and migration tools often pin their own copy.

2. Let the advisory feed confirm it

npm audit --audit-level=high

All three GHSAs are in the GitHub Advisory Database and OSV.dev, so npm audit, pnpm audit and any OSV-backed scanner should now report them. If your scanner is silent, its advisory mirror is stale.

3. Check your TLS configuration (CVE-2026-55215)

Grep your connection setup for ssl. You are exposed if TLS is enabled without a CA:

// EXPOSED on affected versions: no CA, fingerprint check runs after auth
const pool = mariadb.createPool({ host, user, password, ssl: true });

// NOT exposed to CVE-2026-55215: server identity verified before auth
const pool = mariadb.createPool({
  host, user, password,
  ssl: { ca: fs.readFileSync('/etc/ssl/certs/db-ca.pem') }
});

Connections over a local Unix socket, or over TLS with a proper CA and a verifying mode, are not affected by this vector.

4. Check auth plugins and charsets (CVE-2026-55854, CVE-2026-55855)

• PAM / dialog authentication over plain TCP? Exposed to CVE-2026-55854. TLS or a Unix socket closes it.
• charset set to big5, gbk, sjis, cp932 or gb18030 and Buffers passed as query parameters? Exposed to CVE-2026-55855. On utf8mb4 you are not.

What are the remediation steps?

1. Upgrade to the patched release on your branch: 3.2.x → 3.2.4, 3.3.x → 3.3.3, 3.4.x → 3.4.6, 3.5.x → 3.5.3 (currently tagged latest on npm). Regenerate the lockfile and confirm with npm ls mariadb --all.
2. Pin a CA certificate and use a verifying TLS mode (VERIFY_CA / VERIFY_FULL). This is the vendor's stated workaround if you can't upgrade today, and it's good hygiene regardless of version.
3. Rotate database passwords for any account that connected with ssl: true and no CA over a network you don't fully control. You can't prove nobody was on-path; a rotation costs minutes.
4. Restrict auth plugins with restrictedAuth so dialog can't be negotiated over an insecure transport, and stop using PAM over plain TCP.
5. Prefer server-side prepared statements (connection.execute()) for anything that binds untrusted Buffers. Binary-protocol parameters are sent out-of-band and never escaped into SQL text, which sidesteps the charset bug entirely.
6. Add a CI gate so a future downgrade or a new transitive pin can't quietly reintroduce an affected range.

Also disclosed the same day: 9router

If you self-host an LLM proxy, note two High advisories published 28 August for 9router (~35k weekly downloads): CVE-2026-55641 (a client-controlled Host: localhost header is treated as "local" and skips API-key auth on /v1, giving an unauthenticated open relay over your stored provider keys, plus SSRF via /v1/search) and CVE-2026-55638 (the /codex/* rewrite bypasses the same gate). Both are fixed in 0.5.2. 9router binds 0.0.0.0 by default, so anything below 0.5.2 that is reachable on its port should be upgraded now and the provider API keys rotated.

How does a registry firewall help with advisories like this?

Auditing after the fact works, but it depends on someone running the audit. A registry firewall moves the check to the one chokepoint every install goes through: the registry URL itself.

InstallSafe is a drop-in npm registry proxy. You point your package manager at it once:

npm config set registry https://r.installsafe.io

From then on, every npm install, pnpm install or yarn install, whether it's run by a developer, a CI runner, or an AI coding agent, resolves through the firewall. Package versions flagged in OSV.dev (which now includes all three mariadb GHSAs and both 9router ones) are refused at install time instead of landing in node_modules and waiting for the next audit. Clean versions are served byte-for-byte from npm, so builds don't change.

Two honest limits. First, InstallSafe blocks on advisory data, so a vulnerability is blocked once it is published to OSV, not at the moment a maintainer discovers it. For this incident that means from 28 August onward; a behavioural scanner like Socket or Aikido would not have caught a TLS ordering bug any earlier either, because there is no malicious code to detect. Second, a registry firewall can't fix a bad ssl config in your app; it stops the vulnerable package, and steps 2–5 above are still yours to do.

Want to know today, without changing anything? Run the free scan: upload a lockfile and it lists every package version in your tree that currently carries an OSV advisory, mariadb included.

FAQ

Is CVE-2026-55215 remotely exploitable from the internet?

No. The attacker must be on the network path between your app and the database (or control a server you connect to). It's a credential-disclosure bug, not remote code execution. The risk is that a captured password stays valid after the attacker is gone.

Which mariadb npm versions are safe?

3.2.4 or later on the 3.2 line, 3.3.3+, 3.4.6+, and 3.5.3+. The 3.5.3 release (June 2026) is the one currently tagged latest on npm.

I use ssl: true with a CA certificate. Am I affected?

Not by CVE-2026-55215: when a CA is provided, the server's identity is verified before authentication. You should still upgrade, because the other two advisories don't depend on your TLS setup.

Do I need to rotate my database password?

If any affected version ever connected with TLS-but-no-CA over a network you don't control, treat the password as potentially exposed and rotate it. If all connections were over a Unix socket or verified TLS, rotation is optional.

Does this affect the mysql2 package?

No. These advisories are specific to MariaDB Connector/Node.js (mariadb on npm). Other drivers have their own histories; check them separately.

Would InstallSafe have blocked this before 28 August?

No. InstallSafe blocks versions flagged in OSV.dev; the advisories were published on 28 August 2026, and that is when blocking started. Its value is that every install after that date, across every developer, runner and agent, is covered without anyone remembering to run an audit.

Sources: GitHub Advisory Database entries GHSA-cqhc-2h57-wpxf, GHSA-42r5-vhpq-m858, GHSA-g5xc-5w98-jfvm (all published 2026-08-28); MariaDB Connector/Node.js 3.5.3 release notes; CONJS-349. Download counts from the npm registry API for the week ending 2026-08-29.