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. -- 73, Ged. _______________________________________________ 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/
