How severe is GHSA-fg3j-5w9g-hmg7?

No CVSS score has been assigned to GHSA-fg3j-5w9g-hmg7 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-fg3j-5w9g-hmg7?

GHSA-fg3j-5w9g-hmg7 affects the following packages: github.com/canonical/authd (Go). Ecosystems affected: Go.

How do I fix GHSA-fg3j-5w9g-hmg7?

Update github.com/canonical/authd to 0.6.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fg3j-5w9g-hmg7 is resolved across your whole dependency graph.

How do I detect GHSA-fg3j-5w9g-hmg7 in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/canonical/authd. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-fg3j-5w9g-hmg7 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-fg3j-5w9g-hmg7?

O3 pinpoints whether GHSA-fg3j-5w9g-hmg7 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-fg3j-5w9g-hmg7 actively exploited in the wild?

No public exploit code has been indexed for GHSA-fg3j-5w9g-hmg7 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-fg3j-5w9g-hmg7 published, and has it been updated?

GHSA-fg3j-5w9g-hmg7 was published on May 5, 2026 and was last updated on June 25, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

GHSA-fg3j-5w9g-hmg7

Fix: canonical/authd@154b428

GHSA-fg3j-5w9g-hmg7 is a security vulnerability in github.com/canonical/authd. O3 Security confirms whether GHSA-fg3j-5w9g-hmg7 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

authd: Primary group ID is incorrectly set to value of UID

Also known asCVE-2026-6970GO-2026-5361

Published

May 5, 2026

Updated

Jun 25, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Real-World Exposure

1 pkg affected

🐹github.com/canonical/authd

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

authd 0.6.0 contains a bug which can lead to an incorrect primary group ID.

It affects users whose primary group ID (i.e. the GID in the user record) differs from their UID. There are two ways which can lead to this:

The user was created with authd < 0.5.4 (released June 2025). Those users were created with UID != GID.
The primary group of the user was modified manually with the authctl utility that is shipped with authd (authctl group set-gid).

Another condition is that some user information must have changed in the identity provider (else the user record is not updated upon login). If that is the case, the next time an affected user logs in, authd will set their primary group ID to their UID.

This could lead to local privileges escalation. Also, files and directories created by those users will be owned by that incorrect primary group, which may grant other local users access to those files which they shouldn't have.

Users who are affected by the issue can run this script to fix the primary group ID of all authd users and the file ownership of files in the home directory created with the incorrect GID:

authd_users=$(getent passwd --service authd | cut -d: -f1)
for user in $authd_users; do
    OLD_GID=$(id -g "$user")
    GID=$(getent group "$user" | cut -d: -f3)
    if [ -z "$GID" ]; then
        echo "Warning: could not determine GID for $user, skipping" >&2
        continue
    fi
    if [ "$OLD_GID" = "$GID" ]; then
        continue  # user not affected
    fi
    USER_HOME=$(getent passwd "$user" | cut -d: -f6)
    echo "Fixing $user: resetting GID from $OLD_GID to $GID"
    sudo authctl group set-gid "$user" "$OLD_GID"
    sudo authctl group set-gid "$user" "$GID"
    sudo chown -R --from=":$OLD_GID" ":$GID" "$USER_HOME"
done

After applying the fix, affected users must log out and log back in for id, groups, and new file GID stamping to reflect the corrected primary group. You may also optionally terminate a user's active session with:

sudo loginctl terminate-user "$user"

If the users also own files outside their home directory, the ownership of those files might have to be updated as well.

Fixed by: https://github.com/canonical/authd/commit/154b428305cb1a7a19c897626fefd09d6dde8b9f

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/canonical/authd`	≥ 0.6.0&&< 0.6.4	0.6.4

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/canonical/authd. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/canonical/authd to 0.6.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fg3j-5w9g-hmg7 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-fg3j-5w9g-hmg7 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-fg3j-5w9g-hmg7. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

authd 0.6.0 contains [a bug](https://github.com/canonical/authd/issues/1482) which can lead to an incorrect primary group ID. It affects users whose primary group ID (i.e. the GID in the user record) differs from their UID. There are two ways which can lead to this: 1. The user was created with authd < 0.5.4 (released June 2025). Those users were created with UID != GID. 2. The primary group of the user was modified manually with the authctl utility that is shipped with authd (`authctl group set-gid`). Another condition is that some user information must have changed in the identity provid

O3 Security · Impact-Aware SCA

Is GHSA-fg3j-5w9g-hmg7 in your dependencies?

O3 detects GHSA-fg3j-5w9g-hmg7 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works