Personal blog of Yzmir Ramirez

Upstream MySQL published an out-of-schedule release this week with two high-severity CVE fixes. If you’re running Percona Server for MySQL 5.7 or 8.0 under Extended Lifecycle Support (ELS), the program we previously called Post EOL Support, you don’t have to do anything to qualify for them. We’ve already applied the fixes and re-released the affected ELS builds.

This is the point of ELS. When a major version reaches End of Life (EOL), the community stops shipping patches, but the databases running on it don’t stop mattering. ELS keeps critical bug and security fixes coming for versions that are past their EOL date, so you can stay on 5.7 or 8.0 on your own timeline instead of a deadline someone else set.

What we did

These CVE fixes landed upstream outside the normal cadence. Under ELS, customers are entitled to security fixes for the versions they run, so we pulled the patches into the 5.7 and 8.0 builds and re-released them. ELS customers will get access to the updated builds from the usual private repository in the next couple of weeks.

Why this matters if you’re still on 5.7 or 8.0

Percona Server for MySQL 5.7 reached EOL in October 2023. Percona Server for MySQL 8.0 reached EOL in April 2026. Plenty of production systems are still on both, and not every migration can happen on the upstream’s schedule. Running an unpatched database past EOL is where the real risk sits: no security fixes, no bug fixes, and no support when something breaks at 2:00 a.m.

ELS closes that gap. You keep getting the critical fixes, including out-of-schedule security patches like these, while you plan an upgrade on terms that work for your team.

Where to go from here

If you’re on 5.7 or 8.0 and don’t have ELS in place, now is a good time to look at it. The fixes we just shipped are exactly what the program is for. See the details for your version: Extended Lifecycle Support for MySQL 8.0 or Extended Lifecycle Support for MySQL 5.7. Or reach out via percona.com or the Percona Community Forum to discuss coverage for your environment.

 

---

Written by @Dennis Kittrell – Reviewed by @Matthew Boehm & @Varun Nagaraju

The post Still on MySQL 5.7 or 8.0? Those high-severity CVE fixes are covered appeared first on Percona.

TL;DR: This advisory covers the two most important high-severity memory-safety vulnerabilities affecting MongoDB Community and our downstream Percona Server for MongoDB – CVE-2026-11933 and CVE-2026-9740. Both will be addressed in a single coordinated patch release, bundled with other recently revealed lower-scored CVE fixes: CVE-2026-9753, CVE-2026-9752, CVE-2026-9751, CVE-2026-9750, CVE-2026-9749, CVE-2026-9748, CVE-2026-9747, CVE-2026-9746, CVE-2026-9743, and CVE-2026-9741.

Fixes land in Percona Server for MongoDB patch window starting next week. The first high-vulnerability issue has nothing between it and your mongod process except your firewall. The second has a configuration off-switch you can flip during a maintenance window.  Read on to understand why, how, and what.

CVE-2026-9740 — the one that does not need credentials

A stack overflow in the BSON validator, specifically in the BSONColumn interleaved-reference handling. The validator’s depth tracking resets on mutual recursion between validation functions, so a sufficiently nested input exhausts the thread’s stack before any explicit limit fires. The result: mongod crashes.

CVSS 8.7. High severity. The reason it lands in High instead of merely Medium is the prerequisite for exploitation – there is none.

The attacker needs network reachability to a mongod listener. No credentials, no prior session, and no application interaction. One crafted message over the wire and the process is down. Repeated crashes are trivially repeatable, so an attacker who can reach the port can keep the instance offline for as long as they keep that reachability. The urgency of this issue comes from the audience – everyone with a TCP route to your database.

Upstream tracking: SERVER-125063. Affected versions are Percona Server for MongoDB 8.0 ? 8.0.23-10 and PSMDB 7.0 ? 7.0.34-19. The vulnerable BSONColumn code path was introduced in 7.0, so 6.0 and earlier are not in scope for this one.

CVE-2026-11933 — the one that does need credentials and permissions to read

The vulnerable code path is inside MongoDB Server’s server-side JavaScript engine, specifically in the BSON-to-array conversion routine. When a BSON document is materialized as a JavaScript array for use inside a server-side script, the engine can reach a state where it accesses memory that has already been freed. An attacker who can submit input that flows into that conversion path can shape what happens at the point of access.

Server-side JavaScript is reachable from the following surfaces:

1. The $where query operator (deprecated in 8.0).
2. The $function aggregation expression (deprecated in 8.0).
3. The $accumulator aggregation expression (deprecated in 8.0).
4. The mapReduce command (deprecated since 5.0).
5. JavaScript functions stored in system.js.

MongoDB logs a warning when you run deprecated functions.

Prerequisites for exploitation:

1. The attacker must be authenticated to MongoDB.
2. The attacker must hold any role that permits running queries or aggregations against a collection. The built-in read role on a single database is sufficient.
3. Server-side JavaScript must be enabled on the mongod instance. This is the default; many production deployments leave it enabled even when they do not use it.

CVSS 8.8. High severity. Two demonstrated outcomes:

• Information disclosure (reading other content out of the mongod process memory) and
• Denial of Service (crashing it).

Upstream tracking: SERVER-128125. Affected versions: every supported and End of Life Percona Server for MongoDB major from 4.4 through 8.0.

The good news and bad news

CVE-2026-11933 has a configuration off-switch. If your application does not use server-side JavaScript — $where, $function, $accumulator, mapReduce, or stored system.js functions — you can disable server-side JavaScript on the server, removing the attack surface entirely until you patch.

How to check whether your applications use server-side JavaScript before disabling:

1. Enable MongoDB profiling at level 2 (all operations) on a representative mongod server for a representative time window. See details in Manage the database profiler.
2. Search the system.profile collection for operations that include $where, $function, $accumulator, or mapReduce.
3. Inspect application code paths and stored aggregation pipelines for the same operators. Check system.js in each database for stored functions.
4. If any usage exists, treat disabling as not viable for those deployments and rely on patching plus the defense-in-depth controls below.

How to disable server-side JavaScript:

Add to your configuration file for mongodand mongos:

security: 
  javascriptEnabled: false

Or pass --noscripting on the command line. See the reference documentation for details about MongoDB Setting:  security.javascriptEnabled.

After a restart, any operation that reaches for server-side JavaScript will return an error. That is the catch: if your application does use one of those operators, this is not a viable mitigation for you, and you have to wait for the patch. If you are not sure whether your application uses them, turn on the database profiler at level 2 on a representative replica for a window long enough to be representative, then grep the profile collection for the operator names. Several teams have done this exercise in the last forty-eight hours and learned the answer is “no, we don’t actually use any of that.” The cost of disabling is then the cost of a mongod or mongos restart.

That was good news. Now the bad news: CVE-2026-9740 has no equivalent off-switch. The BSON validator is core to every client message; it cannot be disabled. Patch and network controls are the only options.

What is shipping, and when

The fixes for both CVEs will land in a single coordinated patch release for each supported major:

• Percona Server for MongoDB 7.0 series — fix targeted for  June 23, 2026.
• Percona Server for MongoDB 8.0 series — fix targeted for  June 25, 2026.
• Percona Server for MongoDB 6.0 series — fix targeted for  June 25, 2026 (for CVE-2026-11933).

All dates are targets, not commitments. Plan one upgrade window covering all CVEs.

Percona is not building binary packages for the 5.x line. We’re being upfront about that — the calculus on extended support has a limit, and 5.x is past it for us. If you have a hard requirement on 5.x and the time pressure to meet it, the source is available for building. Percona customers on 5.x can open a ticket, and we’ll work on the case individually.

As usual, you can download patches from your package manager or Percona Software Downloads page.

On Kubernetes via the Percona Operator for MongoDB: same drill as usual. When the patched image is published, edit the image tag in your PerconaServerMongoDB custom resource and let the operator roll the cluster. Don’t wait for the June operator release to do it for you. See details in our documentation on how to Upgrade Percona Server for MongoDB. You do not need to wait for an operator release to apply a security fix.

What to do this week

In order of urgency, for most deployments:

1. Confirm your mongod or mongos listeners are not reachable from any source you would not trust with a shell on the host. If you find an exposure, fix that first. CVE-2026-9740 turns any such exposure into a DoS primitive.
2. For deployments that do not use server-side JavaScript, disable it. Full mitigation for CVE-2026-11933 within a single mongod restart.
3. Plan your upgrade window for the week the relevant fixed release lands. One window. Both CVEs. Plus, the others scored lower.
4. Audit which roles in your deployment can run ad-hoc queries or aggregations. The bar for CVE-2026-11933 is the standard read role, so the population of potential attackers is larger than for most memory-safety defects.

One closing point, because it has come up several times in customer conversations this week. For a deployment behind tight network controls, the post-authenticated bug is the more urgent one. For a deployment reachable from broader networks — public cloud, shared internal LANs, multi-tenant infrastructure — the pre-authenticated bug is. Triage by your exposure, not by their CVSS.

---

Questions, or a deployment you’re not sure how to triage? Find us on the Percona Forum, or, for customers, in the support portal.

Reviewed by Ivan Groenewold. Vetted for technical accuracy as of June 17, 2026.

The post Security advisory: CVE-2026-9740 and CVE-2026-11933 in Percona Server for MongoDB appeared first on Percona.

TL;DR: A bug in MongoDB’s time-series collection code allows a user with the standard readWrite
role to corrupt memory within the mongod process. Best case: your database crashes, and you spend the night writing a postmortem. Worst case: an attacker is running their code as mongod, with the same access to your data that the database process itself has — every collection on that node, every index, every secret stored in it. The patch for Percona Server for MongoDB 7.0 is already available; 8.0 will be available tomorrow, and 6.0 will be available early next week.

Every time a bug like this lands, the same conversation plays out in incident channels across the industry. Are we affected? We don’t even use time-series collections! Heads nod. Everyone moves on.

That’s the mistake.

CVE-2026-8053 is an out-of-bounds memory write in MongoDB’s time-series collection — specifically in the internal mapping between measurement field names and column indexes. Under the right input, the mapping drifts out of sync with the underlying buffer and mongod writes off the end of an allocation. From there, under the right conditions, you can execute arbitrary code as the database process.

Upstream tracking lives at SERVER-126021. CVSS v3.1 puts it at 8.8. CVSS v4.0 puts it at 8.7. The labels say “High.” How that “High” translates into your week depends on a couple of assumptions worth questioning.

Read literally, the prerequisite is “an authenticated user with database write privileges.” Read operationally, that bar is lower than most teams treat it as.

The mitigation you think you have doesn’t exist

Modern stacks have dozens of service accounts, with secrets scattered across config files, pipelines, and laptops you’ve long forgotten about. Others end up in log files on bad days. And every user with write access to your cluster sits one step away from the vulnerable code path. In a world like that, “the attacker would need credentials first” isn’t a speed bump — it’s a shrug.

So the real question was never authenticated vs. unauthenticated. It’s what authentication unlocks. Here, it unlocks Remote Code Execution (RCE), which is exactly what the CVSS score is trying to tell you — even if the industry’s reaction hasn’t quite caught up. Attackers don’t need your time-series collection to already exist – they just need someone’s credentials in the wrong hands, and there are more ways for that to happen than most teams want to admit.

I’m not raising this to be smug. I’m raising it because too many incident channels keep stalling on the wrong question. It isn’t: “Does our app use time-series?” It’s: “What can a user holding our readWrite role actually do this week?”

Until you patch, the answer is more than you think.

What Percona is shipping, and when?

• Percona Server for MongoDB 7.0.34-19 — May 20, 2026
• Percona Server for MongoDB 8.0.23-10 — May 21, 2026
• Percona Server for MongoDB 6.0.28-22 — May 25, 2026

6.0 is on the End-Of-Life (EOL) track. The easy call would be to point at the lifecycle page, note that the upgrade conversation is overdue, and stop there. We’re shipping the fix anyway. Customers running 6.0 in production have real reasons they haven’t migrated yet — frozen application stacks, certification cycles, dependencies that don’t move on quarterly cadences — and none of those reasons are worth exploiting while a migration plan gets approved.

Percona is not building binary packages for the 5.x line. We’re being upfront about that — the calculus on extended support has a limit, and 5.x is past it for us. But the fix itself is already in our public release branch: release-5.0.33-26. If you have a hard requirement on 5.x and the time pressure to meet it, the source is available for building. Percona customers on 5.x can open a ticket, and we’ll work on the case individually.

What to do this week?

Patch! Specifically:

• If you’re on 7.0, upgrade to 7.0.34-19 from May 20 onward.
• If you’re on 8.0, upgrade to 8.0.23-10 from May 21 onward.
• If you’re on 6.0, upgrade to 6.0.28-22 from May 25 onward.
• If you’re on 5.0 and you can’t move, build from release-5.0.33-26. Customers — open a ticket and we’ll help.

As usual, you can download patches from your package manager or Percona Software Downloads page.

If you’re running PSMDB on Kubernetes via the Percona Operator for MongoDB, edit the image tag in your PerconaServerMongoDB custom resource and let the operator roll the cluster. Don’t wait for the June operator release to do it for you. See details in our documentation on how to Upgrade Percona Server for MongoDB.

While you’re in there, audit your custom roles. Anything granting createCollection on a production database is, today, an RCE primitive in waiting. Decide whether the service accounts that hold it actually need it. Decide whether your application users need full readWrite or whether a narrower role would do the same job. Treat the answer as part of your security posture, not as a quarterly cleanup task you’ll get to.

Questions, sharp disagreements, or a 5.x build that won’t compile? Find us on the Percona Forum or, if you’re a customer, in your support portal. If you want to become one and ensure your databases run, check out Percona Services.

The post CVE-2026-8053: “We don’t use time-series” is not a mitigation appeared first on Percona.

A series of vulnerabilities has been identified that affect all versions of Valkey. Below is the summary of each vulnerability: The patches for these CVEs had been released in newer versions of valkey-server and valkey-bloom. Please consider upgrading to these versions as soon as possible: valkey-server 9.0.3 valkey-server 8.1.6 valkey-server 8.0.7 valkey-server 7.2.12 valkey-bloom 1.0.1 […]

A critical security vulnerability has been identified in the following software that Percona has made available and that you may be using:  PMM 3.x installations (that is, 3.0 and forward). The Common Vulnerabilities and Exposures (CVE) identifier for this issue is on request from mitre.org. Vulnerability details We were notified via an external report that […]

A vulnerability has been discovered in all versions of Percona Monitoring and Management (PMM). There is no evidence this vulnerability has been exploited in the wild, and no customer data has been exposed. Vulnerability details This vulnerability stems from the way PMM handles input for MySQL services and agent actions. By abusing specific API endpoints, […]

A critical security vulnerability has been identified in the following software that Percona has made available: PMM Open Virtual Appliance (OVA) installations, version 2.38 and above. This vulnerability does not extend to Docker or Amazon Machine Images (AMIs). The Common Vulnerabilities and Exposures (CVE) identifier for this issue has been requested from mitre.org. Immediate actions […]

On May 30, Percona was notified of a possible vulnerability in Percona Monitoring and Management (PMM). After researching the report, we agreed with the reporter and began working on a fix to address the issue. Today we’re releasing PMM 2.37.1 with a fix for CVE-2023-34409 that addresses the PMM authentication bypass vulnerability. This release contains no other features or fixes. We advise users to upgrade PMM at the earliest opportunity, particularly if the PMM instance is accessible directly from the Internet.

All versions of PMM starting with 2.0.0 are assumed to be vulnerable.

In prior versions of PMM, the authenticate function would strip parts of a URL separated by a dot or slash until it found a matching pattern in its ruleset. This could allow an attacker to feed a malformed URL to PMM to bypass authentication and access PMM logs. In turn, this could allow information disclosure and privilege escalation.

If you are able to update, follow the standard instructions to upgrade PMM.

If you are unable to perform an update, it is possible to mitigate this issue by making a change to the NGINX configuration on the running PMM instance. To do so, create a Bash script with the code from this script on GitHub.

Then, you can apply the code using this docker command on a server running the PMM Docker container (as root or using sudo):

docker exec -it pmm-server bash -c 'curl -fsSL https://raw.githubusercontent.com/percona/pmm/main/scripts/authfix.sh  | /bin/bash'

If you are running PMM via a virtual appliance (OVF or AMI), use SSH to shell into the PMM server and run this command, as root or using sudo:

curl -fsSL https://raw.githubusercontent.com/percona/pmm/main/scripts/authfix.sh  | /bin/bash

We’d like to thank Adam Kues, security researcher at Assetnote, for the vulnerability report. We deeply appreciate all community security and bug reports that help us identify and fix issues in Percona software. If you believe you’ve identified a security issue, see the Percona Security page for reporting procedures, our security policies, and the Responsible Disclosure program.