CVE-2026-104039

What it actually does

Use-after-free in the PAM responder during GSSAPI authentication: cached connection state is freed without clearing the reference, allowing a subsequent request on the same connection to dereference invalid memory and crash the service.

Why it matters to the business

Local denial-of-service against system authentication on Fedora, RHEL, and OpenShift deployments; login and sudo operations become unavailable until the service restarts, with public exploit code available nearly a month after disclosure increasing the chance of opportunistic abuse.

How an attack unfolds

A local attacker with a low-privileged account opens a connection to the SSSD PAM responder, completes a GSSAPI authentication exchange that triggers the premature free, then immediately issues another request over the still-open connection; the dangling pointer causes an invalid memory access that terminates the daemon.

How to fix it

Upgrade to the first patched release of sssd from Fedora, Red Hat Enterprise Linux, or OpenShift Container Platform once vendor updates are published; until then restrict local accounts, monitor for repeated sssd crashes, and consider disabling GSSAPI authentication in PAM if operationally feasible.

How to confirm the fix worked

After applying updates, confirm the sssd package version matches the vendor advisory, run regression tests that exercise PAM GSSAPI flows, and verify that the service no longer terminates when duplicate requests are sent over a single connection.

Typical attack path

1. Obtain local shell or user session on an affected host
2. Connect to the SSSD PAM responder and initiate GSSAPI authentication
3. Trigger completion of the authentication flow so the connection state is freed
4. Send a follow-up request on the same connection before the process exits
5. Observe service crash and repeated authentication failures

How to detect it

Review system and sssd logs for unexpected process terminations or segmentation faults around PAM GSSAPI activity; correlate with authentication failures immediately following a successful GSSAPI exchange on the same connection.

• sssd.*segfault
• sssd.*terminated unexpectedly
• PAM responder.*GSSAPI.*connection

What your security team should do

• Treat as priority because exploit code is publicly available
• Inventory all systems running sssd on Fedora, RHEL, and OpenShift
• Subscribe to vendor security notifications for the forthcoming fix
• Harden local access controls to reduce the pool of potential attackers
• Add sssd process crash alerts to existing monitoring