CVE-2026-77874 — Enterprise Build Of Quarkus
HIGHCVE-2026-77874 is a high-severity (CVSS 8.6) SQL Injection vulnerability in ibm enterprise build of quarkus. No vendor fix is recorded yet; mitigation options are listed below.
IBM Enterprise Build of Quarkus 3.27.1 through 3.27.5.SP1, and 3.33.1 through 3.33.3.SP1 is vulnerable to SQL injection. A remote unauthenticated attacker could send specially crafted…
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-77874.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-77874 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 386,684 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Description
IBM Enterprise Build of Quarkus 3.27.1 through 3.27.5.SP1, and 3.33.1 through 3.33.3.SP1 is vulnerable to SQL injection. A remote unauthenticated attacker could send specially crafted SQL statements, which could allow the attacker to view, add, modify, or delete information in the back-end database.
Affected Products
enterprise build of quarkusibmDetection & mitigation playbook
Vendor / applianceDetect
Inventory every ibm enterprise build of quarkus deployment and check each version against the affected-products list above.
Remediation status
No patch has shipped for CVE-2026-77874 yet — track the ibm enterprise build of quarkus advisory for a fixed release and apply the workarounds below in the meantime.
Mitigate without a patch
Until you can upgrade, make sure every query built from user input uses parameterised statements or a prepared-statement API rather than string concatenation, and reduce the database account's privileges so an injected query cannot read or alter data beyond what the feature needs. Alongside that, restrict the management interface to trusted networks and apply the vendor's recommended configuration mitigations.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This flaw is rated as Important. An authenticated remote attacker can bypass authorization controls and exfiltrate data from the underlying database by injecting SQL through the JSON path parameter in Hibernate ORM. This is due to improper escaping of the leading JSON path segment in certain database dialects, which…
To mitigate this vulnerability, applications using Hibernate ORM should avoid passing untrusted user-controlled input directly as JSON path arguments to `json_query`, `json_exists`, or `json_value` functions. If dynamic JSON querying is necessary, strictly validate or whitelist the JSON path input against a predefined pattern (e.g., allowing only alphanumeric characters and dots) before use.Source: Red Hat security advisory for CVE-2026-77874 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2026-77874 being exploited in your environment?
Detect and block the exploit chain at execution, on systems you cannot patch yet.