| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| libspdm is a sample implementation that follows the DMTF SPDM specifications. In version 1.4.0, both the FINISH request (Table 80) and the FINISH_RSP response (Table 81) gained two new fields, OpaqueDataLength and OpaqueData, placed before the trailing signed/authenticated field. The transcript definitions used to compute and verify the FINISH signature, the FINISH HMAC (RequesterVerifyData), and the FINISH_RSP HMAC (ResponderVerifyData) were not updated and still terminate with a step of the form. Per DSP0274, the "SPDM Header Fields" are only the four header bytes (SPDMVersion, RequestResponseCode, Param1, Param2). A literal reading therefore excludes OpaqueDataLength and OpaqueData, even though those fields are transmitted before the trailing signature/HMAC field. Because the signature/HMAC must cover every field transmitted before it to "protect the entire handshake against manipulation by an active attacker," an active attacker could otherwise modify the opaque data in flight without invalidating the signature or HMAC. This issue has been patched in version 1.4.1. |
| AstroBlocks is a block-first CMS for Astro projects. Prior to version 3.4.0, admin session tokens can be forged due to a hard-coded fallback JWT secret and a mismatched environment variable name. An attacker who knows the public fallback value (readable in the published package) can forge a valid session token with role: "owner" and obtain full administrative control of the CMS — creating/deleting content, users, media, redirects, and configuration. This issue has been patched in version 3.4.0. |
| Cryptographic Issue when using a static initialization vector for AES-GCM key wrapping, which requires a unique value for each call to ensure security. |
| Missing cryptographic step in Windows CryptoAPI allows an authorized attacker to perform tampering locally. |
| Use of a per-part static key in the ASP Bootloader could allow an attacker to downgrade the Secure Encrypted Virtualization (SEV) firmware and exploit known vulnerabilities to decrypt memory potentially resulting in loss of confidentiality. |
| CAI Content Credentials is affected by a Use of a Broken or Risky Cryptographic Algorithm vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploit depends on conditions beyond the attacker's control. Exploitation of this issue does not require user interaction. |
| Use of a broken or risky cryptographic algorithm in SQL Server allows an unauthorized attacker to disclose information over a network. |
| Inadequate encryption strength in Windows Modern Device Management (MDM) allows an unauthorized attacker to execute code over a network. |
| Use of a broken or risky cryptographic algorithm in Windows DPAPI (Data Protection Application Programming Interface) allows an authorized attacker to elevate privileges locally. |
| Issue summary: The AES-GCM-SIV implementation treats a zero-length Additional
Authenticated Data (AAD) update as a reset of all the AAD supplied so far,
instead of leaving the AAD unchanged. An application that supplies its AAD in
several fragments, one of which is empty, therefore produces or verifies
messages whose authentication tag does not cover the AAD supplied before
the empty fragment.
Impact summary: Data an application intended to authenticate alongside a
message is silently left unauthenticated. An attacker can forge the AAD of such
a message.
CWE: CWE-325: Missing Cryptographic Step
Description: An application passing AAD in multiple chunks of which some have
zero length will have the previous AAD chunks effectively unauthenticated. Also,
on context re-initialisation, the AAD was not reset, which meant that any AAD
accumulated from the previous context usage were also included in the AAD of the
new message.
The fix makes a zero-length AAD update a no-op and clears any accumulated AAD
whenever the context is re-initialised with a key or a nonce.
A re-initialisation that only changes parameters keeps the AAD.
FIPS impact: no
The FIPS modules are not affected, as AES-GCM-SIV is not a FIPS approved
algorithm and is implemented only in the default provider, outside the
OpenSSL FIPS module boundary. |
| Use of Hard-coded Cryptographic Key in JWT token authentication in Apache OFBiz 24.09.06 and 24.09.07 on all platforms allows an unauthenticated, network-reachable attacker to obtain full administrative access via a forged JWT signed with the factory-default security.token.key value that CVE-2026-31986 removed from newly generated configurations, on a deployment that upgraded from a release predating that fix while retaining its existing security.properties with security.internal.sso.enabled set to true. Users are recommended to upgrade to version 24.09.08. Upgrading alone does not replace an already-configured key: deployments that carried framework/security/config/security.properties forward from a release predating the CVE-2026-31986 fix must also run './gradlew rotateSecretKeys' after upgrading, since the existing generateSecretKeys task leaves an already-set value untouched. |
| Inadequate encryption strength in SSL in Google Chrome prior to 157.0.8103.38 allowed a remote attacker to potentially bypass web origin policy via crafted network traffic. (Chromium security severity: Low) |
| The LaserGest mobile application encrypts stored assistance portal credentials with a hardcoded AES key and IV, allowing an attacker with access to the application package to recover them in cleartext. |
| The RSA cryptographic
key material, including a private key and public key, is embedded within the GV-Access application package. Because Android applications can be extracted and
reverse engineered, storing private cryptographic keys directly inside the
client application may allow an attacker to recover the keys and potentially
use them to impersonate the application, decrypt protected data, or generate
unauthorized cryptographic operations. |
| An
API key is hardcoded and retrievable from the GV-Face package. Since
Android applications can be reverse engineered, embedding sensitive API
credentials directly in the client application may allow unauthorized users to
extract and misuse the key. |
| The RSA cryptographic key material, including a private key and public key, is
embedded within the application package. Because Android applications can
be extracted and reverse engineered, storing private cryptographic keys
directly inside the client application may allow an attacker to recover the
keys and potentially use them to impersonate the application, decrypt protected
data, or generate unauthorized cryptographic operations. |
| The RSA cryptographic key
material, including a private key and public key, is embedded within the GV-Cloud application package. Because Android applications can be extracted and
reverse engineered, storing private cryptographic keys directly inside the
client application may allow an attacker to recover the keys and potentially
use them to impersonate the application, decrypt protected data, or generate
unauthorized cryptographic operations. |
| INDOTALENT WHMS (Asp.Net-Core-Inventory-Order-Management-System) before 10.20261109 contains an authentication bypass vulnerability caused by a hard-coded JWT signing key, issuer and audience in appsettings.json. Unauthenticated remote attackers can forge tokens for any user ID and role that the Tokens/DI.cs validator trusts, gaining administrator access to the entire API. |
| Due to a weak HMAC cryptography calculation when receiving an RFC callback in SAP NetWeaver and ABAP Platform (Application Server ABAP), an authenticated attacker with high privileges and access to a network segment between application servers on an SAP system could intercept network communication between application servers and change the identity of the caller, enabling the execution of unauthorized function calls on the target server with escalated privileges leading to High impact on Confidentiality, Integrity, and Availability of the application. |
| Kubero 3.0.0 through 3.1.1 contains an authentication bypass vulnerability that allows unauthenticated remote attackers to forge administrative JWTs by using a hardcoded fallback signing secret when JWT_SECRET is unset. Attackers can sign tokens with arbitrary role, userGroups and permissions claims, which JwtStrategy.validate() trusts without a database lookup, to take control of pipelines, applications, users and API tokens. |
