apt said the machine was patched. Two CVEs were waiting behind Ubuntu Pro
Our own scanner flagged two CVEs on gh on a fully updated Ubuntu 24.04 box. The fix had been published in February, in the ESM channel, where apt cannot see it. What we checked and what we did about it.
We found this by accident, which is usually how it goes.
Friday, one of our Ubuntu 24.04 servers at Hetzner. It had just been through its update cycle, rebooted and everything. We were testing the Linux agent of our own product against it, mostly to debug something unrelated, and the scan came back with two CVEs on gh, the GitHub CLI. My first thought was that our matcher was wrong. It happens, version comparison on Debian packages is a minefield, so I went to check manually, fully expecting to close this as a bug on our side.
It was not a bug.
Here is the check I did, you can run the same on any 24.04 box:
apt list --upgradable 2>/dev/null | grep -i security
Nothing. Then:
apt-cache policy gh
Installed 2.45.0-1ubuntu0.3, candidate 2.45.0-1ubuntu0.3. Same version. So apt considers the machine fully patched, and honestly, until that Friday I would have agreed with it.
The two CVEs
CVE-2024-53858: when you clone a repository with submodules that live outside GitHub.com and ghe.com, the CLI could send an authentication token to that foreign host. Depending on your setup that can be an Enterprise token or even your GITHUB_TOKEN (Codespaces users, that means you). A gh repo clone on the wrong repository is all it takes. Upstream fixed it in 2.63.0.
CVE-2024-54132: a path traversal in gh run download. A workflow artifact named .. gets extracted one directory above where you asked. Fixed in 2.63.1.
So the question became: our noble box runs 2.45, the fixes are in 2.63, where is the update?
Where the update actually is
The answer took me twenty minutes of digging and it sits in one place: USN-8012-1, published by Canonical on February 4, 2026. The patched package for noble exists, it is 2.45.0-1ubuntu0.3+esm2.
I had to look up what esm2 meant. ESM stands for Expanded Security Maintenance, and it is the update channel you get when you attach the machine to Ubuntu Pro. We had not attached it. So the fix has been sitting there for months, published, documented, and completely unreachable for our apt.
So yes, apparently even on free and open source Linux, security now comes with a Pro tier. The code is free, the maintenance is the product. I made the joke myself that morning. Then I counted how many of our packages were in the same situation, and it got less funny.
I want to be fair to Canonical here, because the story is more nuanced than “universe packages get no updates”. The 2.45.0-1ubuntu0.3 we were running is itself a public security update from July 2025, delivered through the normal channels, no Pro needed. It is these two specific CVEs that went ESM only.
Also, on a standard install, apt upgrade does print a notice about it, one of those “the following security updates require Ubuntu Pro” lines. Be honest, when did you last read the full output of apt upgrade? And on minimal images and containers, where ubuntu-pro-client is not installed, the notice does not exist at all.
Checking a machine yourself
There is one more command worth knowing. This one gives you an actual number for your own machine:
pro security-status
On a second server of ours, where we later reproduced the whole thing, it printed: “There are 3 pending security updates” for universe packages, available only through esm-apps. Three published fixes the machine will not get in its current state, counted by Canonical’s own tool.
What we did
In the end we put these machines on the list of things our scanner watches, since it reads the distro security trackers directly, ESM advisories included.
That is SentriKat, the product this blog belongs to, and yes, this whole post started as one of its findings that I did not believe.
If you take one thing away: an empty apt list --upgradable tells you apt has nothing for you. Whether a fix for your packages exists somewhere else is a different question, and apt was never designed to answer it.
One last thing we did before publishing, because we wanted to see the other side of the door. We attached a free Ubuntu Pro subscription on the same test machine (it is free for personal use, up to five physical machines), ran apt update, and there it was: gh 2.45.0-1ubuntu0.3+esm3, offered like any normal update. Not even the esm2 from the advisory, a newer revision, the channel had moved on again in the meantime. Same machine, same apt, five minutes apart. The fix was never missing. It was sitting behind a door we had not opened.
Ready to automate your vulnerability management?
Deploy SentriKat on-premises in minutes. Track exploited vulnerabilities, generate NIS2 compliance reports, and protect your infrastructure.
Request a Demo