Information on CVE-2026-85091

[carnil]

Hi

I'm not sure if you got notified about a new CVE assignment for zlib, originating from
https://gist.github.com/thesmartshadow/e0b9481792afb7c31e86fee1ff084490 . The
assigned CVE is CVE-2026-85091,

Was this reported to you?

Regards,
Salvatore

[BJD1999]

I have also got the notification from our vul system about this with high score.

[muralikrishna05]

Hi,
I asked Claude about CVE-2026-85091 and received a suggested patch.As I do not have expertise in this area, I have attached the patch for your review it to see if it helps?

CVE-2026-85091-zlib-gz_vacate.patch

[illia-imperva]

Would be nice to have a new release once this sorted

[manojkrgupta]

Looking forward to a release. Thanks

[theanwarshad]

I am also waiting for the fix for this issue

[dylan-ketel-ai]

For CVE-2026-85091, we independently checked Debian trixie's source 1:1.3.dfsg+really1.3.1-1 and amd64 binary 1:1.3.dfsg+really1.3.1-1+b1 using Debian's authenticated package indexes. This appears to be an affected-version classification issue for 1.3.1, separate from fixing the later non-blocking writer implementation.

• The Debian patch series is empty, and all five gz*.[ch] files match upstream v1.3.1 byte for byte. gz_vacate is absent from the entire extracted source.
• Commit 81cc0bebedd935daeb81b0b6e475d8786b51af3d, which adds gz_vacate and non-blocking handling, is not an ancestor of v1.3.1; it is included in v1.3.1.2 and v1.3.2.
• We also checked the older writer path rather than relying on the function name. In v1.3.1, gz_comp treats EAGAIN/EWOULDBLOCK as fatal Z_ERRNO; gzvprintf returns before its following memmove, and later write calls are rejected while the error remains. The retryable state->again/retained-input behavior needed for the reported stale-buffer path was added by commit 81cc0beb.
• The Debian archive binary is zlib1g_1.3.dfsg+really1.3.1-1+b1_amd64.deb, SHA256 015be740d6236ad114582dea500c1d907f29e16d6db00566ca32fb68d71ac90d. Its libz.so.1.3.1 SHA256 is 85590dd58edf5445e18bc7193e5ebc01ac5841f1ae187e97705a662e90c6421e.
• The authenticated source archive hashes are 60dd315c07f616887caa029408308a018ace66e3d142726a97db164b3b8f69fb (orig) and 9ed525955ce9fb0c1b39be8ff98f73450dbfc6305a9a27e6149c8972d38a0a9e (Debian packaging). The .dsc hash is ede2791e29c1d3b422f9208bdd7edf040c20445ea1e7453a72037576e64fa197, verified through the authenticated source index; separate .dsc signer verification is not claimed.

Debian's tracker currently labels trixie vulnerable, while the CVE description names 1.3.1.2–1.3.2. Could upstream confirm whether v1.3.1 is outside this CVE's affected range, or identify an earlier supported writer path that reaches the same stale-buffer overflow? That would help resolve the classification discussed in Debian bug1146895. We are preserving the existing finding pending vendor review rather than treating our assessment as accepted adjudication.

Public references: introducing commit, v1.3.1 gzip writer, Debian archive.

[chadlwilson]

This is a bit of a worry, if legit. This appears to have been yeeted into public with no fix available, via VulnCheck as CNA. It is unclear if @thesmartshadow responsibly disclosed months ago, and it was not responded to, or even if it has been validated by anyone independent of the researcher. The PR backlog seems a bit out of control.

In the meantime, a whole lot of "me too" messages are probably unhelpful. There is a "subscribe" button and you can watch for releases.

[thesmartshadow]

This is a bit of a worry, if legit. This appears to have been yeeted into public with no fix available, via VulnCheck as CNA. It is unclear if @thesmartshadow responsibly disclosed months ago, and it was not responded to, or even if it has been validated by anyone independent of the researcher. The PR backlog seems a bit out of control.

In the meantime, a whole lot of "me too" messages are probably unhelpful. There is a "subscribe" button and you can watch for releases.

I submitted this through the CNA first and intended to coordinate with upstream once the record was confirmed

I only realized it had already gone public after your notification reached me... The CNA publication notice had landed in spam
Glad to help with the fix if needed.

[chadlwilson]

I submitted this through the CNA first and intended to coordinate with upstream once the record was confirmed

I really don't think that this is the right way to do disclosure at all, and makes no sense - since you already made the POC public on your Github - even if it is a project with no obvious security policy.

You should be disclosing responsibly first for many reasons:

• to ensure the vuln is actually valid and confirmed as in-scope
• to communicate in private rather than via public GitHub docs
• to show that you value safety and prioritise remediation, not "credit"
• in case the project manages its own CVEs / disclosures
• to avoid reckless disclosure like this

... not going direct to whichever CNA you feel like and bypassing the relevant project. CNAs like VulnCheck or MITRE do no actual confirmation of vulns or coordination with projects, they appear to just take whatever at face value and will likely assume it's public already if you had already put something public on your GitHub. After which it gets picked up by other sources and creates a lot of noise.

Perhaps you can try and undo the damage by trying to co-ordinate with zlib@gzip.org or madler@alumni.caltech.edu (which I presume may get more attention than here, not sure) as I assume you were going to do...

[thesmartshadow]

I submitted this through the CNA first and intended to coordinate with upstream once the record was confirmed

I really don't think that this is the right way to do disclosure at all, and makes no sense - since you already made the POC public on your Github - even if it is a project with no obvious security policy.

You should be disclosing responsibly first for many reasons:

• to ensure the vuln is actually valid and confirmed as in-scope
• to communicate in private rather than via public GitHub docs
• to show that you value safety and prioritise remediation, not "credit"
• in case the project manages its own CVEs / disclosures
• to avoid reckless disclosure like this

... not going direct to whichever CNA you feel like and bypassing the relevant project. CNAs like VulnCheck or MITRE do no actual confirmation of vulns or coordination with projects, they appear to just take whatever at face value and will likely assume it's public already if you had already put something public on your GitHub. After which it gets picked up by other sources and creates a lot of noise.

Perhaps you can try and undo the damage by trying to co-ordinate with zlib@gzip.org or madler@alumni.caltech.edu (which I presume may get more attention than here, not sure) as I assume you were going to do...

The disclosure sequence was my mistake and I should have contacted upstream before making the report public

But the suggestion that this was about credit is not accurate

My goal was to get the issue tracked and fixed not to bypass zlib

I will contact zlib@gzip.org and Mark directly now and coordinate validation and a fix as quickly as possible

[chadlwilson]

My goal was to get the issue tracked and fixed not to bypass zlib

If you say so; but "intended to coordinate with upstream once the record was confirmed" looks a lot like intentional "bypass" to the normal reader.

Anyway, whether it's valid or not, if I were you I'd probably contact the CNA to withdraw the CVE until then.