AI analysis
Apache Karaf's XmlUtils caches XML parser and transformer factories in static ThreadLocal fields on long-lived container threads. Because ThreadLocal values outlive the OSGi bundle that created them, each bundle or feature install, update, or refresh operation pins that bundle's ClassLoader in memory where it can never be garbage collected. Repeated dynamic lifecycle operations therefore drive unbounded Metaspace growth until the Karaf instance exhausts memory and is denied service. Exploitation requires the ability to trigger repeated bundle/feature operations, meaning an attacker would typically need management access (Karaf shell, JMX, or web console) or control of an automated deployment pipeline, though internal CI/CD-driven deployments can be affected without any attacker. The issue is not yet CVSS-scored, is not in CISA KEV, and no public proof-of-concept or in-the-wild exploitation is known.
What to do: Upgrade Apache Karaf to the patched release referenced in the Apache security advisory once published, since no fixed version is stated in the available data. Until patched, restrict Karaf shell, JMX, and Hawtio/webpack console access to trusted administrators and avoid frequent automated bundle/feature install-update-refresh cycles in production. Monitor JVM Metaspace consumption and restart instances showing steady growth.
Affected
| Apache Software Foundation Apache Karaf | — |
Estimated exposure
moderate≈1,000–10,000 internet-exposed Karaf/Hawtio management instances (public scan estimates), with far more internal and embedded deployments — Karaf is primarily deployed as an internal OSGi/ESB container (often embedded in other products rather than exposed directly), and internet-wide scans of Karaf/Hawtio management endpoints typically surface only low thousands of instances —…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
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.