CVE-2026-55222: Isar: Unprivileged user ownership of trusted repository GPG public keys storage after bootstrap
Isar is an integration system for automated root filesystem generation. In versions 0.11 and newer, /etc/apt/trusted.gpg.d is created manually during bootstrap setup to be able to deploy local keys. By that, the directory is owned by the calling user (the one that executes Isar) instead of root. If the calling user's id is identical to one of an unprivileged user inside the image, this user is able to alter existing keys and deploy new ones, silently breaking the apt repo integrity protection. The issue is has no impact on those images that use an immutable rootfs, or if apt is never invoked. Changing only the keys does not trigger an exploit, it's just one step in a chain. An attacker would also have to manipulate a remote repo or intercept non-secure communication with it. This issue has been patched via commit 29e84ed.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch 29e84ed
Event History
Frequently Asked Questions
Which images are realistically exposed to integrity compromise?
Affected images are those where the Isar calling user's UID matches an unprivileged user in the image, the root filesystem is mutable, and APT is invoked. Images using an immutable root filesystem, or images that never invoke APT, are not impacted.
What else must an attacker do after changing trusted repository keys?
Changing the keys alone is not sufficient to exploit the issue. The attacker must also manipulate a remote repository or intercept insecure communication with it in order to undermine repository integrity.
How can I determine whether an image has the risky ownership condition?
Check ownership of /etc/apt/trusted.gpg.d in the generated image and compare its owner UID with UIDs assigned to unprivileged users in that image. The vulnerable condition exists when the directory is owned by the Isar-invoking user and that UID is used by an unprivileged in-image account.
What remediation is available?
The issue is patched by commit 29e84ed. Apply that patch or use a version containing it.