Security Vulnerabilities
- CVEs Published In June 2020
A vulnerability exists in Arista’s Cloud EOS VM / vEOS 4.23.2M and below releases in the 4.23.x train, 4.22.4M and below releases in the 4.22.x train, 4.21.3M to 4.21.9M releases in the 4.21.x train, 4.21.3FX-7368.*, 4.21.4-FCRFX.*, 4.21.4.1, 4.21.7.1, 4.22.2.0.1, 4.22.2.2.1, 4.22.3.1, and 4.23.2.1 Router code in a scenario where TCP MSS options are configured.
A flaw was discovered in Undertow in versions before Undertow 2.1.1.Final where certain requests to the "Expect: 100-continue" header may cause an out of memory error. This flaw may potentially lead to a denial of service.
IrfanView 4.54 allows a user-mode write access violation starting at FORMATS!GetPlugInInfo+0x0000000000038ed4.
IrfanView 4.54 allows a user-mode write access violation starting at FORMATS!GetPlugInInfo+0x0000000000038eb7.
HashiCorp Vault and Vault Enterprise 1.4.0 and 1.4.1, when configured with the GCP Secrets Engine, may incorrectly generate GCP Credentials with the default time-to-live lease duration instead of the engine-configured setting. This may lead to generated GCP credentials being valid for longer than intended. Fixed in 1.4.2.
HashiCorp Vault and Vault Enterprise logged proxy environment variables that potentially included sensitive credentials. Fixed in 1.3.6 and 1.4.2.
Liferay Portal 7.x before 7.3.2, and Liferay DXP 7.0 before fix pack 92, 7.1 before fix pack 18, and 7.2 before fix pack 5 does not sanitize the information returned by the DDMDataProvider API, which allows remote authenticated users to obtain the password to REST Data Providers.
In Liferay Portal before 7.3.2 and Liferay DXP 7.0 before fix pack 92, 7.1 before fix pack 18, and 7.2 before fix pack 6, the template API does not restrict user access to sensitive objects, which allows remote authenticated users to execute arbitrary code via crafted FreeMarker and Velocity templates.
Kata Containers doesn't restrict containers from accessing the guest's root filesystem device. Malicious containers can exploit this to gain code execution on the guest and masquerade as the kata-agent. This issue affects Kata Containers 1.11 versions earlier than 1.11.1; Kata Containers 1.10 versions earlier than 1.10.5; and Kata Containers 1.9 and earlier versions.
A malicious guest compromised before a container creation (e.g. a malicious guest image or a guest running multiple containers) can trick the kata runtime into mounting the untrusted container filesystem on any host path, potentially allowing for code execution on the host. This issue affects: Kata Containers 1.11 versions earlier than 1.11.1; Kata Containers 1.10 versions earlier than 1.10.5; Kata Containers 1.9 and earlier versions.