See how red hat compares to other vendors in security performance
Moderate: Red Hat Service Interconnect 2.2.3 Release (images)
Moderate: Red Hat Service Interconnect 2.2.3 Release (rpms)
Moderate: tftp security update
A flaw was found in the clevis PKCS#11 pin. The clevis-pkcs11-afunix-socket-unlock daemon crashes when an AFUNIX client connects to the data socket without a bound address, due to an integer underflow in the getpeername result handling. This causes a denial of service, preventing LUKS disk decryption from completing during boot.
The clevis-decrypt-pkcs11 script passes the PKCS#11 token PIN via the -p command-line argument to pkcs11-tool at lines 121-122:
pkcs11-tool --login --decrypt --input-file ${ENC} \ -p ${PINvalue} ${moduleopt} ${mechanismoption} ${slotopt}
This makes the PIN visible to any local user via /proc/<pid>/cmdline or ps aux for the lifetime of the pkcs11-tool process. Unlike the daemon's -k flag (which is not used in production), this code path is exercised in the default production flow on every boot.
The PIN is the authentication credential for the PKCS#11 token. An attacker who captures the PIN and has physical access to the token can perform unauthorized private key operations.
The pkcs11-tool binary supports reading the PIN from an environment variable via the env: prefix on the -p flag (e.g., -p env:CLEVISPKCS11PIN), which would prevent command-line exposure since /proc/<pid>/environ is mode 0400 (owner-only). This is supported by pkcs11-tool's utilgetpin() function in OpenSC source (src/tools/util.c).
Additionally, the variables ${ENC}, ${PINvalue}, ${moduleopt}, ${mechanismoption}, ${slotopt} are all passed unquoted to pkcs11-tool, which is a secondary correctness issue (word splitting/globbing) but not security-critical.
Affected files: src/pins/pkcs11/clevis-decrypt-pkcs11 (lines 121-122) Versions affected: >= v21 through v22 (latest)
Steps to reproduce: 1. Boot a system using Clevis PKCS#11 pin for LUKS decryption. 2. During boot, as any local user: while true; do ps aux | grep '[p]kcs11-tool.-p' && break; sleep 0.01; done 3. If the timing window is hit, the PIN appears in the pkcs11-tool command-line arguments.
The clevis-luks-pkcs11-askpin script writes the PKCS#11 token PIN in plaintext to /run/systemd/clevis-pkcs11.pin at line 176:
echo "${pin}" > /run/systemd/clevis-pkcs11.pin
No umask is set before this write. Under the default systemd UMask of 0022, the file is created with mode 0644 (world-readable). The file is later read by clevis-decrypt-pkcs11 (line 118) and deleted after use (line 131: rm -rf "${PINFILE}"). However, the onexit trap in clevis-decrypt-pkcs11 only cleans the $CLEVISPKCS11 temporary directory, NOT the PIN file. If clevis-decrypt-pkcs11 exits early (multiple exit 1 paths before line 131) or is killed by a signal, the PIN file persists indefinitely.
The PIN is the authentication credential for the PKCS#11 token. While the PIN alone does not unlock the disk without physical access to the token, it enables an attacker to perform arbitrary private key operations on the token, potentially extracting LUKS key material independently of the daemon.
The race window between creation and deletion spans the full clevis-decrypt-pkcs11 invocation including PKCS#11 hardware decryption (typically 1-5 seconds on hardware tokens). Exploitation requires a local polling loop during boot but the window is reliably catchable on every boot.
Affected files: src/luks/systemd/clevis-luks-pkcs11-askpin.in (line 176), src/pins/pkcs11/clevis-decrypt-pkcs11 (cleanup gap) Versions affected: >= v21 through v22 (latest)
Steps to reproduce: 1. Boot a system using Clevis PKCS#11 pin for LUKS decryption. 2. During boot, as any local user: while true; do cat /run/systemd/clevis-pkcs11.pin 2>/dev/null && break; done 3. If the timing window is hit, the PKCS#11 PIN is displayed. 4. Alternatively, if clevis-decrypt-pkcs11 exits early, the PIN file persists indefinitely and can be read at any time.
The clevis-pkcs11-afunix-socket-unlock daemon creates two AFUNIX sockets (data socket at /run/systemd/clevis-pkcs11.sock and control socket at /run/systemd/clevis-pkcs11.control.sock) with no explicit permission restrictions and no peer credential verification. There is no umask(0077) before bind(), no fchmod() after bind(), and no SOPEERCRED check on accepted connections.
The data socket delivers LUKS passphrases to connecting processes. The control socket accepts arbitrary device/key pair injections from connecting processes. Socket permissions depend entirely on the inherited process umask — under systemd's default UMask=0022, sockets get mode 0755 which prevents unprivileged connect() (write permission required for AFUNIX stream sockets). However, in the dracut initramfs path or under a permissive umask, any process can connect and inject keys or receive passphrases.
The vulnerability is architectural: the code has zero authentication logic for its most critical function (key delivery), making the security posture entirely dependent on an inherited umask that is never verified in the code.
Affected files: src/pins/pkcs11/clevis-pkcs11-afunix-socket-unlock.c (controlthread and main socket handling) Versions affected: >= v21 through v22 (latest)
Steps to reproduce: 1. Start the daemon under permissive umask: (umask 0000; clevis-pkcs11-afunix-socket-unlock -l /run/systemd/clevis-pkcs11-systemd.log -f /run/systemd/clevis-pkcs11.sock -s 60 &) 2. Verify socket permissions: stat -c '%a' /run/systemd/clevis-pkcs11.control.sock shows 777 3. As non-root user, inject a key: echo -n "target-device,INJECTEDKEY" | socat - UNIX-CONNECT:/run/systemd/clevis-pkcs11.control.sock 4. The injected key is accepted and logged — no peer credential check is performed.
A flaw was found in Red Hat Quay. The build trigger management application programming interface (API) fails to verify whether a requested trigger belongs to the specified repository. An authenticated user with administrative access to any repository can view, modify, or permanently delete build triggers and associated write tokens of another repository if they know the victim trigger's universally unique identifier (UUID).
A flaw was found in Red Hat Quay. The build trigger management endpoints (GET, PUT, DELETE on /api/v1/repository/<repository>/trigger/<triggeruuid>) resolve the trigger object by its global UUID without verifying that the trigger belongs to the repository specified in the request URL. The requirerepoadmin decorator only authorizes the caller against the URL namespace/repository, not against the object a handler loads. As a result, any user who is admin of any repository can read another repository's build trigger configuration, disable it, or permanently delete it (along with its delegate write token) by supplying the target trigger's UUID. Exploitation requires knowledge of the victim trigger's random v4 UUID, which is not normally visible across organizations. The vulnerability is in endpoints/api/trigger.py, specifically the BuildTrigger class get/put/delete methods, which all call gettrigger(triggeruuid) - a UUID-only lookup with no repository/namespace scoping. The sibling endpoint BuildTriggerAnalyze.post already has the correct ownership check, confirming this is an oversight.
Rate Moderate - exploitation requires an authenticated user with the collection-namespace owner role to store the payload (roleless upload is rejected), and a separate authenticated viewer must actively activate the crafted link (no execution on page load); the build CSP does not block the script-executing scheme. Component mapping confirmed via newcli: Platform UI assets ship in automation-gateway (2.5 RPM), automation-platform-ui (2.6 RPM), and the gateway-rhel9 container (2.6 and 2.7); standalone ansible-hub-ui uses a different, non-reproduced renderer. Source flaw component = upstream ansible-ui (frontend/hub).
Rate Moderate - exploitation requires an authenticated user with the collection-namespace owner role to store the payload (roleless upload is rejected), and a separate authenticated viewer must actively activate the crafted link (no execution on page load); the build CSP does not block the script-executing scheme. Component mapping confirmed via newcli: Platform UI assets ship in automation-gateway (2.5 RPM), automation-platform-ui (2.6 RPM), and the gateway-rhel9 container (2.6 and 2.7); standalone ansible-hub-ui uses a different, non-reproduced renderer. Source flaw component = upstream ansible-ui (frontend/hub).
Moderate: environment-modules security update
A flaw was found in Keycloaks implementation of the Client-Initiated Backchannel Authentication CIBA grant. Although the CIBA specification and Keycloaks internal contract intend for this flow to be restricted to confidential clients, the enforcement mechanism is missing at both the backchannel-authentication and token endpoints. While bearer-only clients are correctly rejected, public clients which authenticate using only a client-id are permitted to proceed. An attacker can exploit this by using a public client to initiate a CIBA flow for a known user via login-hint. If the targeted user approves the resulting push notification on their authentication device, the attacker can redeem the auth-req-id at the token endpoint to obtain a valid user access token. This allows the attacker to perform any action the user is authorized to do and access their private information, all without ever possessing a client secret or valid credentials.
A flaw was found in Keycloaks implementation of the Client-Initiated Backchannel Authentication CIBA grant. Although the CIBA specification and Keycloaks internal contract intend for this flow to be restricted to confidential clients, the enforcement mechanism is missing at both the backchannel-authentication and token endpoints. While bearer-only clients are correctly rejected, public clients which authenticate using only a client-id are permitted to proceed. An attacker can exploit this by using a public client to initiate a CIBA flow for a known user via login-hint. If the targeted user approves the resulting push notification on their authentication device, the attacker can redeem the auth-req-id at the token endpoint to obtain a valid user access token. This allows the attacker to perform any action the user is authorized to do and access their private information, all without ever possessing a client secret or valid credentials.
A flaw was found in the login theme rendering component of Keycloak. The issue occurs because the security filter responsible for cleaning user input can be bypassed, allowing a realm administrator to store malicious scripts in display fields. This could result in unauthorized JavaScript execution in the browsers of users visiting the login page, potentially leading to data exposure or session interference.
Moderate: glibc security, bug fix, and enhancement update
A flaw was found in the keycloak-services component. A copy-paste error in the OIDC Dynamic Client Registration response serialization prevents the backchannellogoutrevokeofflinetokens setting from being included in GET responses. When an authorized user or client performs a standard read-modify-write update (GET followed by PUT), the missing field is interpreted as false, silently disabling the revocation of offline tokens. An attacker with manage-clients or registration access can exploit this to ensure offline tokens survive backchannel logout events, maintaining unauthorized access after a session should have been terminated. Additionally, this bug causes the backchannellogoutsessionrequired status to be incorrectly overwritten.
A flaw was found in the keycloak-services component. A copy-paste error in the OIDC Dynamic Client Registration response serialization prevents the backchannellogoutrevokeofflinetokens setting from being included in GET responses. When an authorized user or client performs a standard read-modify-write update (GET followed by PUT), the missing field is interpreted as false, silently disabling the revocation of offline tokens. An attacker with manage-clients or registration access can exploit this to ensure offline tokens survive backchannel logout events, maintaining unauthorized access after a session should have been terminated. Additionally, this bug causes the backchannellogoutsessionrequired status to be incorrectly overwritten.
A flaw was found in the Admin REST installation provider endpoints and the Client Registration install endpoint in Keycloak. While the dedicated client-secret endpoint correctly enforces authorization, these specific endpoints fail to mask the client secret when accessed by a user with the realm-management:view-clients role. An authenticated attacker with this role can retrieve the cleartext secret of any confidential client using the client-secret authenticator. Successful exploitation allows the attacker to obtain a client-credentials access token and exercise the target client's service account permissions. This issue represents an incomplete fix for CVE-2026-89298.
A flaw was found in the Admin REST installation provider endpoints and the Client Registration install endpoint in Keycloak. While the dedicated client-secret endpoint correctly enforces authorization, these specific endpoints fail to mask the client secret when accessed by a user with the realm-management:view-clients role. An authenticated attacker with this role can retrieve the cleartext secret of any confidential client using the client-secret authenticator. Successful exploitation allows the attacker to obtain a client-credentials access token and exercise the target client's service account permissions. This issue represents an incomplete fix for CVE-2026-89298.
Moderate: tftp security update