CVE-2026-56852

What it actually does

This is a denial-of-service flaw in Unicode normalization handling: code paths using norm.Iter can enter a non-terminating loop when processing input that contains invalid UTF-8 byte sequences. Any affected Go-based product or component that normalizes attacker-controlled text, identifiers, headers, metadata, file names, labels, configuration values, API fields, or other strings may consume CPU indefinitely on the worker, request handler, or background process handling that input. The impact is availability-focused; the issue does not inherently provide code execution, authentication bypass, or data disclosure, but it can degrade or exhaust service capacity if malformed input is repeatedly supplied.

Why it matters to the business

Successful exploitation can make affected services slow, unresponsive, or unavailable, especially for internet-facing APIs, proxies, telemetry pipelines, container tooling, orchestration components, and automation systems that process untrusted text. Because the affected package is embedded across many Red Hat-distributed Go products, exposure may be broad even when the vulnerable Unicode code is not obvious in application code. Current public exploitation signal is low: EPSS is 0.00446, it is not listed in CISA KEV, no ransomware association is indicated, and exploit maturity is listed as none; however, the fix should still be scheduled because denial-of-service bugs in common parsing libraries can be triggered remotely when reachable parsing paths exist.

How an attack unfolds

An attacker first identifies a reachable interface in an affected product that accepts text later passed through Unicode normalization, such as an HTTP request field, API parameter, metadata value, configuration payload, label, file path, object name, telemetry attribute, or similar string. The attacker then sends input containing deliberately invalid UTF-8 bytes that reach the vulnerable norm.Iter processing path. When the vulnerable iterator attempts to process the malformed sequence, it can fail to make forward progress and spin indefinitely. Repeating the request or delivering multiple malformed payloads can tie up CPU cores, goroutines, worker threads, request handlers, or background processors, resulting in latency, request timeouts, queue buildup, health-check failures, or service restarts. The attack does not require a memory corruption primitive; the objective is to consume processing capacity through malformed input.

How to fix it

Upgrade affected Red Hat packages to the fixed versions from RHSA-2026:49360 or later: buildah-main 1.44.0-3.3.hum1, caddy-main 2.11.4-0.3.hum1, cosign-main 3.1.2-0.2.hum1, etcd-main 3.7.0-0.3.hum1, go-fdo-client-main 1.0.0-2.1.hum1, go-fdo-server-main 1.0.1-0.5.hum1, golang1-25-main 1.25.12-1.1.hum1, golang1-26-main 1.26.5-0.1.1.hum1, grype-main 0.116.0-0.1.hum1, helm3-main 3.21.3-0.1.2.hum1, helm4-main 4.2.3-0.1.2.hum1, hugo-main 0.164.0-0.1.2.hum1, jaeger-main 2.20.0-0.2.hum1, kubernetes1-35-main 1.35.6-2.1.hum1, kubernetes1-36-main 1.36.2-6.1.hum1, oauth2-proxy-main 7.15.3-0.3.hum1, opentelemetry-collector-main 0.157.0-0.1.hum1, opentelemetry-collector-contrib-main 0.157.0-0.1.hum1, opentofu1-10-main 1.10.10-0.3.hum1, opentofu1-11-main 1.11.13-0.2.hum1, opentofu1-12-main 1.12.5-0.2.hum1, podman-main 6.0.2-2.1.hum1, prometheus3-13-main 3.13.2-0.1.hum1, prometheus3-5-main 3.5.5-0.3.hum1, and skopeo-main 1.23.0-3.1.hum1. Rebuild and redeploy any statically linked Go binaries that vendor the vulnerable normalization library, since updating the operating system package alone may not update embedded dependencies. Where immediate patching is not possible, reduce exposure by limiting unauthenticated access, enforcing request size and duration limits, applying rate limits, rejecting malformed UTF-8 at ingress, adding timeouts around parsing and normalization operations, and isolating affected services with resource limits so a stuck normalization loop cannot consume all host capacity.

How to confirm the fix worked

Confirm installed package versions are at or above the fixed RHSA-2026:49360 versions listed for each affected product. For containerized deployments, verify the image digest was rebuilt after the fix and that running workloads are using the rebuilt image, not only that a base image is available. For statically compiled Go applications, inspect dependency manifests, SBOMs, build logs, or binary provenance to confirm the corrected Unicode normalization implementation is included. Operationally validate by exercising representative text-handling paths with malformed UTF-8 in a controlled non-production environment and confirming the process returns an error, rejects the input, or times out safely instead of consuming sustained CPU. Also verify that ingress validation, request timeouts, CPU limits, and autoscaling/health-check behavior are configured to contain malformed-input denial-of-service attempts.

Typical attack path

1. Identify an exposed affected Go-based product or service that accepts externally supplied text or metadata.
2. Probe inputs that are likely to be normalized, parsed, indexed, compared, rendered, proxied, or stored by the service.
3. Send malformed payloads containing invalid UTF-8 byte sequences to the selected input path.
4. Trigger the vulnerable norm.Iter loop during Unicode normalization.
5. Repeat or parallelize requests to consume CPU and tie up handlers or workers.
6. Cause degraded service, timeouts, failed health checks, backlogs, or temporary outage.

How to detect it

Look for evidence of availability degradation aligned with malformed text input. Relevant sources include web server and reverse-proxy access logs, API audit logs, application logs, Kubernetes or container runtime logs, systemd journals, endpoint telemetry, CPU and goroutine profiling data, load balancer logs, WAF logs, and observability traces. Indicators include a sudden rise in CPU usage without corresponding traffic growth, request handlers that never complete, increased 408/499/500/502/503/504 responses, health-check failures, watchdog restarts, container OOM/CPU throttling events, and log entries showing invalid or malformed UTF-8 shortly before degradation. For Go services, collect goroutine dumps or CPU profiles during an incident and look for hot stacks in Unicode normalization or norm.Iter-related code paths. Network and application logs may not preserve raw invalid bytes, so absence of readable payload evidence does not rule out exploitation; prioritize timing correlation between anomalous requests and CPU saturation. No named threat actors or campaigns are currently provided for this vulnerability.

• invalid UTF-8
• invalid utf8
• malformed UTF-8
• malformed utf8
• unicode/utf8
• unicode/norm
• norm.Iter
• context deadline exceeded
• request timed out
• upstream timed out
• CPU throttling
• Readiness probe failed
• Liveness probe failed

What your security team should do

• Inventory affected Red Hat Go-based packages and container images across servers, build systems, CI/CD runners, orchestration nodes, observability components, proxies, and developer tooling.
• Prioritize patching internet-facing or multi-tenant services that parse externally supplied text, including proxies, APIs, telemetry collectors, Kubernetes-related components, Prometheus, OAuth2 Proxy, Caddy, etcd, and container tooling exposed through automation interfaces.
• Apply RHSA-2026:49360 fixed versions or later and redeploy running workloads; ensure statically linked binaries are rebuilt rather than relying only on host package updates.
• Add or verify malformed UTF-8 rejection at trust boundaries where protocol-compatible, especially for unauthenticated endpoints.
• Enforce request timeouts, body/header size limits, concurrency limits, and per-process CPU quotas to reduce denial-of-service blast radius.
• Monitor for unexplained sustained CPU saturation, request latency spikes, handler timeouts, queue growth, or repeated malformed input errors on affected services.
• Treat exploitation likelihood as currently low but nonzero: there is no KEV listing, ransomware association, or mature public exploit indicated, but the vulnerability is recent and affects widely reused Go components.