I understand this this is failing CI/CD and all... but we are stuck with our packages failing on vulnerabilities with this fix. What is the ETA for getting this merged?

I find it strange that a fix has been available for days while this vunerability is already breaking pipelines across the ecosystem.

Meanwhile this seems stuck in process overhead :(

@zhangskz can you please release a new version with this security fix?

I can't express how absurd this whole situation is.

Please, next time have a release ready before approving a CVE. I don't know who made this obvious mistake, but you've annoyed a lot of people that care about security. Just leave the report there forever instead of making the thing public.

Any update on this?

pip-audit has now started to fail "out in the world" for things that use protobuf, which will probably cause many pipelines out there to fail.

Just to share while waiting on the new protobuf package release, you can use pip-audit with --ignore-vuln CVE-2026-0994 to remediate pipelines in the near term

Protobuf team member jumping in here.

Please, next time have a release ready before approving a CVE. I don't know who made this obvious mistake, but you've annoyed a lot of people that care about security. Just leave the report there forever instead of making the thing public.

Yes, this was definitely mistake and we'll be tightening up our process to avoid this from happening in the future.

Just for 'how the sausage is made' normally our internal CVE process is so slow that we can open our internal process request to create a CVE and it just inherently takes long enough that we can start that process as soon as we decide a CVE is warranted and it takes longer for that process than it does for us to patch the issue and release the patches.

What went 'wrong' in this case is the internal process surprisingly managed to move fast instead (which should be a good thing), but because it normally is slow we didn't have the proper process for it that to be gated on the patches being released (which is definitely a bad thing).

Sorry for our process failure negatively affecting folks here. Given the CVE is already published now, we'll try to move fast for these patches.

Thanks @paulhodson , that is a useful tip for future

@aviralgarg05 @ankitsinha-cmyk @anandolee Is there any plans to bring this to version 4.25.x? We run a cloud function which depends on this version and updating will cause backwards incompatibility with other library versions as well for our customers. Thanks!

@aviralgarg05 @ankitsinha-cmyk @anandolee Is there any plans to bring this to version 4.25.x? We run a cloud function which depends on this version and updating will cause backwards incompatibility with other library versions as well for our customers. Thanks!

Any update on above? Thanks!

We don't plan to backport to 4.25 as Py 4.x has has been end of lifed for a year (after a year of high prio fixes only). See the chart here:
https://protobuf.dev/support/version-support/#:~:text=TBD-,Release%20support%20chart,-Protobuf%20Python

The 25.x line is still specially maintenance support just for Java (so the same issue happening in Java would get a backport by contrast).

Note that we're even in the final quarter of official high prio backports only for Py 5.x, so 4.x is getting quite behind the version treadmill here.

Note that the breaking changes across this version boundaries are intentionally minor/obscure including that old gencode is still compatible, as described here:
https://protobuf.dev/support/cross-version-runtime-guarantee/#:~:text=minor%2C%20or%20micro).-,Python%2Dspecific%20Guarantees,-Since%20the%203.20.0

So we expect it should be rare that anyone should not be able to upgrade past these major version numbers without changing their application code at all.

We don't plan to backport to 4.25 as Py 4.x has has been end of lifed for a year (after a year of high prio fixes only). See the chart here: https://protobuf.dev/support/version-support/#:~:text=TBD-,Release%20support%20chart,-Protobuf%20Python

The 25.x line is still specially maintenance support just for Java (so the same issue happening in Java would get a backport by contrast).

Note that we're even in the final quarter of official high prio backports only for Py 5.x, so 4.x is getting quite behind the version treadmill here.

Note that the breaking changes across this version boundaries are intentionally minor/obscure including that old gencode is still compatible, as described here: https://protobuf.dev/support/cross-version-runtime-guarantee/#:~:text=minor%2C%20or%20micro).-,Python%2Dspecific%20Guarantees,-Since%20the%203.20.0

So we expect it should be rare that anyone should not be able to upgrade past these major version numbers without changing their application code at all.

Thanks! We have other dependencies that will break such as google-cloud-sdk libs (https://github.com/observeinc/google-cloud-functions/blob/main/requirements.txt#L48)

@sfc-gh-ndua I don't want to tell you how to manage your dependencies, but all of the Google Cloud packages you have are apparently pinned to versions from around 2023. But they're all actively maintained and have had many releases since then, which are presumably compatible with protobuf v5+. So you could just upgrade them...?

Speaking authoritatively for Protobuf project: it does looking to me that cloud-sdk libs are stuck behind here (at least for their default set version, unclear about true-compatibility) and they is one of our biggest Google library usages. We'll follow up on that internally to see why its still stuck.

Broadly we also know being 3 years behind on some deps is also relatively normal for lots of projects; we are just trying to thread the needle on being able to make changes that keep Protobuf healthy while still avoiding breaking people; there's unfortunately a direct tension where total stability (which we did for a while) makes things stagnant on all axes which ends up slowly building up over time to harm.

We do try very hard to keep the breaking changes obscure to avoid people's difficulties upgrading. We had made some missteps with our last Java breaking change, which is partially why it has an extended support window, so we also know that even smaller seeming breaks can cause big problems for some customers.

We are likely to do a 25 release for an unrelated Java issue; depending on the state of Cloud SDK and difficulty in releasing the backport we may consider backporting this thing to Py 4.x as well even though its officially end of life (but no promises here).

Thanks!