Alpine Linux security updates (servers and containers)

Updated November 2026

On Alpine Linux, security fixes come as normal package updates on your release branch: run apk update and then apk upgrade. For containers, patching means rebuilding the image, not updating a running container.

Supported release branches

Alpine creates a new release branch from edge every May and November. On each branch the main repository is typically supported for 2 years, and the community repository only until the next stable release. After that, Alpine says security fixes “can be made on request when there are patches available”, which is not something to rely on.

Alpine Linux release branches, as of November 2026
Branch	Branch date	End of support	Still supported
v3.24	2026-06-09	2028-06-01	main and community
v3.23	2025-12-03	2027-11-01	main
v3.22	2025-05-30	2027-05-01	main
v3.21	2024-12-05	Ended 2026-11-01	None
v3.20 and older	2024 and earlier	Ended	None
edge	Development branch	Not a stable release	Not for production

So a v3.23 server that uses packages from community (for example many language runtimes) already gets no community fixes, because v3.24 is out. Look up which repository your important packages come from on pkgs.alpinelinux.org, and plan upgrades with that in mind.

Since v3.23, Alpine uses apk-tools version 3. The commands on this page work with both apk v2 (v3.22) and v3.

Check your release

cat /etc/alpine-release
cat /etc/os-release
cat /etc/apk/repositories

The repositories file shows which branch you actually install from, such as …/alpine/v3.24/main. If it says latest-stable, the next apk upgrade after a new release can move you to the new branch.

Apply security updates now

apk update
apk version -l '<'
apk upgrade

Run these as root (or with doas/sudo). apk update downloads the latest package index; apk version -l '<' lists installed packages that have a newer version available; apk upgrade installs the updates. The short form apk -U upgrade does the update and upgrade in one step.

Alpine has no separate security repository or security-only mode. In the words of Alpine’s wiki, apk update followed by apk upgrade gets “the latest security upgrades and bugfixes” from your current release branch, so a regular upgrade on a supported branch is the security update.

Configuration files

If an update would overwrite a config file you changed, apk writes the new one as .apk-new instead. List and review them with update-conf -l and update-conf. Be careful not to replace files such as /etc/passwd or /etc/shadow with the new version, which would wipe your users and password hashes.

Is a package vulnerable?

Each Alpine package records the CVEs it fixes (its secfixes). Alpine publishes this as the security database at secdb.alpinelinux.org, one file per branch and repository, for example https://secdb.alpinelinux.org/v3.24/main.json. Container and image scanners use it to decide whether an Alpine package is fixed. The Alpine security tracker shows potentially vulnerable packages for each branch.

Automatic updates

Alpine’s wiki mentions apk-autoupdate, but as of November 2026 that package is only in the edge testing repository, not in stable branches. On a server, a simple alternative is a daily script for the BusyBox cron daemon. Create /etc/periodic/daily/apk-upgrade:

#!/bin/sh
apk -U upgrade >/var/log/apk-upgrade.log 2>&1

Then make it executable and make sure crond runs at boot:

chmod +x /etc/periodic/daily/apk-upgrade
rc-update add crond
rc-service crond start

This installs updates but does not restart services or reboot, so you still need the steps below. See automatic updates.

Restart services and reboot

Alpine’s documentation says that services must be restarted to use upgraded code, and that a kernel upgrade needs a reboot. Alpine uses OpenRC:

rc-status
rc-service nginx restart
reboot

rc-service … restart briefly interrupts that service; reboot restarts the server. Reboot after any update to the kernel package (for example linux-lts), and plan a maintenance window for it. In diskless and data-disk installs, apk upgrade does not upgrade the kernel; use the update-kernel script and remember lbu commit to keep changes.

Containers

An Alpine container has no kernel of its own (it uses the host’s), and changes made inside a running container are lost when it is replaced. Patch the image, then replace the containers:

Base your image on a supported branch tag, such as alpine:3.24, not an old point-release tag that stops getting fixes.
Upgrade packages during the build, so fixes released after the base image are included:
```
FROM alpine:3.24
RUN apk upgrade --no-cache
```
Rebuild with a fresh base image and redeploy:
```
docker build --pull -t myapp:latest .
```
--pull makes Docker fetch the newest alpine:3.24 instead of a cached copy.
Scan the new image, then restart or redeploy the containers that use it.

Rebuild on a schedule (for example weekly) and whenever the secdb or an advisory shows a fix for a package in your image. See patching containers.

Where Alpine publishes security information

Alpine security database (secdb) and the security tracker.
alpine-announce mailing list and the news feed, which announce new point releases (for example 3.21.9, 3.22.7, 3.23.7 and 3.24.3 on 2026-10-21) and incidents.
Release branches page for end-of-support dates.

On an end-of-support branch

If you are on v3.21 or older, move to a supported branch. Back up first, read the release notes, then edit /etc/apk/repositories to the new version (for example replace v3.21 with v3.24) and run:

apk update
apk add --upgrade apk-tools
apk upgrade --available
sync
reboot

--available resets packages to the versions in the new branch, even when version numbers match. Handle .apk-new files, and reboot (this restarts the server) to load the new kernel. For containers, change the FROM line and rebuild. Upgrading across several branches at once can need extra steps; check Alpine’s upgrade notes. See end-of-life systems.