CVE-2026-6970: authd Privilege Escalation Vulnerability

CVE-2026-6970 Overview

A local privilege escalation vulnerability has been identified in authd prior to version 0.6.4. The vulnerability stems from a logic error in the primary group ID (GID) assignment mechanism. When a user's primary group ID differs from their UID—either because the account was created with authd prior to version 0.5.4 or because the primary group was manually changed via the authctl group set-gid command—and the user's identity provider record is updated, authd incorrectly resets the user's primary group ID to their UID upon next login.

This incorrect behavior causes newly created files and directories to be owned by the wrong group, leading to denial of service issues and potentially granting unintended access to other local users, thereby enabling local privilege escalation.

Critical Impact
Local attackers can exploit incorrect group ownership on newly created files to gain unauthorized access to sensitive resources or escalate privileges on affected systems running authd versions prior to 0.6.4.

Affected Products

authd versions prior to 0.6.4
authd versions prior to 0.5.4 (accounts created in these versions are particularly vulnerable)
Systems where primary groups were manually modified via authctl group set-gid

Discovery Timeline

2026-04-27 - CVE-2026-6970 published to NVD
2026-04-27 - Last updated in NVD database

Technical Details for CVE-2026-6970

Vulnerability Analysis

The vulnerability is classified under CWE-842 (Placement of User into Incorrect Group), which accurately describes the core issue. The flaw exists in authd's user management logic, specifically in how it handles primary group ID persistence across identity provider updates and user logins.

Under normal circumstances, a user's primary group ID should remain stable unless explicitly changed by an administrator. However, due to this logic error, authd incorrectly assumes that a user's private group GID should always match their UID. When an identity provider record is updated, authd enforces this incorrect assumption, overwriting any legitimate GID configurations.

The attack requires local access and low privileges to exploit. The attacker must wait for or trigger an identity provider record update, after which the next login session will apply the incorrect GID. Files created in this session will have improper group ownership, potentially exposing sensitive data or allowing unauthorized modifications.

Root Cause

The root cause lies in the internal/users/manager.go file where the user private group GID was unconditionally set to match the user UID. The vulnerable code explicitly assigned userPrivateGroup.GID = &u.UID regardless of the user's actual configured primary group, failing to preserve legitimate GID assignments that differed from the UID.

Attack Vector

This is a local attack vector requiring:

A user account whose primary GID differs from their UID (either legacy accounts from authd < 0.5.4 or accounts with manually configured primary groups)
An identity provider record update trigger
User login after the update, which causes the GID reset

The attacker can exploit the resulting incorrect file ownership by:

Accessing files that should have been protected by proper group permissions
Modifying files created by other users whose GID was incorrectly reset
Escalating privileges through group-based access control bypasses

// Vulnerable code pattern (removed in fix)
// User private Group GID is the same of the user UID.
userPrivateGroup.GID = &u.UID

// Fixed code preserves user's configured GID by removing this incorrect assignment
// and properly iterating through groups to maintain their original GID values
for i := range u.Groups {
    g := &u.Groups[i]
    if g.Name == "" {
        return fmt.Errorf("empty group name for user %q", u.Name)
    }
}

Source: GitHub Commit 154b428

Detection Methods for CVE-2026-6970

Indicators of Compromise

Unexpected changes to file and directory group ownership after user logins
User primary GID values that unexpectedly match their UID when they should differ
Access control violations or permission errors in applications relying on group-based permissions
Log entries indicating identity provider record updates followed by group ownership anomalies

Detection Strategies

Monitor for changes in user primary group assignments in /etc/passwd or equivalent authd databases
Implement file integrity monitoring on critical directories to detect unexpected group ownership changes
Audit user login events correlated with identity provider synchronization activities
Review system logs for permission-related errors that may indicate improper group assignments

Monitoring Recommendations

Enable verbose logging in authd to track group ID assignment operations
Implement alerting on any changes to user primary group IDs that were not initiated by administrative actions
Monitor for privilege escalation attempts that leverage group membership inconsistencies
Regularly audit file ownership in sensitive directories to detect unauthorized group assignments

How to Mitigate CVE-2026-6970

Immediate Actions Required

Upgrade authd to version 0.6.4 or later immediately
Audit all user accounts to identify those with primary GID differing from their UID
Review and correct any file ownership issues that may have resulted from the GID reset behavior
Temporarily restrict identity provider synchronization until the patch is applied if immediate upgrade is not possible

Patch Information

Canonical has released authd version 0.6.4 which addresses this vulnerability. The fix removes the incorrect logic that forced user private group GID to match the user UID, ensuring that configured primary group assignments are preserved across identity provider updates and login sessions.

The security patch is available through:

Workarounds

Avoid manually changing user primary groups via authctl group set-gid until upgraded
Implement additional file permission monitoring to detect and alert on ownership changes
Consider temporarily disabling identity provider synchronization for affected accounts
Apply strict file system permissions on sensitive directories that do not rely solely on group ownership

bash

# Verify current authd version
authd --version

# Check for users with mismatched UID/GID
awk -F: '$3 != $4 {print $1, "UID:", $3, "GID:", $4}' /etc/passwd

# Audit file ownership in critical directories after upgrading
find /home -type f -exec stat -c '%n %U %G' {} \; | grep -v "expected_group"