Quarkus ships three maintenance updates for five CVEs, including remote code execution and file-read flaws

Quarkus has released 3.39.2, 3.33.3.2 LTS and 3.27.5.2 LTS to address five CVEs across its current and long-term-support lines. Although the project describes the updates as maintenance releases and says 3.39.2 should be a safe upgrade for applications already on 3.39, the vulnerability set makes this more than a routine patch notice.

What changed

The release fixes CVE-2026-12894, CVE-2026-17615, CVE-2026-19625, CVE-2026-19651 and CVE-2026-76763, alongside other bug fixes and documentation changes, according to the Quarkus announcement.

The published descriptions include distinct attack preconditions. CVE-2026-12894 is a Qute template-engine bypass: an attacker who can provide or influence template text can reach Java internals and execute unauthorized commands. Red Hat’s CVSS vector rates it PR:L, meaning low privileges are required; it should not be described as an unauthenticated path. CVE-2026-17615 is an unauthenticated XML external-entity flaw in RESTEasy’s SourceProvider that can expose local file contents when an application accepts crafted XML and returns a Source or StreamSource.

A third issue, CVE-2026-76763, lets an unauthenticated attacker send a GraphQL number with a very large exponent to trigger CPU exhaustion or an out-of-memory condition in SmallRye GraphQL. Red Hat scored that denial-of-service issue 7.5, high severity, in the NVD record.

Who is affected

The exposure depends on which extensions and application paths are enabled. Qute applications are at risk where an attacker with low privileges can provide or influence template text; the RESTEasy flaw requires the relevant XML endpoint shape; and the GraphQL issue applies to services using the affected numeric coercion path.

The NVD records also identify affected Red Hat products beyond upstream Quarkus. The Qute record names Red Hat build of Quarkus and Red Hat build of Apache Camel for Quarkus, while the RESTEasy record names those products as well as Red Hat build of Keycloak, Apicurio Registry and Debezium. That does not mean the upstream Quarkus version numbers are the supported remediation versions for every downstream product.

What to do

Teams already on Quarkus 3.39 should move to 3.39.2; teams on the supported LTS branches should evaluate 3.33.3.2 or 3.27.5.2, following the project’s upgrade guidance. Before rollout, inventory Qute, RESTEasy XML and SmallRye GraphQL use, then prioritize internet-facing services and endpoints that accept untrusted templates, XML or GraphQL input.

Users of Red Hat productized builds should follow the corresponding Red Hat advisory and package stream rather than substituting an upstream artifact. The affected-product data spans multiple Red Hat middleware products, so each deployment needs a product-specific remediation check.