Zimbra vs Carbonio. Co mówi analiza kodu o bezpieczeństwie obu systemów?

Kiedy administrator IT pyta nas, dlaczego warto migrować z Zimbry do Carbonio, zwykle odpowiadamy konkretami: polskie wsparcie producenta, brak utraty danych podczas migracji, kontrola nad infrastrukturą. Tym razem sprawdziliśmy coś innego. Nie opinie, nie deklaracje producentów, tylko surowe dane z publicznych repozytoriów kodu obu produktów.

Wynik jest bardziej jednoznaczny niż się spodziewaliśmy.

19,1x	7,5x	Jetty 12	0
commitów Carbonio wobec Zimbry (od początku 2026)	zmienionych linii kodu Carbonio wobec Zimbry (od początku 2026)	kontener serwletów Carbonio, Zimbra wciąż na Jetty 9.4	z przeanalizowanych CVE Zimbry 8.8.15 dociera do Carbonio

Metodologia, żeby nie było wątpliwości

Wszystkie liczby w tym artykule pochodzą z publicznych repozytoriów Git: 188 repozytoriów organizacji Zimbra i 126 organizacji Zextras, zmirrorowanych 18 sierpnia 2026. Wersje bibliotek trzecich odczytaliśmy bezpośrednio z plików definicji builda dołączonych do każdego wydania. Powiązania z CVE zweryfikowaliśmy krzyżowo z oficjalnymi advisory producentów oraz z bazą NIST National Vulnerability Database. Każde twierdzenie w tym artykule da się odtworzyć, uruchamiając te same zapytania na tych samych repozytoriach.

Najważniejsze odkrycie: podatność, która nie dotyczy Carbonio

Zacznijmy od najbardziej wymownego przypadku. CVE-2025-68645 to nieautoryzowane włączenie pliku lokalnego (Local File Inclusion) w filtrze RestFilter obsługującym endpointy klasycznego interfejsu Zimbry pod ścieżką /h/*. CISA umieściła tę podatność na liście aktywnie wykorzystywanych w atakach. Występuje w Zimbrze 8.8.15 i 9.0, czyli w wersjach wciąż najczęściej wdrożonych u klientów. Żadna z tych linii nie otrzyma już poprawki.

W Carbonio ten problem po prostu nie istnieje, nie dlatego, że podatność została załatana szybciej. Analiza kodu pokazuje, że Carbonio korzysta w tym obszarze z innej architektury niż Zimbra. Nie ma komponentu RestFilter ani endpointów /h/*, a klasyczny interfejs JSP, w którym znajdowała się podatność, nie został przeniesiony do nowej architektury. W efekcie nie istnieje kod tworzący ten wektor ataku, dlatego podatność obecna w Zimbrze nie występuje w Carbonio.

To najważniejsza różnica w całej analizie: przewaga Carbonio nie polega na tym, że łata szybciej. Polega na tym, że podatnego kodu często po prostu tam nie ma.

Tempo rozwoju: refaktoryzacja kontra nawarstwianie

Od 1 stycznia do 18 sierpnia 2026 w repozytoriach obu produktów:

Metryka	Zimbra	Carbonio	Różnica
Aktywne repozytoria	44	99	2,3x
Commity	342	6 525	19,1x
Zmienione pliki	2 570	9 869	3,8x
Dodane linie	348 407	1 712 429	4,9x
Usunięte linie	74 932	1 478 278	19,7x
Łącznie zmienionych linii	423 339	3 190 707	7,5x

Najciekawszy nie jest jednak żaden z tych mnożników, tylko stosunek dodanych linii do usuniętych. Zimbra dodaje 4,6 linii kodu na każdą usuniętą. Carbonio dodaje 1,2 linii na każdą usuniętą. Stosunek bliski jedności to sygnatura refaktoryzacji: istniejący kod jest przepisywany. Wysoki stosunek to sygnatura nawarstwiania: nowy kod dokłada się na niezmienionej podstawie.

Carbonio przebudowuje swoje komponenty. Zimbra dobudowuje wokół nich.

Warstwa technologiczna: Jetty jako najczytelniejszy sygnał

Jetty to warstwa HTTP, przez którą przechodzi każde żądanie do serwera pocztowego. Najnowsza publiczna zmiana Zimbry w tym komponencie (wydanie 10.1.12 z 2026 roku) aktualizuje go do wersji 9.4.57, czyli wydania serwisowego linii, której wsparcie społeczności zakończyło się cztery lata wcześniej. Carbonio działa na Jetty 12, aktualnej głównej linii.

Przestarzała warstwa HTTP nie otrzymuje poprawek bezpieczeństwa od twórców. Każda przyszła podatność musi zostać samodzielnie backportowana przez producenta albo pozostanie niezałatana.

Podobny obraz widać w pozostałych warstwach:

Warstwa	Zimbra	Carbonio
Kontener serwletów	Jetty 9.4.57 (koniec wsparcia w 2022)	Jetty 12
Środowisko Java	OpenJDK 17	OpenJDK 21 (Eclipse Temurin), o całą generację LTS dalej
Framework serwisowy	Klasyczny stos servlet + SOAP, Guice	Quarkus, Weld CDI + RESTEasy
Interop natywny	Wiązania JNI	Java FFM API, bez zależności od bibliotek natywnych
Podgląd i miniatury	Ścieżka servletowa w Javie	Przepisane w Go dla przepustowości
Edytor tekstu	TinyMCE 4.9.11, ostatnie wydanie wygasłej linii	Lexical 0.45.0, migracja zakończona w lipcu 2026
Biblioteki JS	YUI wciąż obecne w kliencie 8.8, wycofane przez twórców w 2014	Moduły oparte na React, brak wygasłych frameworków

Biblioteki firm trzecich: sześć komponentów poniżej wymaganej wersji

Producent Zimbry sam publikuje, jaka wersja poszczególnych bibliotek usuwa daną podatność. Porównanie z tym, co faktycznie jest wbudowane w kod, wygląda następująco:

Komponent	Zimbra 8.8	Zimbra 9.0	Carbonio	Wymagana wersja poprawki
PHP	7.4.27	8.3.0	nie występuje	8.3.0, CVE-2021-21708, CVSS 9,8
nginx	1.20.0	1.24.0	1.30.3	1.24.0, CVE-2022-41741
Apache httpd	2.4.57	2.4.57	nie występuje	2.4.62, CVE-2023-38709
OpenJDK	17.0.8	17.0.8	21.0.10	17.0.12, CVE-2023-22067
ClamAV	1.0.1	1.0.1	1.5.3	1.0.6 / 1.0.8, CVE-2024-20328, CVE-2025-20128
AntiSamy (sanityzacja HTML)	fork 1.5.8	fork 1.5.8	1.7.8	1.7.8, CVE-2025-66376, na liście CISA KEV

Sześć komponentów w linii 8.8 i cztery w linii 9.0 znajdują się poniżej wersji, którą sam producent wskazuje jako remediację. Carbonio w każdym wierszu jest na poziomie wymaganej poprawki albo dalej, a PHP w ogóle nie jest częścią jego stosu technologicznego.

Dlaczego te same podatności nie docierają do Carbonio

Porównaliśmy ostatnią łatkę Zimbry 8.8.15 (P47, listopad 2024, wsparcie zakończone 31 grudnia 2023, wciąż najczęściej wdrożona linia) z aktualną linią rozwojową Carbonio. Z 46 CVE, których poprawka nigdy nie dotarła do linii 8.8, 19 potwierdziliśmy bezpośrednio w kodzie źródłowym, w tym trzy oznaczone przez CISA jako aktywnie wykorzystywane w atakach. Żadna z nich nie dociera do Carbonio, z trzech możliwych powodów.

Powód pierwszy: podatny komponent nie istnieje w Carbonio. Dotyczy to m.in. wspomnianego CVE-2025-68645, ale też podatności w bibliotece PHP (CVE-2021-21708, CVSS 9,8, najwyższa pozycja na całej liście) i w edytorze TinyMCE (CVE-2024-38356). Carbonio nie ma tych komponentów w swoim stosie.

Powód drugi: Carbonio jest już poza wersją wymagającą poprawki. Dotyczy m.in. luk w ClamAV, nginx i OpenJDK, gdzie Carbonio wyprzedza wymaganą wersję remediacji, w przypadku JDK o całą generację LTS.

Powód trzeci: architektura, w której żyła podatność, została zastąpiona. Klasyczny interfejs JSP z wstrzykiwaniem przez atrybuty żądania już nie istnieje. Stos servletowy oparty na Guice zastąpiono usługami Quarkus z Weld CDI. Wiązania JNI zastąpiono przez Java FFM API, usuwając zależność od natywnych bibliotek współdzielonych. Każda z tych zmian usuwa nie jedną podatność, tylko całą ich klasę.

Podsumowanie

Na każdej mierzalnej z kodu osi, wersje środowiska uruchomieniowego, generacja frameworków, aktualność bibliotek firm trzecich, tempo rozwoju i obecność niezałatanego podatnego kodu, Carbonio jest platformą bardziej aktualną i aktywniej rozwijaną. Różnica jest największa dokładnie tam, gdzie ma to największe znaczenie dla ryzyka: warstwa HTTP, środowisko Java, sanityzacja HTML i silnik antywirusowy.

Przewaga Carbonio nie polega na szybszym łataniu. Polega na tym, że podatny kod często po prostu nie istnieje w jego stosie technologicznym.

---

Jeśli administrujesz środowiskiem Zimbra i zastanawiasz się, jak wygląda migracja do Carbonio w praktyce, w tym bez utraty danych i przestojów, porozmawiajmy. Jako jedyny autoryzowany dystrybutor Carbonio i Zextras w Polsce przeprowadziliśmy już dziesiątki takich migracji, od szpitali po instytucje publiczne i firmy produkcyjne.