CVE-2026-6245

What it actually does

CVE-2026-6245 is a local denial-of-service flaw in the System Security Services Daemon (SSSD) PAM passkey responder. The vulnerable code path, pam_passkey_child_read_data(), reads raw bytes from a pipe and later treats that data as a NUL-terminated C string without guaranteeing explicit termination. When string-handling functions such as snprintf() process the buffer, SSSD can perform an out-of-bounds read and crash the PAM responder. The impact is availability loss for authentication services that rely on SSSD, particularly passkey-backed PAM authentication. The CVSS vector indicates local access is required, exploitation complexity is low, and no confidentiality or integrity impact is expected.

Why it matters to the business

Successful exploitation can disrupt local authentication on Linux systems using SSSD passkey authentication, potentially preventing users or administrators from logging in through affected PAM flows. Because SSSD is commonly used for centralized identity integration, a crash can create operational friction across servers, workstations, or infrastructure components that depend on it. The issue is not currently listed in CISA KEV, has low EPSS, and has no reported mature exploit in the provided data, but it should still be prioritized on shared systems where untrusted local users can attempt authentication repeatedly.

How an attack unfolds

An attacker needs local ability to initiate an authentication attempt against a PAM service that uses SSSD with passkey support. The attacker crafts a passkey authentication request that causes malformed or unterminated raw data to be passed through the pipe read by pam_passkey_child_read_data(). Because the responder later handles that buffer as a C string, processing can read past the intended bounds and trigger a crash. The practical result is denial of service: the SSSD PAM responder or related SSSD process fails, which can interrupt authentication until the service is restarted or recovers. There is no indication from the provided information that this enables privilege escalation, credential theft, remote code execution, or data modification.

How to fix it

Upgrade SSSD to a vendor-provided fixed version as soon as patches are available for the relevant Linux distribution. No exact fixed versions were provided in the input, so remediation should be tracked through the operating system vendor’s security advisory and package repositories. Where immediate patching is not possible, reduce exposure by disabling passkey authentication through SSSD where it is not required, limiting local interactive access to trusted users, and ensuring SSSD is supervised by systemd or equivalent service management for automatic restart. Because this is a local DoS issue, compensating controls should focus on restricting who can initiate local PAM authentication attempts and monitoring for repeated SSSD crashes.

How to confirm the fix worked

Confirm the installed SSSD package version against the fixed version published by the relevant Linux distribution or upstream advisory. Validate that PAM passkey authentication still works after upgrade and that repeated failed or malformed authentication attempts no longer crash sssd_pam or related SSSD child processes. Check service health with systemctl status sssd and review journal logs for recent crashes, core dumps, segmentation faults, or repeated restarts. If passkey authentication is not required and was disabled as a mitigation, confirm PAM configuration no longer invokes the affected SSSD passkey path.

Typical attack path

1. Obtain local access to a Linux system where SSSD is installed and PAM passkey authentication is enabled or reachable.
2. Identify a PAM authentication path that invokes the SSSD passkey responder, such as local login, sudo, screen unlock, SSH with PAM, or another PAM-integrated service.
3. Initiate a crafted passkey authentication request that sends malformed raw bytes through the responder pipe.
4. Trigger the vulnerable string-handling path in pam_passkey_child_read_data(), causing an out-of-bounds read during later formatting or processing.
5. Cause the SSSD PAM responder or associated SSSD process to crash, disrupting authentication availability.
6. Optionally repeat the authentication attempts to sustain the denial-of-service condition if the service is automatically restarted.

How to detect it

To determine whether exploitation was attempted or successful, review host logs for SSSD crashes, PAM passkey authentication failures, core dumps, segmentation faults, and repeated service restarts. Useful sources include systemd journal logs for the sssd service, SSSD-specific logs such as /var/log/sssd/sssd_pam.log, authentication logs such as /var/log/secure on Red Hat-like systems or /var/log/auth.log on Debian-like systems, auditd logs if PAM authentication auditing is enabled, and coredump metadata from systemd-coredump or ABRT. Look for a pattern of passkey authentication attempts immediately followed by sssd_pam termination, segmentation faults, core dumps, or systemd restarting SSSD. Because this vulnerability produces denial of service rather than a persistent payload, durable artifacts are likely to be limited to logs, crash dumps, and service restart history.

• /var/log/sssd/sssd_pam.log
• /var/log/secure
• /var/log/auth.log
• sssd_pam
• pam_passkey_child
• pam_passkey_child_read_data
• Passkey authentication
• segfault at
• core dumped
• systemd-coredump
• Process sssd_pam
• sssd.service: Main process exited
• sssd.service: Failed with result 'core-dump'
• sssd.service: Scheduled restart job
• sssd.service: Started System Security Services Daemon
• audit: ANOM_ABEND
• /var/lib/systemd/coredump/
• /var/spool/abrt/

What your security team should do

• Inventory Linux systems running SSSD and identify those with passkey authentication enabled through PAM.
• Prioritize patching on multi-user systems, bastion hosts, developer workstations, shared compute nodes, and systems where untrusted or semi-trusted local users can attempt authentication.
• Track vendor advisories for the exact fixed SSSD package version and deploy updates through normal OS package management.
• If patches are unavailable, temporarily disable SSSD passkey authentication where operationally acceptable.
• Monitor for sssd_pam crashes, SSSD service restarts, core dumps, and bursts of failed passkey authentication attempts.
• Ensure systemd or the platform service manager is configured to restart SSSD after crashes to reduce operational impact.
• Review local user access policies and remove unnecessary shell or interactive login access from untrusted users.
• Create SIEM detections for repeated SSSD PAM responder failures followed by authentication outages.