| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to perform unauthorized actions due to improper configuration of HTTP method-based security constraints. |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote authenticated attacker to execute arbitrary code due to improper validation of a specified quantity. |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow an adjacent-network attacker to execute arbitrary code due to deserialization of untrusted data. |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a local attacker to obtain sensitive information and perform unauthorized actions due to insufficiently protected credentials. |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a local attacker to gain unauthorized access to sensitive information and modify transaction data due to the use of hard-coded credentials. |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote authenticated attacker to gain elevated privileges due to improper privilege management. |
| A flaw was found in Foreman. The Red Hat Satellite /unattended/provision API endpoint is vulnerable to an authentication bypass due to a semantic logic flaw in host_verifier.rb. The application verifies the database state of a provisioning token rather than its actual presence in the incoming HTTP request. Because a host actively undergoing provisioning has an unexpired token in the database, the server's valid_host_token? method evaluates to true, granting access to the kickstart template even if the requester provides no token at all in the URL. |
| A flaw was found in Foreman. OS command injection vulnerabilities exist in the foreman-rake db:dump and db:import_dump tasks. The application fails to properly sanitize user-supplied input in the destination parameter (during backups) and the file parameter (during imports) before passing them to a Ruby system() call for execution. An attacker with permissions to execute foreman-rake (e.g., via a restricted sudo configuration) can append malicious shell commands to the provided file paths. |
| A flaw was found in Foreman. A command injection vulnerability exists in the foreman-rake errors:fetch_log task. The request_id parameter is passed to an underlying system command (typically grep) without adequate shell neutralization. While the task is intended to fetch specific log entries, an attacker with sudo permissions to execute this rake task can inject shell metacharacters (such as ;, ", or |) to break out of the intended command and execute arbitrary code. |
| A flaw was found in Foreman. The foreman-rake initialization logic in /usr/share/foreman/config/settings.rb contains a vulnerable code pattern where configuration data is processed through two distinct executable layers. This creates a multi-stage execution chain that allows for both Server-Side Template Injection (SSTI) and insecure deserialization. This vulnerability can lead to remote code execution, total infrastructure compromise and supply chain risk. |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote authenticated attacker to obtain sensitive information due to improper restriction of XML external entity references. |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a local attacker to execute arbitrary commands due to the inclusion of functionality from an untrusted control sphere. |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a local attacker to obtain sensitive information and trigger unauthorized actions due to server-side request forgery. |
| A vulnerability was found in the quarkus-core component. Quarkus captures local environment variables from the Quarkus namespace during the application's build, therefore, running the resulting application inherits the values captured at build time. Some local environment variables may have been set by the developer or CI environment for testing purposes, such as dropping the database during application startup or trusting all TLS certificates to accept self-signed certificates. If these properties are configured using environment variables or the .env facility, they are captured into the built application, which can lead to dangerous behavior if the application does not override these values. This behavior only happens for configuration properties from the `quarkus.*` namespace. Application-specific properties are not captured. |
| A vulnerability was found in Undertow where the ProxyProtocolReadListener reuses the same StringBuilder instance across multiple requests. This issue occurs when the parseProxyProtocolV1 method processes multiple requests on the same HTTP connection. As a result, different requests may share the same StringBuilder instance, potentially leading to information leakage between requests or responses. In some cases, a value from a previous request or response may be erroneously reused, which could lead to unintended data exposure. This issue primarily results in errors and connection termination but creates a risk of data leakage in multi-request environments. |
| A flaw was found in Quay. When handling build trigger requests, the application incorrectly exposes trigger configuration details containing repository write tokens to global read-only administrative users. An authenticated user with read-only privileges can exploit this flaw by querying the build trigger API to retrieve these delegate tokens. This issue allows a restricted user to bypass read-only limitations and push arbitrary container images to private repositories, leading to privilege escalation. |
| A flaw was found in sssd. A local attacker can trigger a Denial of Service (DoS) by sending a specially crafted Pluggable Authentication Module (PAM) request when passkey authentication is enabled. Due to a missing state validation check in passkey Kerberos handling, the PAM responder dereferences an uninitialized pointer and crashes. This failure disrupts authentication services on the host. |
| A flaw was found in SSSD. A local user can cause a denial of service (DoS) by disrupting system authentication services. When handling Generic Security Services Application Programming Interface (GSSAPI) authentication in the Pluggable Authentication Module (PAM) responder, cached connection state is freed upon completion without clearing the reference pointer. An attacker can exploit this by sending an additional request over the same connection, causing the service to access invalid memory and unexpectedly terminate. |
| A flaw was found in SSSD. An issue in the Kerberos Credential Manager (KCM) responder allows a local user to cause a Denial of Service (DoS) by maintaining a persistent connection and repeatedly storing and destroying credentials. Because the service fails to release cached objects from memory when credentials are removed, memory consumption grows continuously, ultimately exhausting available memory and rendering the service unresponsive. |
| Issue summary: The first concurrent use of the same X.509 certificate by
several threads may cause its cached extension data to be freed while
another thread is still using it.
Impact summary: A remote, unauthenticated peer could crash a multi-threaded
TLS client, or a multi-threaded TLS server that requests client
certificates, if the first certificate chains built to the same trusted CA
certificate are built by several connections at the same time. This is a
use-after-free read, which is likely to crash the process, resulting in a
Denial of Service.
CWE: CWE-416: Use After Free
Description: OpenSSL caches the decoded values of a certificate's X.509v3
extensions inside the X509 object the first time they are needed. In
OpenSSL 4.0 this cache is built in two phases: the extension values are
computed while holding a read lock on the certificate, and the results are
then installed into the certificate under a write lock. Because a read lock
does not exclude other readers, several threads can compute the cache for
the same certificate at the same time. Each thread that subsequently
acquires the write lock installs its own results and frees the values
installed by the thread before it, even though that earlier thread has
already marked the cache as complete and may have returned pointers into it
to its caller. A caller still using those pointers then reads freed memory.
Any certificate shared between threads is exposed the first time its
extensions are decoded. In TLS the certificates at risk are the trusted CA
certificates supplied for chain verification, by whatever means, since these
are shared by every connection and their extensions are decoded and cached
the first time a chain is built to them. Certificates sent by the peer are
decoded separately for each connection and are not shared, so they are not
affected. In a TLS client verifying server certificates, or a TLS server
that requests and verifies client certificates, the use-after-free could
only occur if the first chains built to the same trusted CA are built by
several connections at the same time.
FIPS impact: no
The FIPS module is not affected as X.509 certificate handling is outside
of the OpenSSL FIPS module boundary.
OpenSSL 4.0 is vulnerable to this issue.
OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are not affected by this issue.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3.
This issue was reported on 27 August 2026 by Tim Becker (Xint.io) and
independently in a public report on 31 August 2026 by aydinmercan.
The fix has been developed by Bob Beck.
-- cut (non-publishing metadata for internal use) --
Reported by: Tim Becker (Xint.io), aydinmercan
Fixed by: Bob Beck |
