A NowSecure scan reports **Components with Known Vulnerabilities** for `libz.1.dylib` (`zlib` `1.2.12`) in our iOS app binary built with Firebase iOS SDK.

[MuraliSaiTummala]

A NowSecure scan reports Components with Known Vulnerabilities for libz.1.dylib (zlib 1.2.12) in our iOS app binary built with Firebase iOS SDK.

What we are seeing

• Finding ID: 3246948
• Library: libz.1.dylib
• Version: 1.2.12
• CPE: cpe:2.3:a:zlib:zlib:1.2.12:*:*:*:*:*:*:*
• Total CVEs detected: 4
• Highest CVSS: 9.8
• Scanner category: Code Quality, App Store Blocker
• Status: Detected

CVEs reported by scanner:

• CVE-2022-37434 (9.8)
• CVE-2023-45853 (9.8)
• CVE-2026-22184 (7.8)
• CVE-2026-27171 (5.5)

Environment

• Firebase iOS SDK: latest
• Xcode: 26.6
• Installation method: Swift Package Manager
• Platform: iOS
• Build config: Release

Question / help needed

Please help confirm:

1. Is libz.1.dylib/zlib in this case introduced by Firebase SDK (directly or transitively), or by Apple toolchain/runtime packaging?
2. Is there a recommended mitigation/remediation for this finding when using latest Firebase SDK?
3. If this is not actionable from Firebase side, can you share official guidance we can use for AppSec exception documentation?

Repro

1. Build iOS app with latest Firebase iOS SDK on Xcode 26.6 (Release)
2. Scan app package with NowSecure
3. Observe vulnerability finding for libz.1.dylib version 1.2.12

Privacy note

Please avoid asking for public app-identifying details. I can share sanitized diagnostics privately.

Reproducing the issue

Build app from in Release
Use latest Firebase iOS SDK
Build with Xcode 26.6
Run NowSecure scan
Observe finding for libz.1.dylib version 1.2.12 (4 CVEs, highest 9.8)

Firebase SDK Version

26.6

Xcode Version

26.6

Installation Method

Swift Package Manager

Firebase Product(s)

App Distribution, Analytics, Crashlytics

Targeted Platforms

iOS

Relevant Log Output

If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet

Replace this line with the contents of your Package.resolved.

If using CocoaPods, the project's Podfile.lock

No response

[rizafran]

Thanks for reporting. Upon checking, the libz.1.dylib is a system library provided by Apple as part of the iOS runtime. It is not bundled inside the Firebase iOS SDK, nor is it usually packaged inside your application binary. You may try to verify whether your app is linking against Apple's system library or if a custom version is actually embedded in your .ipa file using the otool:

# 1. Unzip your .ipa file
unzip MyApp.ipa

# 2. Navigate to the Payload folder
cd Payload/MyApp.app/

# 3. Check dynamic library dependencies for your main executable
otool -L MyAppExecutable | grep libz 

[MuraliSaiTummala]

Thanks @rizafran. We verified with otool on our build, and you're right that it's not a bundled/custom copy:

$ otool -L "My App" | grep libz
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12)

find over the .app returns no libz/zlib file, confirming nothing is embedded — the app dynamically links Apple's system library. (Screenshot attached.)

That said, both our testing and the Firebase SDK source show the /usr/lib/libz.1.dylib reference is introduced by the Firebase SDK:

Behavioral proof

• With Firebase → libz.1.dylib 1.2.12 is flagged.
• Remove Firebase → the reference is gone from the binary and the finding passes.
• Even a Crashlytics-only build (no Analytics) still shows it.

Code-level proof (from Firebase's own packages)

• GoogleUtilities/Package.swift → the GoogleUtilities-NSData target (path GoogleUtilities/NSData+zlib) declares .linkedLibrary("z"), i.e. the -lz flag that embeds the /usr/lib/libz.1.dylib load command into the app binary.
• GoogleDataTransport/.../GDTCCTCompressionHelper.m → #import <zlib.h> and calls deflateInit2() / deflate() to gzip telemetry before upload.
• firebase-ios-sdk/Package.swift → the FirebaseAnalytics wrapper targets also declare .linkedLibrary("z").

Both GoogleUtilities and GoogleDataTransport are dependencies of Analytics and Crashlytics, which is why the reference appears even with Crashlytics alone, and disappears entirely when Firebase is removed. Our first-party code does not reference or link zlib anywhere.

We understand the zlib version (1.2.12) is Apple's system library and can't be changed at the app level (we've also filed with Apple, FB24008444). Our question is specifically about the linkage: is there any Firebase guidance for apps flagged on zlib:zlib:1.2.12 via this transitive system-library link — e.g., a build/config option, or a statement we can cite to security reviewers (NowSecure MASVS) confirming this is expected and low-risk?

Thanks,
Murali Sai

[MuraliSaiTummala]

To make the source concrete — this is visible directly in our own project's dependencies (screenshot attached). In GoogleUtilities 8.1.0 (pulled in transitively by FirebaseAnalytics/Crashlytics), the file:

GoogleUtilities/NSData+zlib/GULNSData+zlib.m

#import <zlib.h> // line 17
...

• (NSData *)gul_dataByInflatingGzippedData:(NSData *)data error:(NSError **)error {
  ...
  z_stream strm; // uses zlib directly

This is Google's own code (// Copyright 2018 Google, line 1), and its target in GoogleUtilities/Package.swift declares .linkedLibrary("z") (-lz) — which is exactly what embeds the /usr/lib/libz.1.dylib reference into the app binary that NowSecure flags.

So to summarize the full chain, verified in our project:

App → FirebaseAnalytics / Crashlytics → GoogleUtilities (NSData+zlib) → #import <zlib.h> / -lz → /usr/lib/libz.1.dylib (Apple system, 1.2.12)

Our first-party code contains no zlib usage — it comes entirely from GoogleUtilities/GoogleDataTransport. Since the library itself is Apple's system zlib, could you confirm whether this transitive linkage is expected, and whether there's any Firebase-side guidance (or a statement we can cite to security reviewers) for the zlib:zlib:1.2.12 finding?

Thanks,
Murali Sai

[paulb777]

Confirmed that both Crashlytics and Analytics depend on the Apple system library libz.

[MuraliSaiTummala]

Thanks @paulb777. Since both libz (Apple system library) and the bundled gRPC are currently release blockers for us (flagged as App Store Blocker / MASVS), could the Firebase team please provide:

1. An official statement we can cite to our security reviewers — confirming libz.1.dylib is Apple's OS-provided system library (linked, not bundled) and not remediable at the SDK level, and
2. An ETA for a Firebase release that pins a patched grpc-binary to resolve the gRPC CVEs.

An official confirmation and timeline would let us document libz as accepted risk and plan the Firebase update for gRPC. Appreciate your help.