CVE-2026-92230 in Karaf
Summary
by MITRE • 09/17/2026
Apache Karaf's XmlUtils cached XML parser/transformer factories in static ThreadLocal fields on long-lived container threads. Because a ThreadLocal value outlives the OSGi bundle that created it, repeated bundle or feature install, update, or refresh operations can leave successive bundle ClassLoader's pinned in memory and unreachable for garbage collection, leading to unbounded Metaspace growth and eventual denial of service of the Karaf instance.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in Apache Karaf stems from a resource management flaw within its XmlUtils component, specifically involving the improper handling of XML parser and transformer factories across thread lifecycles. In Java applications utilizing the OSGi modular framework like Karaf, components are packaged as bundles that have their own isolated ClassLoaders to prevent classpath conflicts between different modules. However, Apache Karaf's implementation stored these critical XML processing objects in static ThreadLocal fields on long-lived container threads rather than allocating them per request or bundle context. This architectural decision creates a persistent reference chain where the thread holds onto the XmlUtils instance, which in turn holds references to the specific ClassLoader of the OSGi bundle that originally initialized it. Because ThreadLocal variables are designed to persist for the duration of the thread they reside on, and Karaf container threads typically run indefinitely as part of the application server lifecycle, these references remain active even after the associated bundles have been uninstalled or updated.
This design flaw leads directly to a severe memory management issue known as Metaspace exhaustion, which is a subset of Java heap space but specifically tracks non-heap memory used for class metadata such as loaded classes and method definitions. When an OSGi bundle is installed, updated, or refreshed, it loads new versions of its classes into its unique ClassLoader. Under normal circumstances, when the bundle is removed, that ClassLoader becomes eligible for garbage collection along with all the classes it loaded. However, due to the static ThreadLocal retention in XmlUtils, references to these obsolete ClassLoaders are kept alive by the long-running threads. Consequently, successive operations involving multiple bundles or frequent updates result in a cumulative accumulation of unreachable ClassLoaders and their associated class metadata. This unbounded growth consumes increasing amounts of Metaspace memory until the JVM reaches its configured limit, triggering an OutOfMemoryError that crashes the Java Virtual Machine and renders the entire Karaf instance unavailable to users and dependent services.
From a security operations perspective, this vulnerability is classified under CWE-401, which describes missing release of memory after effective usage, or more specifically in this context, it aligns with CWE-772 regarding Missing Release of Resource after Effective Ownership. The operational impact is primarily a Denial of Service (DoS) condition resulting from resource exhaustion rather than arbitrary code execution. Attackers do not need to exploit the vulnerability directly through malicious input; instead, they can trigger the DoS by inducing repeated bundle installations or updates within the Karaf environment. This behavior maps closely to the ATT&CK technique T1496, Resource Hijacking, where an adversary consumes system resources to degrade performance or cause a crash. The persistence of these references makes it particularly difficult for standard monitoring tools to detect the leak until the service has already become unresponsive, as the memory usage appears legitimate from the perspective of active threads rather than leaked objects in garbage collection roots.
Mitigation strategies must focus on breaking the reference chain between the long-lived container threads and the short-lived bundle ClassLoaders. The most effective remediation involves refactoring XmlUtils to avoid storing parser or transformer factories in static ThreadLocal fields for extended periods. Instead, these resources should be instantiated locally within methods where they are needed, allowing them to become eligible for garbage collection immediately after use if no other references exist. Alternatively, if caching is required for performance reasons, a bounded cache with explicit eviction policies based on time-to-live or usage frequency should be implemented instead of relying on ThreadLocal storage. For organizations unable to apply an immediate code patch, operational mitigations include reducing the frequency of bundle updates and ensuring that unused bundles are properly uninstalled to minimize the accumulation of stale ClassLoaders. Regular monitoring of Metaspace utilization metrics is also recommended to detect early signs of memory leaks before they result in a complete service outage.