dbcve.org
Build Of QuarkusApplication · Redhat

CVE-2022-4492

HIGH · 7.5 CVSS v3.1 Published 2023-02-23
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
84/100
Remediation priority · High
Remotely reachable No privileges Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
The undertow client is not checking the server identity presented by the server certificate in https connections. This is a compulsory step (at least it should be performed by default) in https and in http/2. I would add it to any TLS client protocol.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

The Undertow HTTP client does not perform server identity verification (hostname validation) on TLS certificates when establishing HTTPS connections. This allows man-in-the-middle attacks where an attacker can present an arbitrary certificate and the client will accept it, bypassing TLS security guarantees.

MitigationEnable proper hostname verification in the Undertow client SSL configuration or upgrade to a version that enforces certificate identity validation by default.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
Build Of QuarkusApplication
Affected:all versions
Integration Camel For Spring BootFramework / library
Affected:all versions
Integration Camel KApplication
Affected:all versions
Integration Service RegistryApplication
Affected:all versions
Jboss Enterprise Application PlatformApplication
Affected:= 7.0.0
Jboss FuseApplication
Affected:= 7.0.0
Migration Toolkit For ApplicationsApplication
Affected:= 6.0
Migration Toolkit For RuntimesApplication
Affected:all versions

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify Undertow HTTP client usage
    Search for undertow-core dependency in project pom.xml/build files or look for org.xnio.nio, io.undertow.client, or UndertowClient imports in Java source code
    Affected if Undertow HTTP client library is present in the application
  2. Verify HTTPS client connections are used
    Review application code for HTTP client requests to https:// URLs, or inspect network traffic/SSL session logs for outbound HTTPS calls from the Undertow client
    Affected if The application makes outbound HTTPS connections using the Undertow client
  3. Inspect SSL TrustManager configuration
    Search codebase for SSLContext creation - look for custom TrustManager implementations or TrustManagerFactory.getInstance calls that may bypass standard certificate validation
    Affected if A custom TrustManager is configured that does not perform hostname validation
  4. Check hostname verifier configuration
    Search for Undertow SSLEndpoint or SSLClientAuthMode configuration; look for AnyTrustHostnameVerifier or NO_VERIFY settings in the client SSL configuration code
    Affected if Hostname verification is disabled or set to trust any certificate in the Undertow client SSL setup
  5. Review Undertow client builder configuration
    Search for UndertowClientBuilder or XnioWorker configuration where .setSslOption(UndertowOptions.ENABLE_SSL, true) is used without StrictHostnameVerifier or equivalent
    Affected if Undertow client SSL is enabled without proper hostname verification enforcement

A user is affected if their application uses the Undertow HTTP client to make HTTPS connections and the SSL configuration lacks proper hostname validation, allowing arbitrary certificates to be accepted.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Enable proper hostname verification in the Undertow client SSL configuration or upgrade to a version that enforces certificate identity validation by default.

Recommended fix Moderate confidence
  1. Ensure SSL/TLS hostname verification is enabled in the undertow client configuration
  2. For Java/Quarkus applications, set the system property 'https.verify.hostname' to 'true' or configure the SSLContext with a TrustManager that validates server identity
  3. For Camel Spring Boot integrations, configure the HTTP client to use standard hostname verification: set 'sslContextParameters' with proper TrustManager configuration
  4. For Camel K integrations, ensure the TLS configuration includes endpoint identification algorithm (e.g., HTTPS) in the SSLParameters
  5. For JBoss EAP/Fuse, configure the https connector with 'verify-host' attribute set to 'true' in the undertow subsystem configuration
  6. Alternatively, upgrade to a JBoss Enterprise Application Platform version that includes the fix for CVE-2022-4492
Caveat Enabling hostname verification may cause connection failures if server certificates are improperly configured (e.g., missing Subject Alternative Names for used hostnames); such servers would need certificate remediation

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Build Of Quarkus Scoped from the published advisory
  • Consultation2.0 h
  • Implementation4.0 h
  • Testing4.0 h
  • Review / QA2.0 h
12.0 hours of engineering $2,080
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,328.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2022-4492 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2022-4492 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data