Use apt-mark hold only as a short, documented exception, because a held package is excluded from automatic upgrades, including security fixes. If a package must stay on one version, record the owner, the reason and an expiry date, and add a compensating control until the hold is lifted.
What a hold does
The apt-mark manual says that hold marks a package as held back, which prevents it from being automatically installed, upgraded or removed. Unhold removes the mark, and showhold lists current holds. Holds are stored as dpkg selections, and tools such as aptitude respect them.
sudo apt-mark hold package-name
apt-mark showhold
sudo apt-mark unhold package-name
Why teams hold packages
- A newer version changes behaviour your application depends on.
- A database or runtime upgrade needs coordination with a schema change.
- A vendor supports only one version of a package.
All are real reasons. The danger is not the hold itself. It is forgetting it.
What a forgotten hold costs
A held package keeps its vulnerabilities. If unattended upgrades is running, it will skip the held package, and the dashboard may still show a healthy update status. The Ubuntu documentation also warns that blocking a package might prevent other updates from installing if they depend on it, so a single hold can quietly stall a chain of fixes.
Treat holds as patch exceptions. A workable register has these columns:
| Field | Example content |
|---|---|
| Host or image | Which systems carry the hold |
| Package and version | What is frozen |
| Reason | The dependency or vendor limit |
| Owner | A named person or team |
| Review date | When to retry the upgrade |
| Compensating control | Network restriction, WAF rule, monitoring |
There is more on this process in patch exception register: how to track exceptions.
Alternatives to a blanket hold
- Test the upgrade in a staging host and fix the incompatibility, which ends the need for the hold.
- Hold the one package and keep upgrading everything else, rather than freezing the whole host.
- Pin by repository or version in a Dockerfile so the choice is visible in code, as discussed in should you pin apt package versions in a Dockerfile.
- Isolate the host if it truly cannot be updated, following unpatchable assets: isolation and long term mitigation.
A worked example
Say your service needs a database client library at one version because a newer release changes a default. You hold the package, note it in the register, and move on. Three months later a security advisory lands for that library. Without a review date, nobody looks. With one, the owner sees the advisory, tests the newer version in staging, and either lifts the hold or writes a compensating control, such as restricting which hosts can send the library untrusted input.
The lesson is that a hold is a promise to revisit. Put the review date in a calendar or ticket, not in someone's memory.
Check holds in audits
When an auditor or customer asks how you apply security updates, holds are the honest exception. Be ready to list them with reasons and dates. A short, well explained list reads as control. A long, unexplained one reads as drift.
Quick check
Does a hold block security updates for that package?
Yes. The apt-mark manual says a held package is excluded from automatic installation, upgrade and removal.
How do I list what is held on a host?
Run apt-mark showhold.
Safeguard flags known advisories against installed packages, so a held package with an open fix appears as a finding you can attach an exception and expiry to.
Sources
Last reviewed: 19 October 2026.
