According to
"zlib before 1.2.12 allows memory corruption when deflating (i.e., when compressing) if the input has many distant matches."
In my understanding of T5880 , the build data for windows will have to be updated to 1.2.12
and a new Gpg4win release seems prudent.
Not in the way it is used by gpg. See T5880
Okay, I understand that no external data is run directly through the part of zlib with the defect and thus there is no way to construct input to that functions of zlib that have the problem.
Thanks for the clarification, I admit that I was not clear about this from reading T5880.
In any way, the existence of this issue is good, because we can refer people to it, who have the same question. Some might even find it by themselves.
(Werner just told me that I was mistaken and he needs to take a look. There was a mixup because of the 2018 CVE number.)
The fix is from 2018 but was not picked up widely; see
https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531
Given that at this is a compression only bug the input data to GnuPG should in most cases be controlled by the user and is thus known. Thus the severity of this bug for attended use cases is not high but we need to fix it anyway.