CVE-2026-47845

Executive Summary

CVE-2026-47845 is a security flaw in Broadcom's Reactor Netty HTTP Server component that causes incorrect remote IP address evaluation when the HAProxy Protocol is enabled. An unauthenticated, network-adjacent attacker can exploit this vulnerability to spoof or misrepresent the true source IP address of incoming connections, potentially circumventing IP-based access controls and authentication mechanisms. Affected versions include Reactor Netty 1.3.0 through 1.3.6, 1.1.0 through 1.2.18, and 1.0.52 and earlier. Given the CVSS score of 5.3 (Medium severity) and the integrity impact (I:L), enterprises running Reactor Netty-based microservices behind HAProxy should prioritize validation of their deployment configurations and apply the vendor patch upon release.

Technical Analysis

The vulnerability resides in the HTTP server component of Reactor Netty, specifically in the code path responsible for resolving and evaluating the remote IP address of incoming connections when the server is configured to use the HAProxy Protocol. The HAProxy Protocol (PROXY protocol) is a standard used by load balancers and proxies to pass the original client connection information (source IP, destination IP, source port, destination port) to the backend server across the TCP connection.

Vulnerability Mechanism: The flaw arises from an incorrect evaluation logic within Reactor Netty's handling of the PROXY protocol header. In specific scenarios — the exact nature of which is not fully detailed in the public description — the server incorrectly assigns or retains the remote address information. This can occur due to improper parsing of the PROXY protocol header, mishandling of the connection's remote address metadata after the PROXY header is processed, or failure to properly distinguish between the proxy's connection address and the forwarded client address contained within the protocol header.

Root Cause Class (CWE-290: Authentication Bypass by Spoofing): This weakness classification indicates that the flaw allows an attacker to bypass an authentication mechanism by spoofing the identity of another entity. In this context, the "authentication" is the server's trust in the source IP address. Because the server fails to correctly evaluate the remote IP address, it may treat the address supplied via the PROXY protocol header as the definitive client address without sufficient validation, or conversely, it may misattribute the proxy's actual socket address to the client.

Attack Surface: The attack surface is limited to deployments where:

1. Reactor Netty HTTP Server is used (a reactive, non-blocking HTTP server built on Netty).
2. The application explicitly enables HAProxy Protocol support (e.g., ForwardedHeaderHandler or PROXY protocol configuration).
3. The PROXY protocol-enabled listener is exposed to untrusted networks.

In standard configurations, the PROXY protocol is typically used only when the server is placed behind a trusted reverse proxy or load balancer (e.g., HAProxy, NGINX, AWS ELB). If the server port accepting PROXY protocol connections is directly reachable by clients (bypassing the legitimate proxy), the vulnerability becomes exploitable.

Affected Configurations: The NVD description lacks code-level specifics regarding which function or class contains the flaw. Insufficient technical detail is available to pinpoint the exact implementation component. However, the vulnerability class suggests the logic resides within the connection initialization or channel read handler functionality that parses the PROXY v1/v2 header and subsequently updates the remote address attribute represented in the server's HTTP request context.

Exploitation Scenarios

No public PoC is available; the attack chain is inferred from the vulnerability class (CWE-290) and NVD description. The following is a hypothetical attack scenario based strictly on the described flaw:

Step 1 — Reconnaissance / Target Identification: The attacker identifies an external-facing Reactor Netty HTTP Server that terminates PROXY protocol connections. Indicators include: the service responding on a non-standard high port (commonly 8080+), response headers revealing Spring Boot/Netty/Reactor fingerprints, or error messages indicating a reverse proxy layer is expected. Shodan/Censys queries for product:"Reactor Netty" or detection of Netty-specific response headers may assist. Importantly, the attacker must determine whether the PROXY protocol listener is directly reachable.

Step 2 — Triggering the Flaw: The attack is triggered by sending a specially crafted TCP connection to the Reactor Netty server with a forged PROXY protocol header. When a legitimate connection comes through the proxy (e.g., HAProxy), the proxy rewrites the TCP connection and prepends a PROXY protocol header containing the original client IP. By crafting a direct connection and prepending a malformed or spoofed PROXY header, the attacker aims to confuse the server's remote address resolution logic.

Specific trigger mechanisms could include:

• Sending a PROXY v1 header with an extremely long or malformed source address field that overflows or misaligns parser state.
• Sending an invalid protocol family (e.g., UNKNOWN) with mismatched address lengths.
• Sending multiple PROXY headers in sequence, where a second header is crafted to override the first (if the parser permits multiple headers).
• Sending a PROXY header where the address format is semantically valid but inconsistent with the actual TCP connection metadata.

Step 3 — Payload / Execution Method (vulnerability-class level): At the class level, this is an authentication bypass by IP spoofing. The attacker sends a PROXY protocol header with a forged source IP (e.g., PROXY TCP4 127.0.0.1 10.0.0.5 45678 80 for a v1 header). Subsequent to the header being processed, the server's remote-address accessor returns the attacker-supplied IP address.

Step 4 — Post-Exploitation Impact: Once the attacker controls how the server resolves the remote IP, they can:

• Bypass IP-based allowlists or trust boundaries — accessing administrative endpoints restricted to internal management IP ranges.
• Evade rate-limiting mechanisms that key on client IP.
• Bypass log-based audit trails by poisoning access logs with spoofed addresses.
• Circumvent security analytics that flag connections from known-bad IPs (e.g., threat intelligence blocklists).
• In multi-tenant applications, impersonate a trusted CIDR prefix used for privileged API access.

The impact is limited to an integrity violation of IP-based access control logic; confidentiality and availability are not directly affected (per CVSS: C:N/I:L/A:N). However, chained with other vulnerabilities (e.g., an admin endpoint that assumes IP-based trust as its only control), the practical severity may escalate.

Impact Assessment

Business Impact: Reactor Netty is a core reactive networking framework used in Spring WebFlux applications and numerous microservice architectures. The flaw enables remote attackers to falsify their source IP address when interacting with affected HTTP servers that have PROXY protocol enabled. This undermines IP-based security controls, including network segmentation policies, geographic restrictions, and identity trust boundaries.

Affected Systems: All Reactor Netty HTTP Server deployments satisfying the version constraints:

• Reactor Netty 1.3.0 – 1.3.6 (latest 1.3.x branch)
• Reactor Netty 1.1.0 – 1.2.18 (1.1.x and 1.2.x maintenance branches)
• Reactor Netty 1.0.52 and earlier

Blast Radius: Because HAProxy Protocol is typically used behind a reverse proxy/load balancer (which validates and sets the header), the risk in well-architected deployments is limited to scenarios where the PROXY-listening port is directly exposed. In misconfigured deployments or internal trust zones where Reactor Netty services accept PROXY protocol without a perimeter proxy enforcing header integrity, the full impact materializes. Organizations in financial services, e-commerce, and SaaS platforms relying on reactive Java stacks are primarily at risk. CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N confirms: network-exploitable with no privileges required, no user interaction, no confidentiality or availability impact, low integrity impact.

EPSS Context: With an EPSS score of 0.00176 (7.2% percentile of exploited CVEs), current in-the-wild exploitation probability is low. The vulnerability is not listed on CISA's Known Exploited Vulnerabilities (KEV) catalog.

Detection Guidance

Detection of this vulnerability is challenging because exploitation is purely a data-manipulation exercise — a crafted PROXY header with a spoofed IP. There is no unique string payload or binary signature. Detection should therefore focus on anomalous network behavior: PROXY protocol sessions arriving from unexpected sources, inconsistencies between the TCP peer address and the PROXY header source, and abnormal access patterns following spoofing.

Sigma Rule

title: Suspicious HAProxy PROXY Protocol Usage on Reactor Netty Services
status: experimental
description: Detects potential CVE-2026-47845 exploitation attempts by flagging PROXY protocol sessions originating from unexpected source addresses or mismatched peer/TCP addresses.
author: Valters IT Cyber Intelligence
logsource:
  category: application
  product: reactornetty
  service: http
detection:
  selection_proxy_enabled:
    cs.proxy_protocol: "true"  # Assuming application logs indicate PROXY usage
  selection_mismatch:
    cs.peer_ip|not_eq: cs.client_ip  # TCP peer vs declared PROXY source
    cs.peer_ip|is: "10.*|192.168.*|172.16.*"  # Trigger on private ranges in public contexts
  condition: selection_proxy_enabled and selection_mismatch
  timeframe: 5m
falsepositives:
  - Legitimate load balancer health checks
  - Misconfigured internal routing
level: medium

YARA Rule

/*
 * Detection rule for CVE-2026-47845 — Reactor Netty HAProxy IP mis-evaluation.
 * Note: YARA is file/content-based. PROXY protocol headers are transient
 * network data, not persistent files. This rule targets captured PCAP payloads
 * and web server logs preserved for forensic analysis.
 */

rule ReactorNetty_CVE_2026_47845_PROXY_Header_Spoofing
{
    meta:
        author = "Valters IT Cyber Intelligence"
        description = "Detects crafted PROXY v1 headers with anomalous address pairs indicative of CVE-2026-47845 exploitation attempts."
        cve = "CVE-2026-47845"
        date = "2026-02-15"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-47845"

    strings:
        $proxy_v1 = "PROXY TCP4 "
        $proxy_v1_ipv6 = "PROXY TCP6 "
        $proxy_v1_unknown = "PROXY UNKNOWN"
        $proxy_spoofed_localhost = "PROXY TCP4 127.0.0.1 "
        $proxy_private_src = /PROXY TCP4 (10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)/

    condition:
        any of ($proxy_v1, $proxy_v1_ipv6, $proxy_v1_unknown) and
        filesize < 10MB and
        (#proxy_v1 > 5)  // high frequency of proxy headers suggests scanning behavior
}

Suricata IDS Rule

alert tcp any any -> any any (msg:"ET JAEGER Reactor Netty HAProxy PROXY Header Spoofing Attempt (CVE-2026-47845)"; flow:established,to_server; content:"PROXY TCP4 "; depth:11; offset:0; pcre:"/PROXY TCP4\s+(127\.0\.0\.1|10\.\d{1,3}\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2\d|3[0-1])\.\d{1,3}\.\d{1,3})\s/"; classtype:attempted-admin; sid:202647845; rev:1; metadata:created_at 2026_02_15, updated_at 2026_02_15;)

Note: The rule flags PROXY v1 headers with private or loopback source addresses arriving on Internet-facing interfaces, an indicator of spoofing attempts against a directly exposed Reactor Netty server.

Elastic Detection

// EQL query to identify sessions where PROXY protocol declarations mismatch the network peer.
// Assumes enrichment of HAProxy 'client_ip' is stored alongside the connection's source IP.
// Works when logs capture both TCP peer metadata and POST-PROXY parsed IP (e.g., via logs from a WAF or app server with dual fields).

sequence by host.name, destination.ip, destination.port with maxspan=30s
  [network where network.protocol == "http" and
   process.name == "java" and
   event.category == "network" and
   network.direction == "ingress"]
  [network where network.protocol == "http" and
   source.ip : ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8") and
   not source.ip : "174.89.16.0/20"  // filter known internal jump hosts
   and event.action == "connection_accept"]

Splunk SPL Query

index=network sourcetype=access_combined_wcookie OR sourcetype=stream:http
| eval proxy_declared_ip = coalesce(clientip, src_ip)
| eval tcp_peer_ip = coalesce(src_ip, remote_host, dest_ip)
| where proxy_declared_ip != tcp_peer_ip
| search (proxy_declared_ip IN ("10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8"))
| stats count by _time, tcp_peer_ip, proxy_declared_ip, dest_host, dest_port, uri_path
| where count > 10
| sort -count
| table _time, tcp_peer_ip, proxy_declared_ip, dest_host, dest_port, uri_path, count

Wazuh OSSEC Rule

<group name="reactornetty,">
  <rule id="100845" level="10" frequency="12" timeframe="60">
    <decoded_as>json</decoded_as>
    <field name="app">ReactorNetty</field>
    <field name="proxy_protocol">true</field>
    <description>CVE-2026-47845: Possible HAProxy PROXY Protocol IP spoofing against Reactor Netty HTTP server - multiple mismatches between peer and declared client IP.</description>
    <group>authentication_bypass_spoofing,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
    <options>no_full_log</options>
  </rule>

  <rule id="100846" level="8">
    <if_sid>100845</if_sid>
    <field name="peer_ip_type">private</field>
    <description>Reactor Netty PROXY protocol session originating from private IP space - unusual for internet-facing services.</description>
    <group>reactornetty_proxy_anomaly,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 2/4 — CLAIMED. A single source (NVD) indicates a patch exists, but it is not independently confirmed. No vendor advisory or official fix version has been publicly confirmed at the time of writing.

Immediate Mitigations (before patch):

1. Validate PROXY Protocol Listener Exposure: Audit which network interfaces bind to ports listening in PROXY protocol mode. If the server is accepting PROXY-protocol traffic, verify it is only reachable from the legitimate load balancer/proxy IP ranges. Restrict via firewall or security group ACLs to only the trusted proxy source addresses.
2. Disable HAProxy Protocol If Not Required: If the Reactor Netty server does not need to receive PROXY headers (e.g., it is not directly behind a proxy needing to forward the original client IP), disable the PROXY protocol configuration entirely.
3. Add Application-Level IP Validation: If the server must continue using PROXY protocol, consider adding a middleware/interceptor that validates the PROXY-declared source IP against the actual TCP peer address. Reject the connection if the declared source is not within the expected trusted client ranges and the peer is not the known proxy.
4. Use TLS + Header Injection Prevention: Ensure any reverse proxy in front of Reactor Netty strips and re-adds PROXY headers at the perimeter, so external clients cannot inject their own headers directly.

Patch / Upgrade Steps:

1. Monitor the Pivotal/VMware Tanzu Reactor Netty release page and the official Spring Security advisory feed.
2. When confirmed, upgrade to the patched version. If you run Reactor Netty 1.3.x, upgrade to 1.3.7 or later once released. For 1.1.x/1.2.x, upgrade to 1.2.19 or later. For 1.0.52 and earlier, upgrade to the latest patched 1.0.x release or migrate to a maintained branch.
3. If using Spring Boot, upgrade to the Spring Boot patch release that manages the corrected Reactor Netty dependency version.
4. Re-verify your application after upgrading with regression tests around remote-address-dependent functionality (access logging, rate limiting, IP allowlists).

Long-Term Hardening:

• Never trust the PROXY protocol header as the sole source of truth unless the socket is guaranteed to be proxy-only and network-restricted.
• Implement defense-in-depth for IP-based access controls: combine IP allowlists with mTLS, JWT claims, or additional shared-secret headers.
• Review application code for uses of request.remoteAddress() or equivalent; confirm whether those usages are security-sensitive.
• Subscribe to the CVE feed and vendor security notifications for Netty ecosystem vulnerabilities.
• Document configurations: clearly mark which services operate in PROXY protocol mode so future security audits can identify exposure windows.

References

1. NVD Entry — CVE-2026-47845: https://nvd.nist.gov/vuln/detail/CVE-2026-47845 (Primary authoritative source; contains the official description, CVSS 3.1 vector, and CWE classification.)
2. Reactor Netty GitHub Repository / Releases Page: https://github.com/reactor/reactor-netty/releases (Track for the official patch release and version changelogs. As of this report, no release notes specifically referencing CVE-2026-47845 have been published — patch is CLAIMED by NVD only.)
3. HAProxy PROXY Protocol Specification (v1 & v2): https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt (Technical reference for the PROXY protocol header format, useful for understanding the attack mechanism.)
4. CWE-290 — Authentication Bypass by Spoofing: https://cwe.mitre.org/data/definitions/290.html (Weakness class categorization explaining the spoofing root cause.)
5. Spring Security Advisories Page: https://spring.io/security (Watch for an official VMware Tanzu / Spring advisory that will confirm the patch and provide detailed remediation guidance once public.)

Threat Actor Campaign Evidence: None known. CISA KEV does not list CVE-2026-47845, no exploit code or PoC has been observed publicly, and the EPSS percentile (7.2%) suggests it is not currently a favored target for mass exploitation. However, the low exploitation likelihood does not diminish the need for remediation, given the ease with which IP-based trust is commonly abused once a flaw of this class is weaponized.