See how smallrye compares to other vendors in security performance
A flaw was found in Smallrye, where smallrye-fault-tolerance is vulnerable to an out-of-memory (OOM) issue. This vulnerability is externally triggered when calling the metrics URI. Every call creates a new object within meterMap and may lead to a denial of service (DoS) issue.
A flaw was found in Smallrye. smallrye-fault-tolerance is vulnerable to an Out-of-Memory (OOM) which is triggered externally when calling the metrics URI. Every call creates a new object within meterMap and may lead to Denial of Service (DoS).
A memory leak vulnerability was discovered in SmallRye Fault Tolerance core. When a programmatic Guard, TypedGuard, or FaultTolerance is invoked through the ApplyGuard or the deprecated ApplyFaultTolerance annotations, the library retains one DelegatingMeteredOperation and one MetricsCollector instance per invocation for the lifetime of the singleton guard.
The root cause is that these objects are never released, causing the heap to grow linearly with the number of calls. An unauthenticated remote attacker can exploit this by sending a high volume of requests to a vulnerable endpoint, leading to increased garbage collection pressure, significant performance degradation, and an eventual OutOfMemoryError OOM condition. This impact occurs regardless of whether a description is set for the guard.
A path traversal and same-origin Server-Side Request Forgery (SSRF) vulnerability was found in the AWS ALB key resolver of SmallRye JWT. When the AWSALB key provider is configured, AwsAlbKeyResolver constructs the verification-key URL by concatenating the configured key location with the attacker-controlled kid value from the inbound, unverified JWT header. The kid value is only checked for null and, optionally, against a configured expected value. Characters such as /, .., ?, and # are not rejected or encoded. An unauthenticated attacker can therefore cause the application server to issue GET requests to arbitrary paths and manipulate query parameters on the configured OIDC/JWKS origin before JWT signature verification. This can be exploited remotely without authentication or user interaction, allowing attackers to read non-public data on the same origin as the configured key endpoint.