zlib es una de las pocas piezas de código C de terceros que hay dentro de sgcWebSockets. Es la base de la extensión WebSocket permessage-deflate, así que cada trama comprimida que su servidor envía o recibe pasa por ella, y también se encarga de la codificación de contenido HTTP. sgcOpenAPI comparte el mismo código fuente, por lo que utiliza la misma copia. A partir de 2026.8.0 esa copia pasa de zlib 1.2.12 a zlib 1.3.1.
El cambio es invisible en la API. No hay que tocar nada en su código, y el comportamiento de la compresión no varía. Lo que sí merece una explicación es por qué subir de versión una pequeña librería en C es algo más que cambiar un archivo, y qué hicimos para asegurarnos de que es seguro en todos los compiladores que soportamos.
Qué corrige 1.3.1, y por qué usted no estaba expuesto
La corrección más destacada entre 1.2.12 y 1.3.1 es CVE-2022-37434, una lectura fuera de límites en el heap dentro de inflate(). Solo es alcanzable cuando la aplicación que llama entrega a zlib un gz_header cuyo campo extra apunta a un búfer. zlib copia entonces el campo extra de gzip en él, y en 1.2.12 a esa copia le faltaba una comprobación de límites.
sgcWebSockets nunca cumplió esa condición. Llama a inflateGetHeader únicamente con un gz_header inicializado a cero, y nunca asigna head.extra, por lo que no se podía entrar en la rama afectada. Lo comprobamos en el código fuente antes de decidir qué hacer, y lo decimos con claridad: las aplicaciones compiladas con versiones anteriores no eran vulnerables por esta vía.
Aun así actualizamos. Lo que leen los escáneres automáticos y los cuestionarios de proveedores son las cadenas de versión, no los grafos de llamadas, y un cliente que ejecuta un análisis de dependencias no debería tener que reconstruir nuestro razonamiento para descartar un hallazgo. Actualizar zanja la conversación en lugar de obligar a repetirla una y otra vez.
Por qué actualizar zlib no es cambiar un archivo
zlib se compila dentro de su ejecutable en lugar de distribuirse como una DLL, y por eso una aplicación sgcWebSockets no lleva ningún zlib1.dll al lado. Ese enlazado se hace con archivos objeto precompilados, y Delphi es muy exigente con su formato. Actualizar zlib implica por tanto reconstruir esos objetos, y no hay un conjunto sino tres.
| Usado por | Formato | Compilado con |
|---|---|---|
| Delphi 7 hasta XE | OMF | bcc32, ZEXPORT=__fastcall |
| XE2 y posteriores, Win32 | OMF | bcc32, ZEXPORT=__cdecl |
| XE2 y posteriores, Win64 | COFF | MSVC cl |
Los dos conjuntos de 32 bits se diferencian en la convención de llamada, porque los compiladores más antiguos enlazan zlib con la convención de registros de Delphi mientras que XE2 y posteriores usan cdecl. El conjunto de 64 bits es, además, un formato de objeto distinto. Conviene señalar que bcc64 no puede generarlo, porque emite objetos ELF y el enlazador Win64 de Delphi quiere COFF, así que ese conjunto se compila con el compilador de Microsoft.
Nada de esto es visible para usted. Es sencillamente la razón por la que subir la versión de zlib es un ejercicio de compilación y no una descarga.
Verificado en todos los compiladores, no solo en el más reciente
Unos objetos reconstruidos pueden compilar sin errores y aun así ser incorrectos, de modo que una prueba de enlazado no basta por sí sola. Con cada compilador soportado se compiló y después se ejecutó un programa que comprime un búfer, lo descomprime, lo compara byte a byte y verifica que los objetos enlazados informan de la versión esperada.
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;Eso se ejecutó en Delphi 7, Delphi 2007, Delphi 2009 y RAD Studio XE6 hasta 13, en Win32 y en Win64 donde la plataforma existe. Las 25 combinaciones pasan la prueba e informan de 1.3.1.
Un error latente de 64 bits corregido por el camino
La matriz detectó algo que no tenía nada que ver con la nueva versión. En Delphi 10 Seattle, las compilaciones de 64 bits estaban seleccionando los objetos de 32 bits, que no pueden enlazarse en un ejecutable de 64 bits y producían un error Bad object file format. La causa era una condicional antigua pensada para sortear un problema específico de Seattle, que dirigía esa única combinación al conjunto de objetos equivocado. Seattle de 64 bits usa ahora los mismos objetos que cualquier otro destino de 64 bits, y compila.
sgcOpenAPI recibe la misma actualización
sgcOpenAPI comparte su código fuente con sgcWebSockets, zlib incluido, así que pasa a 1.3.1 en la misma versión sin ninguna acción adicional por su parte.
Qué tiene que hacer
Instale 2026.8.0 y recompile sus proyectos. No hay ninguna propiedad que configurar, ninguna unidad que añadir o quitar y ningún cambio de despliegue, porque zlib ya estaba dentro de su ejecutable y sigue estándolo. Si mantiene una lista de materiales de software para su propio producto, actualice la entrada de zlib a 1.3.1 y podrá eliminar cualquier nota sobre CVE-2022-37434 que estuviera arrastrando.