Published November 4, 2026 · Security release: November 2, 2026
NLnet Labs has disclosed three High-severity vulnerabilities affecting Krill through version 0.16.0 inclusive. Its remedy for all three is to install version 0.16.1 or newer.
Krill is an open-source RPKI certificate authority that supports delegated resource management and publishes Route Origin Authorisations (ROAs). It can serve multiple organizations, making the separation between their administrators and resources particularly relevant.
Three different authorization failures
CVE-2026-109140: When multi-user login is enabled, a user who can log in can forge an administrator token. The encryption counter resets at each restart, causing reuse of a key-and-nonce pair. The resulting impersonation can allow actions with another local user’s authority.
CVE-2026-109141: A user restricted to specified CAs receives their full permission set on requests not associated with a CA. Through bulk import, they can create a child under another existing CA, delegate its resources and create ROAs, crossing the intended administrative boundary.
CVE-2026-109142: When a parent CA is on the same server, the local provisioning exchange trusts the supplied child identity without checking that it belongs to the requesting CA. A CA operator can therefore impersonate another child and take over a sibling CA’s resources.
Why a restart is insufficient
The nonce fix generates a fresh random component at startup. It also changes the key-storage location so the update generates a new key. Restarting the old code does not provide those changes; install the corrected version rather than treating a restart as remediation.
A focused administration review
Our recommendation is to pair the update with four checks. These are operational review steps, not additional vendor-prescribed mitigations.
- Identify named users. Record whether multi-user login is enabled, who can sign in and which accounts should have administrative authority. Assign a service owner to resolve unexplained access rather than accepting the account list as its own justification.
- Map CA role restrictions. Write down which authorities each role should manage. Review bulk-import workflows against that map, using controlled test identities and expected refusals as well as successful operations.
- Check co-hosted relationships. Inventory parent and child authorities sharing each server. Have their owners confirm the intended relationships and resource assignments. Keep production routing resources outside experimental testing.
- Verify the deployed result. Confirm every instance’s running version. Compare resource assignments and published ROAs with an approved baseline; investigate unexplained differences without assuming malicious activity.
The completion record should distinguish installation from verification: who reviewed each boundary, what matched the intended state and which questions remain open.