Serguey Asael Shinder: Three OpenJDK 17 authentication flaws were patched, and you have to restart
Canonical's USN-8795-1, published 21 September 2026, fixes three OpenJDK 17 vulnerabilities across five Ubuntu LTS lines. All three are described as incorrect handling of user authentication, remotely triggerable:
- CVE-2026-61308 — Networking, information leak;
- CVE-2026-70907 — JSSE, denial of service;
- CVE-2026-60589 — Security, information leak.
I am not going to pretend I reproduced these — there is no JDK on the machine I write these notes on, and I would not have the exploit anyway. What I want to flag is the operational sentence in the notice, because it is the part teams get wrong:
After a standard system update you need to restart any running Java applications to make all the necessary changes.
A JVM patch is not applied when apt finishes. It is applied when the process restarts. This is obvious and it is missed constantly, because the two facts that produce the miss are both true at once: the package is current, and the vulnerable code is still executing. A long-lived service — the exact thing you most want patched — is the one still running the old java.base an hour after the update reported success.
The practical consequence for anyone running a fleet:
"Patched" is a property of the running processes, not the package database. Your configuration-management tool will happily report the host compliant while every JVM on it carries the flaw. If your evidence that you are patched is dpkg -l, your evidence is measuring the wrong thing. The measurement that matches the CVE is process start time against patch time.
Three components, one root description, is an argument against triaging by CVE. Networking, JSSE and Security all "did not correctly handle user authentication" in the same release. Whatever the shared cause, the fix ships as one update, so the useful unit of work is "restart the JVMs", not "assess three CVEs".