Insufficient ID command validation in the SEV Firmware may allow a local authenticated attacker to perform a denial of service of the PSP.

Insufficient validation of the AMD SEV Signing Key (ASK) in the SEND_START command in the SEV Firmware may allow a local authenticated attacker to perform a denial of service of the PSP

Side-channels Related to the x86 PREFETCH Instruction

A timing and power-based side channel attack leveraging the x86 PREFETCH instructions on some AMD CPUs could potentially result in leaked kernel address space information.

Failure to verify the protocol in SMM may allow an attacker to control the protocol and modify SPI flash resulting in a potential arbitrary code execution.

When the AMD Platform Security Processor (PSP) boot rom loads, authenticates, and subsequently decrypts an encrypted FW, due to insufficient verification of the integrity of decrypted image, arbitrary code may be executed in the PSP when encrypted firmware images are used.

AMD Speculative execution with Floating-Point Value Injection

Potential floating point value injection in all supported CPU products, in conjunction with software vulnerabilities relating to speculative execution with incorrect floating point results, may cause the use of incorrect data from FPVI and may result in data leakage.

AMD Speculative Code Store Bypass

Potential speculative code store bypass in all supported CPU products, in conjunction with software vulnerabilities relating to speculative execution of overwritten instructions, may cause an incorrect speculation and could result in data leakage.

Failure to flush the Translation Lookaside Buffer (TLB) of the I/O memory management unit (IOMMU) may lead an IO device to write to memory it should not be able to access, resulting in a potential loss of integrity.

AMD Secure Encrypted Virtualization

In the AMD SEV/SEV-ES feature, memory can be rearranged in the guest address space that is not detected by the attestation mechanism which could be used by a malicious hypervisor to potentially lead to arbitrary code execution within the guest VM if a malicious administrator has access to compromise the server hypervisor.

In the TeamCity IntelliJ plugin before 2020.2.2.85899, DoS was possible.

Information disclosure in the TeamCity plugin for IntelliJ before 2020.2.2.85899 was possible because a local temporary file had Insecure Permissions.

An issue was discovered in the marc crate before 2.0.0 for Rust. A user-provided Read implementation can gain access to the old contents of newly allocated memory, violating soundness.

An issue was discovered in the raw-cpuid crate before 9.0.0 for Rust. It allows __cpuid_count() calls even if the processor does not support the CPUID instruction, which is unsound and causes a deterministic crash.

An issue was discovered in the raw-cpuid crate before 9.0.0 for Rust. It has unsound transmute calls within as_string() methods.

An issue was discovered in Deserializer::read_vec in the cdr crate before 0.2.4 for Rust. A user-provided Read implementation can gain access to the old contents of newly allocated heap memory, violating soundness.

PHPGurukul Daily Expense Tracker System 1.0 is vulnerable to stored XSS via the add-expense.php Item parameter.

PHPGurukul Daily Expense Tracker System 1.0 is vulnerable to stored XSS via the user-profile.php Full Name field.

An issue was discovered in AfterLogic Aurora through 7.7.9 and WebMail Pro through 7.7.9. They allow directory traversal to read files (such as a data/settings/settings.xml file containing admin panel credentials), as demonstrated by dav/server.php/files/personal/%2e%2e when using the caldav_public_user account (with caldav_public_user as its password).

An issue was discovered in AfterLogic Aurora through 8.5.3 and WebMail Pro through 8.5.3, when DAV is enabled. They allow directory traversal to create new files (such as an executable file under the web root). This is related to DAVServer.php in 8.x and DAV/Server.php in 7.x.

block repositories using http by default

Apache Maven will follow repositories that are defined in a dependency’s Project Object Model (pom) which may be surprising to some users, resulting in potential risk if a malicious actor takes over that repository or is able to insert themselves into a position to pretend to be that repository. Maven is changing the default behavior in 3.8.1+ to no longer follow http (non-SSL) repository references by default. More details available in the referenced urls. If you are currently using a repository manager to govern the repositories used by your builds, you are unaffected by the risks present in the legacy behavior, and are unaffected by this vulnerability and change to default behavior. See this link for more information about repository management: https://maven.apache.org/repository-management.html