Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory allocation in the AtomicDoubleArray class (when serialized with Java serialization) and Compound Ordering class (when serialized with GWT serialization). An attacker could exploit applications that use Guava and deserialize untrusted data to cause a denial of service.
External References:
https://github.com/google/guava/wiki/CVE-2018-10237 https://groups.google.com/forum/#!topic/guava-announce/xqWALw4W1vs/discussion
Upstream Patch:
https://github.com/google/guava/commit/7ec8718f1e6e2814dabaa4b9f96b6b33a813101c
A flaw was found in computer hardware of the Intel microprocessors related to the instruction-side TLB (Translation Lookaside Buffer) that caches translations from guest (and host) virtual addresses into physical addresses.
This is a software fix that attempts to prevent exploitation of the hardware through preventing a hacker from creating an exploitable condition
Additional information:
https://access.redhat.com/security/vulnerabilities/ifu-page-mce
The containers/image library used by container tools; Podman, Builah, and Skopeo in Red Hat Enterprise Linux 8, and CRI-O in OpenShift Container Platform does not enforce TLS connections to the container registry authorization service [1]. An attacker could use this vulnerability launch a MiTM attack, and steal login credentials, or bearer tokens.
Upstream issue:
https://github.com/containers/image/issues/654
Upstream patch:
https://github.com/containers/image/pull/669
[1] https://docs.docker.com/registry/spec/auth/token/
Kubernetes requires an authentication mechanism to enforce users’ privileges. One method of authentication, bearer tokens, are opaque strings used to associate a user with their having successfully authenticated previously. Any user with possession of this token may masquerade as the original user (the “bearer”) without further authentication.
Within Kubernetes, the bearer token is captured within the hyperkube kube-apiserver system logs at high verbosity levels (--v 10). A malicious user with access to the system logs on such a system could masquerade as any user who has previously logged into the system.