zlib is one of the few pieces of third party C code inside sgcWebSockets. It powers the WebSocket permessage-deflate extension, so every compressed frame your server sends or receives passes through it, and it handles HTTP content encoding. sgcOpenAPI shares the same source, so it uses the same copy. As of 2026.8.0 that copy moves from zlib 1.2.12 to zlib 1.3.1.
The change is invisible in the API. Nothing in your code needs to be touched, and the compression behaviour is unchanged. What is worth explaining is why a version bump of a small C library is more than a file swap, and what we did to be sure it is safe on every compiler we support.
What 1.3.1 fixes, and why you were not exposed
The headline fix between 1.2.12 and 1.3.1 is CVE-2022-37434, a heap over-read in inflate(). It is only reachable when the calling application hands zlib a gz_header whose extra field points at a buffer. zlib then copies the gzip extra field into it, and in 1.2.12 that copy was missing a bounds check.
sgcWebSockets never met that condition. It calls inflateGetHeader only with a zero initialised gz_header, and it never assigns head.extra, so the affected branch could not be entered. We checked this in the source before deciding what to do, and we are stating it plainly: applications built with earlier versions were not vulnerable through this path.
We updated anyway. Version strings are what automated scanners and supplier questionnaires read, not call graphs, and a customer running a dependency scan should not have to reconstruct our reasoning to clear a finding. Upgrading ends the conversation instead of requiring it to be had repeatedly.
Why updating zlib is not a file swap
zlib is compiled into your executable rather than deployed as a DLL, which is why an sgcWebSockets application has no zlib1.dll next to it. That linking is done with precompiled object files, and Delphi is particular about their format. Updating zlib therefore means rebuilding those objects, and there is not one set but three.
| Used by | Format | Built with |
|---|---|---|
| Delphi 7 to XE | OMF | bcc32, ZEXPORT=__fastcall |
| XE2 and later, Win32 | OMF | bcc32, ZEXPORT=__cdecl |
| XE2 and later, Win64 | COFF | MSVC cl |
The two 32 bit sets differ in calling convention, because the older compilers link zlib with the Delphi register convention while XE2 and later use cdecl. The 64 bit set is a different object format again. It is worth noting that bcc64 cannot produce it, because it emits ELF objects and the Delphi Win64 linker wants COFF, so that set is built with the Microsoft compiler.
None of this is visible to you. It is simply the reason a zlib bump is a build exercise rather than a download.
Verified on every compiler, not just the newest
Rebuilt objects can compile cleanly and still be wrong, so a link test is not enough on its own. Every supported compiler was used to build and then run a program that compresses a buffer, decompresses it, compares it byte for byte, and asserts that the linked objects report the expected version.
uses
sgcIdCTypes, sgcIdGlobal, sgcIdZLibHeaders;
var
vPackedLen: TIdC_ULONG;
begin
vPackedLen := SizeOf(vPacked);
if compress(PIdAnsiChar(@vPacked[0]), vPackedLen,
PIdAnsiChar(@vSrc[0]), SizeOf(vSrc)) <> 0 then
raise Exception.Create('compress failed');
WriteLn('zlib ', String(AnsiString(zlibVersion))); // zlib 1.3.1
end;That ran on Delphi 7, Delphi 2007, Delphi 2009 and RAD Studio XE6 through 13, on Win32 and on Win64 where the platform exists. All 25 combinations pass and report 1.3.1.
A latent 64 bit bug fixed on the way
The matrix caught something that had nothing to do with the new version. On Delphi 10 Seattle, 64 bit builds were selecting the 32 bit objects, which cannot link into a 64 bit executable and produced a Bad object file format error. The cause was an old conditional meant to work around a Seattle specific problem, which routed that one combination to the wrong object set. Seattle 64 bit now uses the same objects as every other 64 bit target, and compiles.
sgcOpenAPI gets the same update
sgcOpenAPI shares its source with sgcWebSockets, zlib included, so it moves to 1.3.1 in the same release with no separate action from you.
What you need to do
Install 2026.8.0 and rebuild your projects. There is no property to set, no unit to add or remove, and no deployment change, because zlib was already inside your executable and still is. If you keep a software bill of materials for your own product, update the zlib entry to 1.3.1 and you can drop any CVE-2022-37434 note you were carrying.