Re: BackupPC-XS zlib vulnerability

On 1/18/26 9:32 AM, G.W. Haywood wrote:
> Hi there,
>
> On Sat, 17 Jan 2026, jbk wrote:
>
>> ... thoughts / questions on the zlib CVE.
>
> Can we be specific about which CVE?
>
>> There are two path's of vulnerability for the BackupPC server.  One
>> is the distro installed zlib and the other is the zlib bundled in
>> BackupPC to date.
>
> Assuming that you're restricting your consideration of vulnerabilities
> to those in zlib and the zlib bundled by BackupPC, then yes. Although
> the subject is "BackupPC-XS ...", to date not only BackupPC-XS but the
> original rsync and rsync-bpc *also* bundle zlib.  So, I gather, do a
> number of other packages.  As far as rsync-bpc is concerned I'm in the
> midst of dealing with it - see below.
>
>> The distro installed zlib supposedly will be patched soon, not as of
>> yet.  Anyone who has access to this server could avail themselves of
>> the vulnerability till it is patched.
>
> Are all the big distros not all up to speed with zlib patches? That
> may beg the questions (a) which distro? and (b) to whom do you permit
> what kinds of access to your backup server?
>
>> Once it is patched then the only users who have access to the
>> bundled zlib are those trusted BackupPC admin users.  The client
>> users shouldn't have direct access to the bundled zlib, correct?
>
> I'm not sure that I follow.
>
> To make use of flaws in the bundled zlib library, direct access to the
> bundled library is not a requirement.  If (and *only* if) (1) BackupPC
> is linked with the vulnerable library and (2) there's some way for an
> attacker to get a vulnerable function called, all the attacker must do
> is somehow arrange for BackupPC to pipe through zlib data which our
> attacker has somehow contrived to cause BackupPC to make a call to the
> vulnerable function (and for this call to do something of use to the
> attacker, but that's his problem).
>
> In the case of BackupPC I'm not sure how easy it would be to arrange
> for these conditions to be met, but it could theoretically be achieved
> by getting BackupPC to back up or recover a crafted file.  (If users
> can e.g. run a compiler on the server they can alternatively download
> vulnerable code (any vulnerable code, not just zlib) and build it.
> Then they can do what they like with it.  I've done that for example
> to hack into a Debian box when the owner forgot the root password.
>
>> Just trying to get an idea of the risk level for the bundled zlib.
>
> In my view, if you're running a vulnerable zlib it's low if you're
> (otherwise) sane - but since compiling the bundled zlib in the first
> place is optional, avoiding the risk seems trivial.
>
> FWIW I think I'm very close to releasing rsync-bpc version 3.4.1.0rc1,
> which is hopefully going to put this one to bed at last for BackupPC.
> The new version will use both the system zlib and the system popt and
> will bundle neither.
>
The CVE is https://www.cve.org/CVERecord?id=CVE-2026-22184 and marked 
disputed. See also

https://www.openwall.com/lists/oss-security/2026/01/06/5

This was patched very quickly by some distributions even though the 
problem is not in zlib.  This is a bug in a *contibuted reference 
program* demonstrating how to use zlib. This is not a problem in zlib 
itself.

See the thread at https://github.com/madler/zlib/issues/1142

_______________________________________________
BackupPC-users mailing list
[email protected]
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/