RHSA-2026:11721HighCVSS 8.2

Red Hat Security Advisory: Red Hat build of Quarkus 3.27.3.SP1 security update

Published
May 5, 2026
Last Modified
August 17, 2026

🔗 CVE IDs covered (5)

CVE-2026-0636 →CVE-2026-5588 →CVE-2026-35554 →CVE-2026-39852 →CVE-2025-14813 →

📋 Description

CVE-2025-14813 — bouncycastle: BC-JAVA: GOSTCTR implementation unable to process more than 255 blocks correctly CVE-2026-0636 — bouncycastle: BC-JAVA: LDAP injection vulnerability in LDAPStoreHelper.java CVE-2026-5588 — bouncycastle: BC-JAVA: PKIX draft CompositeVerifier accepts empty signature sequence as valid CVE-2026-35554 — Apache Kafka Clients: Apache Kafka Clients: Information disclosure and data corruption due to race condition in producer buffer management CVE-2026-39852 — io.quarkus:quarkus-vertx-http: io.quarkus:quarkus-vertx-http: Authorization bypass via semicolons in HTTP requests

🎯 Affected products1

  • Red Hat build of Quarkus 3.27.3.SP1

✅ Remediation

Before applying this update, make sure all previously released errata relevant to your system have been applied. For details on how to apply this update, refer to: https://access.redhat.com/articles/11258 Workaround: To mitigate this vulnerability, strictly limit the payload encrypted under a single key and Initialization Vector (IV) pair using the GOSTCTR implementation and G3413CTRBlockCipher to a maximum of 255 blocks. Alternatively, transition to a more secure, standardized and authenticated encryption mode. Workaround: To mitigate this flaw, sanitize all user-supplied input to remove or escape LDAP special characters before passing it to the LDAPStoreHelper for directory queries. If the input contains unexpected metacharacters such as asterisks, parentheses or backslashes, reject the request or escape the characters. Workaround: To mitigate this flaw, check that the signature sequence is not empty before passing any data to the CompositeVerifier for cryptographic validation. If the sequence is empty or null, explicitly reject the payload before it is processed. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability. Workaround: To mitigate this issue, configure a reverse proxy or load balancer in front of the Quarkus application to normalize incoming URL paths by stripping matrix parameters (semicolons) before requests reach the Quarkus security layer. This ensures that authorization checks are performed on the intended path. Ensure that any changes to proxy configurations are thoroughly tested and services are reloaded or restarted as necessary to apply the new settings.

🔗 References (6)