lz4-java, Go and libtiff findings in the 1.0.0–1.1.2 images

What was found

The release scan of 1.2.0 refused the images below for what the scanners' database had just added: two new vulnerabilities, and the first fixed package for an older one. The same components are in every earlier published version, so a scanner pointed at those images reports them too.

Component	Image	CVE	Upstream severity	In BROKA
lz4-java 1.10.2	broker service	CVE-2026-106451	High	not exploitable
Go standard library 1.26.7, inside /usr/bin/pebble	broker service	CVE-2026-78667, CVE-2026-78669, CVE-2026-97031	High	never run
libtiff 4.7.1	console	CVE-2026-4775	High	never loaded

Both editions are affected the same way: Community 1.0.0 through 1.1.2, and Commercial 1.0.1 through 1.1.2. The Orchestrator images carry none of these.

Why none of them reaches BROKA

lz4-java — CVE-2026-106451

lz4-java extracts its native library to the temporary directory before loading it, through a file name another user can predict. Exploiting that needs a second local user who can write to the same directory and win the race before the library is loaded. In every way BROKA ships, the broker service has a temporary directory of its own and runs as its own non-root user: under Docker Compose it is the container's private file system, under the Helm chart an emptyDir volume belonging to the pod, and under the Linux package the systemd unit's PrivateTmp. There is no second user to win the race.

The Go standard library — CVE-2026-78667, CVE-2026-78669, CVE-2026-97031

The three are denial-of-service flaws in Go's HTTP and TLS servers. The only Go program in the broker image is /usr/bin/pebble, a service manager its Ubuntu base carries. Nothing in the image runs it: the image starts the Java service directly, so the vulnerable code is never executed. The Linux package does not include it at all.

libtiff — CVE-2026-4775

A crafted TIFF file can overflow a buffer in libtiff. The console's image carries libtiff only because nginx's image-filter module depends on it, through libgd. The console's nginx never loads that module, and it serves the console's own files; it never decodes an image.

What to do

Upgrade to 1.2.0. It is the supported release line, and its images carry none of the five: lz4-java 1.11.4, libtiff 4.7.2, and no pebble binary. An upgrade is new images and a restart; the 1.2.0 release notes have the details. No configuration change is needed, and none of the earlier versions needs a workaround in the meantime.

Scanners that read OpenVEX can take this advisory's statements from the document linked on this page, which names each affected image by digest.

Timeline

• 2026-03-24: CVE-2026-4775 is published for libtiff. Alpine's fixed package was not yet recorded when 1.1.2's images were scanned on 2026-10-08.
• 2026-10-06: CVE-2026-106451 is published for lz4-java.
• 2026-10-08: CVE-2026-78667, CVE-2026-78669 and CVE-2026-97031 are published for Go.
• 2026-10-11: the release image scan refuses the first 1.2.0 build; the components are updated or removed, and 1.2.0 is released the same day.