See how redhat compares to other vendors in security performance
A flaw was found in Red Hat Quay's Stripe billing webhook handler. The /webhooks/stripe endpoint at endpoints/webhooks.py accepts incoming JSON requests without validating the Stripe-Signature header, allowing an unauthenticated attacker to forge billing events. The endpoint is registered unconditionally, even when FEATUREBILLING is disabled. An attacker can forge charge.succeeded events to reset a namespace's build quota to the server-configured maximum and trigger unsolicited billing emails (invoice, payment-failed, subscription-change) to namespace administrators. The checkout.session.completed path calls stripe.SetupIntent.retrieve with attacker-controlled IDs, but subsequent mutations use values from Stripe's response rather than the attacker's payload. Impact is Medium-High for quay.io deployments with real Stripe integration and Low for self-hosted defaults using FakeStripe.
A flaw was found in Red Hat Quay's exported logs feature. An unauthenticated attacker with a valid file ID could download exported action logs without proper authorization. While file IDs are complex, they can be intercepted from plaintext email or webhook callbacks. This vulnerability leads to information disclosure, potentially exposing sensitive data such as usernames, email addresses, IP addresses, and action-specific metadata.
A flaw was found in Red Hat Quay. A user with FEATUREBUILDSUPPORT enabled and repository write access can exploit a Server-Side Request Forgery (SSRF) vulnerability within the build API. This allows the user to provide a malicious URL, causing the Quay builder to make requests to internal network addresses. Such an action could lead to the disclosure of sensitive internal information.
A flaw was found in Red Hat Quay. When the SECURITYSCANNERV4PSK (pre-shared key) is not set, a remote unauthenticated attacker can send POST requests to the security scanner notification endpoint. This allows the attacker to flood the notification queue and inject path traversal characters into Clair API URL paths. The primary consequence is worker resource exhaustion and blind path manipulation on the configured Clair host, potentially leading to a denial of service.
A privilege escalation flaw was found in FreeIPA. The uniqueness constraint enforced on Kerberos principal name attributes in the 389-ds directory server does not properly account for equivalent representations of the same principal name, allowing a user with sufficient LDAP write privileges to create a service principal that impersonates an existing privileged one. This can lead to unauthorized acquisition of Kerberos service tickets for sensitive services, potentially resulting in full domain compromise.
A flaw was found in FreeIPA. The trust-fetch-domains command, used to refresh Active Directory trust topology, is gated only by the read-level ACI on the trust object (System: Read Trust Information, granted to any authenticated IPA user by default) rather than a trust-administration-level permission. Any authenticated, non-privileged IPA user can therefore invoke ipa trust-fetch-domains, which calls a root-owned oddjobd/D-Bus helper (install/oddjob/com.redhat.idm.trust-fetch-domains.in). When the caller supplies --admin/--password, the helper calls kinitpassword() against a caller-chosen --server using attacker-supplied credentials, with no cross-check that they belong to the real trusted AD forest, then accepts whatever forest-trust topology (domain names, NetBIOS names, SIDs) that attacker-controlled server returns via ipaserver/dcerpc.py's fetchdomains()/discovertrustinstance(). This fabricated data is written directly into the IPA LDAP directory as authoritative trust/ID-range topology by trust.addnewdomainsfromtrust(). The authorization gap itself (an unprivileged, non-admin user's request reaching the root-owned helper's execution with no ACI rejection) was reproduced dynamically in an isolated sandbox against ipa-server-4.13.5, confirmed against a negative control (an unrelated admin-only operation was correctly rejected in the same session). The exploiting principal holds zero delegated privilege — this is not a case of a narrow administrative delegation being used beyond its intended scope.
A flaw was found in insights-client. The setDefault() function logs the value of every environment variable it processes, including CCXTOKEN, a bearer credential used in disconnected cluster deployments. When glog verbosity is set to level 2 or higher, the token is written in clear text to the pod log on every startup. An attacker with access to pod logs or centralized logging could obtain the credential, leading to unauthorized access to the CCX API.
IBM Informix Dynamic Server 14.10, and 15.0 contain a local privilege escalation vulnerability in the oninit setuid-root utility.
IBM Informix could allow an unauthenticated user to execute arbitrary commands with service account privileges on the system due to improper validation of user supplied input.
A flaw was found in insights-client. When the application receives a non-200 response, it logs the request headers, which can include the cloud.openshift.com pull-secret token. A local user with access to pod logs on the hub could read this long-lived credential. This information disclosure could grant unauthorized access to Red Hat cloud services.
A flaw was found in the SAML broker component of Keycloak, an identity and access management solution. When configured as a SAML broker using the IdP-Initiated flow, Keycloak fails to enforce the OneTimeUse condition in SAML assertions. This allows an attacker who captures a valid, unused assertion to replay it multiple times. Successful exploitation could allow an attacker to hijack a user's session and gain unauthorized access to the system as that user.
A flaw was found in SSSD. The extractauthtokv1() function in the PAM responder (src/responder/pam/pamsrvcmd.c) reads a 32-bit authtokenlength from the client request but does not validate it against the remaining buffer size before passing it to sssauthtoksetpassword(). When sssauthtoksetstring() processes the token, it accesses str[len-1] using the unvalidated length, resulting in a heap-buffer-overflow read. A local attacker can trigger this by connecting to the world-writable PAM responder socket (/var/lib/sss/pipes/pam) and sending a crafted protocol v1 authentication request with an oversized authtokenlength value. The stock PAM client uses protocol v3, so this is only reachable via raw socket access. Protocol v2 includes an equivalent bounds check (c+datasize > blen), which is missing from v1. Successful exploitation crashes the sssdpam responder, causing a denial of service for SSSD-mediated authentication. Reported via PSIRTSUPT-20553 by BreachX Zero Day Labs.
A Broken Access Control vulnerability was identified in Keycloaks Fine-Grained Admin Permissions V2 (FGAP V2) implementation. The flaw exists in the POST /admin/realms/{realm}/users endpoint, where the server fails to validate group membership permissions within the user creation payload. While Keycloak correctly enforces manage-membership scopes for existing users, it misses this check during the initial user creation process. A sub-administrator with user create scope but restricted group manage-membership scope can successfully assign a new user to unauthorized groups by including them in the creation request. Concrete impact: An attacker with sub-admin privileges can elevate the permissions of new users, grant them access to restricted data by placing them in sensitive groups, and bypass the security boundaries established by FGAP V2.
Summary
The koku-metrics-operator CostManagementMetricsConfig CRD exposes spec.prometheusconfig.serviceaddress as a free-form string with no host validation. The operator reads its own Kubernetes service-account token from /var/run/secrets/kubernetes.io/serviceaccount/token and configures it as the BearerToken for PromQL queries sent to this user-supplied address. The service-account token carries the manager-role ClusterRole, which grants get on all Secrets cluster-wide.
Impact
A principal with create/update permission on costmanagementmetricsconfigs in the operator namespace can harvest the operator's Kubernetes service-account token by redirecting Prometheus queries to an attacker-controlled endpoint. This token grants read access to every named Secret in any namespace across the cluster.
Affected Code
- api/v1beta1/metricsconfigtypes.go:198 — serviceaddress field definition (no validation) - internal/collector/prometheus.go:95-117 — token read and client configuration - config/rbac/role.yaml:18-22 — ClusterRole grants secrets:get cluster-wide
Remediation
Restrict serviceaddress to in-cluster Prometheus/Thanos endpoints via CRD CEL validation:
yaml x-kubernetes-validations: - rule: "url(self.serviceaddress).getHostname().endsWith('.openshift-monitoring.svc') || url(self.serviceaddress).getHostname().endsWith('.openshift-monitoring.svc.cluster.local')" message: "serviceaddress must target the in-cluster monitoring service"
Or use a TokenRequest API call with audience bound to prometheus-k8s so the token is not replayable against kube-apiserver.
Summary
The koku-metrics-operator CostManagementMetricsConfig CRD exposes spec.apiurl as a free-form string with no host allow-list or schema validation. When spec.authentication.type == token (the default), the operator reads the cluster-global openshift-config/pull-secret, extracts the cloud.openshift.com bearer token, and attaches it as Authorization: Bearer <token> on an outbound POST to the user-supplied URL. No comparison against the default https://console.redhat.com gates credential attachment.
Impact
A principal with create/update permission on costmanagementmetricsconfigs in the operator namespace can cause the operator to send the cluster's Red Hat Cloud / registry pull-secret bearer token to an arbitrary external or in-cluster endpoint. This credential authenticates the entire cluster to console.redhat.com and registry.redhat.io.
Affected Code
- api/v1beta1/metricsconfigtypes.go:249 — APIURL field definition (no validation) - internal/controller/costmanagementmetricsconfigcontroller.go:128,235,258,590 — credential extraction and URL construction - internal/crhchttp/httpclouddotredhat.go:94 — bearer token attachment to HTTP request
Remediation
Reject token authentication when apiurl != DefaultAPIURL. Add a CEL validation rule on the CRD:
yaml x-kubernetes-validations: - rule: "self.authentication.type != 'token' || self.apiurl == 'https://console.redhat.com'" message: "token authentication is only permitted against https://console.redhat.com"
Or implement the check in the reconciler before calling Upload().
A flaw was found in the Microsoft social identity provider in Keycloak. When a Microsoft identity provider is configured with a specific tenant ID, the restriction is correctly enforced for standard browser-based logins. However, the external access-token exchange endpoint fails to perform this validation. The root cause is that Keycloak calls the tenant-agnostic Microsoft Graph /me endpoint during the exchange process. It accepts the returned user profile and issues Keycloak tokens without verifying that the tenant associated with the original Microsoft token matches the configured tenant ID in the identity provider settings. An attacker with a valid Microsoft Graph access token from an arbitrary tenant can submit it to the Keycloak token exchange endpoint. Successful exploitation allows the attacker to bypass tenant restrictions, assume an identity within the Keycloak realm, and perform actions with the privileges of that identity, such as accessing protected resources or modifying user data.
A Missing Authorization vulnerability was identified in Keycloak Google Identity Provider implementation. The flaw exists in the external access-token exchange code path, which is used when the Token Exchange V1 feature is enabled. While the standard Google ID-token login flow correctly validates the hd hosted domain claim against the configured hostedDomain setting, the access-token exchange flow skips this validation. When an external access token is provided, Keycloak retrieves the user profile from the Google user-info endpoint but fails to verify that the domain associated with the user matches the restricted domain configured in the Identity Provider settings. An attacker with a valid Google access token for any domain can exploit this flaw if they have access to a confidential client authorized to perform token exchange. Successful exploitation allows the attacker to bypass domain restrictions, obtain a Keycloak access token, and potentially create or link a brokered identity that should have been restricted.
A flaw was found in the file-icns plugin in GIMP, affecting versions 2.99.14 and newer. When applying a decompressed mask during ICNS image processing, the plugin reads from the mask data buffer without verifying if the cursor exceeds the allocated resource size. If a crafted file contains a truncated mask resource, the icnsdecompress function continues reading past the bounds of the buffer. This out-of-bounds read vulnerability results in information disclosure of heap contents, where memory contents are leaked as alpha channel pixel values, or a crash leading to a denial of service if unmapped memory is accessed.
A flaw was found in the file-fits plugin in GIMP, affecting all versions. When processing a FITS image file, the plugin calculates memory allocation sizes using signed 32-bit integers for width and height. If a crafted file sets both values to large values, their product exceeds 2^31 and overflows, resulting in an undersized heap-based buffer allocation. This integer overflow issue results in a heap-based buffer overflow when cfitsio subsequently writes a full row of pixels in the buffer, causing memory corruption, potentially leading to arbitrary code execution or a denial of service.
A flaw was found in libsoup. The chunked transfer encoding parser uses a permissive parsing function for chunk sizes that silently accepts inputs violating RFC 9112, including leading whitespace, plus sign prefixes, and trailing invalid characters. When libsoup operates behind a strict frontend proxy, this parsing differential can be exploited to smuggle HTTP requests.
A configuration-dependent issue in rsyslog's optional imptcp input module can allow an unauthenticated remote peer to crash rsyslogd. The issue is not active in a default installation. Exploitation requires all of the following:
imptcp is explicitly loaded. An imptcp listener uses the non-default framing.delimiter.regex mode. An attacker can establish a TCP connection to that listener.
A crafted input sequence during oversize-frame recovery can cause an invalid internal message length and terminate rsyslogd. No confidentiality or integrity impact, privilege escalation, or code execution has been identified. imtcp and the default imptcp framing modes are not affected.
A flaw was found in Keycloak where the default Dynamic Client Registration (DCR) policy permits the use of User Property mappers without validating the target claim path. While the policy checks the mapper provider type, it does not restrict where the mapper can write data within the resulting token. An attacker with a standard user account and a limited Initial Access Token (IAT) can register a new client and configure User Property mappers (such as firstName or lastName) to target the resourceaccess.realm-management.roles claim path. By setting their user profile properties to administrative role names (e.g., manage-clients, realm-admin), the attacker can produce a forged access token containing these roles. Although recent mitigations (CVE-2026-4629) protect the Admin REST API from such forged tokens, the Client Registration API remains vulnerable because it reads the resourceaccess claim directly during authorization. An attacker can use this bypass to perform unauthorized DCR operations, including reading confidential client secrets, modifying redirect URIs, and impersonating service accounts to achieve full realm compromise.
A flaw was found in 389 Directory Server (389-ds-base). The getruvelementfromberval() function in ldap/servers/plugins/replication/repl5ruv.c copies digit characters from a network-supplied RUV berval into a fixed 16-byte stack buffer (ridbuff[RIDSTRSIZE]) without bounds checking the loop counter. A remote unauthenticated attacker can crash the ns-slapd process by sending a crafted StartNSDS50ReplicationRequest LDAP extended operation (OID 2.16.840.1.113730.3.5.12) containing more than 16 consecutive digit characters in the replica ID field. The overflow occurs during payload decoding in decodestartreplextop(), before the replicaisupdatedn() authorization check runs, making it exploitable without credentials on default configurations where anonymous access is enabled. On production builds with stack protectors, the impact is limited to denial of service (process abort). The vulnerable code path is: decodestartreplextop() -> decoderuv() -> ruvinitfrombervals() -> getruvelementfromberval().
A flaw was found in Keycloak's Authorization Services. The component responsible for matching request paths to security policies (PathMatcher) does not properly normalize URIs before comparison. By adding extra characters like a trailing slash or matrix parameters to a URL, an attacker can trick the system into applying a less restrictive security policy than intended. This allows an authenticated user to access administrative or restricted areas they should not have permission to see.
A flaw was found in Keycloak's Dynamic Client Registration (DCR) security policy management. The "Allowed Protocol Mapper Types" policy, which restricts which types of data mappers a client can use, fails to re-validate the mapper type during a client update if the mapper's configuration remains unchanged. An attacker with client registration privileges can exploit this by first registering an allowed mapper type with a malicious configuration and then swapping it for a restricted, high-privilege mapper type (such as one that hardcodes administrative roles). This allows the attacker to gain full administrative access to the Keycloak realm.
A flaw was found in libssh server-side SFTP directory listing. In processreaddir() in src/sftpserver.c, the server allocates a fixed stack buffer as char longname[MAXLONGNAMELEN] and passes attacker-controlled directory entry names into readdirlongname(). In the pre-patch implementation, readdirlongname() appends metadata and the filename into zlongname with repeated unbounded strcat() calls. Because zlongname points at the caller-owned fixed stack buffer, sufficiently long filenames in an attacker-controlled directory can overflow that stack buffer during SSHFXPREADDIR processing, leading to crashes and possible code execution on the server.
A flaw was found in libssh builds using the OpenSSL backend for AES-GCM. In the decrypt path in src/libcrypto.c, the return value from EVPDecryptFinal() was checked incorrectly, so authentication tag verification failures were not handled as integrity failures. This could effectively remove integrity protection for affected AES-GCM sessions and allow an in-path attacker to modify plaintext on the wire without detection.
A flaw was found in libssh server-side GSSAPIKeyExchange authorization. In sshpacketuserauthrequest() in src/messages.c, the gssapi-keyex login path granted success after Kerberos authentication without dispatching the callback that verifies whether the authenticated principal is authorized for the requested local user. On servers with GSSAPIKeyExchange enabled, an authenticated client can therefore log in as an arbitrary local user if the missing principal-to-user authorization check is relied upon for access control.
A flaw was found in libssh automatic certificate-based public key authentication. In sshuserauthpublickeyauto() in src/auth.c, the iterator over certificate candidates was not advanced correctly when configured certificates were missing or repeatedly rejected by the server. Under specific non-default certificate configurations, this could cause the client to restart the same authentication attempts indefinitely, leading to denial of service.
A flaw was found in libssh channel data handling. In channelrcvdata() in src/channels.c, incoming channel DATA messages could still be processed after the channel had already been marked as remotely closed. In SFTP-backed applications and other callback-driven consumers, this creates a path where data callbacks may observe channel-associated state after it has already been torn down or freed, leading to crashes and possible use-after-free conditions.