Where
AND
AND
-Infinity
0
Severity
5.9
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

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

1 / 2
Source: Red Hat
First published (updated )
Severity
6.5
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

In previous versions of Puppet Agent it was possible for the agent to retrieve facts from an environment that it was not classified to retrieve from. This was resolved in Puppet Agent 5.3.4, included in Puppet Enterprise 2017.3.4

1 / 2
First published (updated )
Severity
5.5
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

In previous versions of Puppet Agent it was possible to install a module with world writable permissions. Puppet Agent 5.3.4 and 1.10.10 included a fix to this vulnerability.

1 / 3
Source: Launchpad
First published (updated )
Severity
4.4
AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

Affected versions of the package are vulnerable to Hash Collision due to an error in the BKS version 1 keystore files.

BKS is a keystore format, designed to function similarly to a Sun/Oracle JKS keystore. BKS files can contain public keys, private keys and certificates, and they rely on a password-based encryption to provide confidentiality and integrity protections to the keystore contents.

The first version of a BKS file (aka BKS-V1) contained a design flaw when determining the key size used to protect the keystore data. It used the SHA-1 hash function, which is 160 bits in length. In a RFC7292-compliant cryptographic algorithm, the MAC key size should be the same size as the hash function being used, meaning that the MAC key size should be 160 bits long for BKS files.

However, Bouncy Castle BKS-V1 files uses only 16 bits for the MAC key size. Regardless of the complexity of the password, ghe BKS-V1 file will have merely 65,536 different encryption keys. An attacker may bruteforce this password in a matter of seconds by testing all 65K values.

References:

https://insights.sei.cmu.edu/cert/2018/03/the-curious-case-of-the-bouncy-castle-bks-passwords.html https://www.kb.cert.org/vuls/id/306792

1 / 3
Source: Red Hat
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203