Quarkus 3.33.3.SP1 closes authentication, template and transport flaws
The Important-rated service pack fixes 13 CVEs across common Quarkus extensions; teams should update the platform BOM and retest the features they actually ship.
Red Hat has issued an Important security update for the 3.33 long-term support stream of Red Hat build of Quarkus. RHSA-2026:62555, published September 3, moves the supported release to 3.33.3.SP1 and lists 13 CVEs.
This is not one defect repeated across packages. The advisory reaches several application-facing parts of a Quarkus stack, so the practical exposure depends on which extensions an application includes.
What the service pack fixes
The most direct application-security fixes are in Quarkus itself. Qute’s ReflectionValueResolver receives a fix for server-side template injection, the OIDC extension fixes a cross-tenant authentication bypass involving its shared token-introspection cache, and the Spring Web compatibility layer closes an authorization bypass using URL query-string manipulation. RESTEasy fixes an unauthenticated remote file-read issue in SourceProvider.
The dependency fixes broaden the review. Apache HttpComponents Client addresses both a connection-leak denial of service and improper TLS hostname verification that could permit server impersonation. Netty fixes a CORS Vary header disclosure issue and an OpenSSL client-path hostname-verification bypass. The MongoDB driver removes credential disclosure during client initialization.
Messaging and API stacks are also represented: SmallRye GraphQL fixes a denial of service using large-exponent floating-point literals, while Apache Qpid Proton-J fixes three separate denial-of-service paths involving nesting, allocation and symbol caching.
Who should prioritize the update
Teams should move fastest where applications use Qute with data that can influence template evaluation, multi-tenant OIDC, quarkus-spring-web, RESTEasy SourceProvider, outbound Apache HTTP clients, MongoDB, GraphQL or AMQP. Netty is foundational enough that teams should not assume they are unaffected merely because it is not declared directly in an application build.
Red Hat identifies the affected product as the Red Hat build of Quarkus 3.33 text-only advisory stream. The advisory does not publish a workaround; its solution is to apply the update after previously released relevant errata.
Upgrade and verification checklist
- Record the current Quarkus platform BOM and extension list before changing the build.
- Align the application to the Red Hat 3.33.3.SP1 platform artifacts rather than overriding individual transitive libraries. That avoids mixing tested and untested component versions.
- Rebuild from a clean dependency cache and inspect the resolved dependency tree for the affected HTTP client, Netty, MongoDB, SmallRye GraphQL and Proton-J components your application uses.
- Run focused regression tests for tenant isolation, route authorization, template rendering, file-producing REST endpoints, outbound TLS hostname verification and message parsing as applicable.
- Rebuild container images and generate a fresh software bill of materials; updating source metadata without replacing deployed artifacts does not remediate running workloads.
- Deploy through a staged environment, then verify the running image digest and application build metadata rather than relying only on a successful CI job.
The breadth of this service pack makes extension-aware testing more useful than a generic smoke test. The update target is one release, but the verification plan should follow the application’s actual dependency graph.
sources
comments · 0