CVE-2022-31684 Overview
Reactor Netty HTTP Server contains an information disclosure vulnerability in versions 1.0.11 through 1.0.23. The HTTP server component may log request headers in certain cases when processing invalid HTTP requests. When WARN level logging is enabled, the logged headers may inadvertently reveal valid access tokens to unauthorized parties who have access to server logs. This vulnerability specifically affects environments where invalid HTTP requests occur and WARN level logging is configured.
Critical Impact
Access tokens and other sensitive authentication credentials in HTTP request headers may be exposed in server logs, potentially enabling unauthorized access to protected resources.
Affected Products
- Pivotal Reactor Netty versions 1.0.11 through 1.0.23
- Applications using affected Reactor Netty HTTP Server components
- Spring WebFlux applications leveraging vulnerable Reactor Netty versions
Discovery Timeline
- 2022-10-19 - CVE-2022-31684 published to NVD
- 2025-05-09 - Last updated in NVD database
Technical Details for CVE-2022-31684
Vulnerability Analysis
This vulnerability falls under CWE-532 (Insertion of Sensitive Information into Log File). The Reactor Netty HTTP Server, a non-blocking I/O library commonly used in reactive Java applications including Spring WebFlux, improperly handles logging during the processing of malformed or invalid HTTP requests. When the server encounters such requests and WARN level logging is enabled, the logging mechanism captures and persists HTTP request headers to log files without adequate sanitization.
The exposure occurs because authentication tokens, session identifiers, API keys, and other sensitive credentials are commonly transmitted via HTTP headers such as Authorization, X-Auth-Token, or custom authentication headers. These values are written to log files in plaintext, creating a persistent record of sensitive authentication material.
Root Cause
The root cause stems from inadequate input sanitization in the logging pathway for error conditions. When the Reactor Netty HTTP Server processes invalid HTTP requests and triggers warning-level log entries, the logging logic fails to redact or filter sensitive header values before writing them to log output. This represents a violation of secure logging practices where authentication credentials should never be persisted in logs regardless of the request validity state.
Attack Vector
The attack vector is network-based and requires low privileges to exploit. An attacker with access to server log files (either through legitimate administrative access, log aggregation systems, or through a separate vulnerability that exposes logs) can harvest valid authentication tokens from logged entries.
The attack scenario involves:
- An attacker or legitimate user sends malformed HTTP requests to the vulnerable server
- The Reactor Netty HTTP Server logs the invalid request at WARN level, including full headers
- An adversary with log access retrieves the logged authentication tokens
- The attacker uses the harvested tokens to impersonate legitimate users or access protected resources
The vulnerability does not require user interaction and the impact is limited to confidentiality exposure of authentication credentials present in the logged headers.
Detection Methods for CVE-2022-31684
Indicators of Compromise
- Presence of authentication headers (e.g., Authorization, Bearer tokens) in server log files
- Unusual access patterns to log files or log aggregation systems
- Authentication anomalies where tokens are used from unexpected IP addresses
- Evidence of log file exfiltration or unauthorized log access
Detection Strategies
- Audit server log files for presence of sensitive header values such as Authorization, Bearer, X-Auth-Token
- Monitor log aggregation systems for queries targeting authentication-related content
- Implement file integrity monitoring on log directories to detect unauthorized access
- Review application dependencies for Reactor Netty versions between 1.0.11 and 1.0.23
Monitoring Recommendations
- Enable alerting on log file access by unauthorized users or service accounts
- Monitor for high volumes of invalid HTTP requests that could trigger vulnerable logging paths
- Track token usage patterns to identify credential reuse from unexpected sources
- Implement centralized logging with access controls and audit trails
How to Mitigate CVE-2022-31684
Immediate Actions Required
- Upgrade Reactor Netty to version 1.0.24 or later which addresses this vulnerability
- Audit existing log files for exposed authentication tokens and rotate any potentially compromised credentials
- Review and restrict access to server log files and log aggregation systems
- Consider temporarily reducing logging level below WARN until patching is complete
Patch Information
VMware has released a security update addressing this vulnerability. Refer to the VMware Security Advisory CVE-2022-31684 for official patch information and upgrade guidance. Organizations should upgrade to Reactor Netty version 1.0.24 or later.
For Maven-based projects, update the dependency version in pom.xml. For Gradle projects, update the version in build.gradle. Spring Boot applications should verify their transitive dependency versions through dependency management.
Workarounds
- Reduce logging verbosity below WARN level for Reactor Netty components to prevent sensitive header logging
- Implement log filtering or redaction rules to mask authentication headers before persistence
- Restrict access to server logs to only essential personnel and systems
- Rotate all authentication tokens that may have been logged during the vulnerable period
# Configuration example
# For Spring Boot applications, reduce Reactor Netty logging level
# Add to application.properties or application.yml
# application.properties
logging.level.reactor.netty=ERROR
# Or in logback-spring.xml, add log filtering
# <filter class="ch.qos.logback.core.filter.EvaluatorFilter">
# <evaluator class="ch.qos.logback.classic.boolex.JaninoEventEvaluator">
# <expression>return message.contains("Authorization");</expression>
# </evaluator>
# <onMatch>DENY</onMatch>
# </filter>
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


