| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| eGovFramework/egovframe-common-components versions up to and including 4.3.1 includes Web Editor image upload and related file delivery functionality that uses symmetric encryption to protect URL parameters, but exposes an encryption oracle that allows attackers to generate valid ciphertext for chosen values. The image upload endpoints /utl/wed/insertImage.do and /utl/wed/insertImageCk.do encrypt server-side paths, filenames, and MIME types and embed them directly into a download URL that is returned to the client. Because these same encrypted parameters are trusted by other endpoints, such as /utl/web/imageSrc.do and /cmm/fms/getImage.do, an unauthenticated attacker can abuse the upload functionality to obtain encrypted representations of attacker-chosen identifiers and then replay those ciphertext values to file-serving APIs. This design failure allows an attacker to bypass access controls that rely solely on the secrecy of encrypted parameters and retrieve arbitrary stored files that are otherwise expected to require an existing session or specific authorization context. KISA/KrCERT has identified this unpatched vulnerability as "KVE-2023-5281." |
| In mutt and neomutt the In-Reply-To email header field is not protected by cryptographic signing which allows an attacker to reuse an unencrypted but signed email message to impersonate the original sender. |
| In JetBrains ReSharper before 2025.2.4 missing signature verification in DPA Collector allows local privilege escalation |
| In neomutt and mutt, the To and Cc email headers are not validated by cryptographic signing which allows an attacker that intercepts a message to change their value and include himself as a one of the recipients to compromise message confidentiality. |
| A vulnerability was found in GnuTLS, where a cockpit (which uses gnuTLS) rejects a certificate chain with distributed trust. This issue occurs when validating a certificate chain with cockpit-certificate-ensure. This flaw allows an unauthenticated, remote client or attacker to initiate a denial of service attack. |
| A flaw was found in Red Hat Enterprise Application Platform 8. When an OIDC app that serves multiple tenants attempts to access the second tenant, it should prompt the user to log in again since the second tenant is secured with a different OIDC configuration. The underlying issue is in OidcSessionTokenStore when determining if a cached token should be used or not. This logic needs to be updated to take into account the new "provider-url" option in addition to the "realm" option.
EAP-7 does not provide the vulnerable provider-url configuration option in its OIDC implementation and is not affected by this flaw. |
| A vulnerability was found in Samba's SMB2 packet signing mechanism. The SMB2 packet signing is not enforced if an admin configured "server signing = required" or for SMB2 connections to Domain Controllers where SMB2 packet signing is mandatory. This flaw allows an attacker to perform attacks, such as a man-in-the-middle attack, by intercepting the network traffic and modifying the SMB2 messages between client and server, affecting the integrity of the data. |
| A flaw exists in the SAML signature validation method within the Keycloak XMLSignatureUtil class. The method incorrectly determines whether a SAML signature is for the full document or only for specific assertions based on the position of the signature in the XML document, rather than the Reference element used to specify the signed element. This flaw allows attackers to create crafted responses that can bypass the validation, potentially leading to privilege escalation or impersonation attacks. |
| A remote code execution vulnerability was found in Shim. The Shim boot support trusts attacker-controlled values when parsing an HTTP response. This flaw allows an attacker to craft a specific malicious HTTP request, leading to a completely controlled out-of-bounds write primitive and complete system compromise. This flaw is only exploitable during the early boot phase, an attacker needs to perform a Man-in-the-Middle or compromise the boot server to be able to exploit this vulnerability successfully. |
| An issue has been discovered in GitLab CE/EE affecting all versions from 12.2 prior to 16.5.6, 16.6 prior to 16.6.4, and 16.7 prior to 16.7.2 in which an attacker could potentially modify the metadata of signed commits. |
| MicroWorld eScan AV's update mechanism failed to ensure authenticity and integrity of updates: update packages were delivered and accepted without robust cryptographic verification. As a result, an on-path attacker could perform a man-in-the-middle (MitM) attack and substitute malicious update payloads for legitimate ones. The eScan AV client accepted these substituted packages and executed or loaded their components (including sideloaded DLLs and Java/installer payloads), enabling remote code execution on affected systems. MicroWorld eScan confirmed remediation of the update mechanism on 2023-07-31 but versioning details are unavailable. NOTE: MicroWorld eScan disputes the characterization in third-party reports, stating the issue relates to 2018–2019 and that controls were implemented then. |
| JWT is a library to work with JSON Web Token and JSON Web Signature. Prior to versions 3.4.6, 4.0.4, and 4.1.5, users of HMAC-based algorithms (HS256, HS384, and HS512) combined with `Lcobucci\JWT\Signer\Key\LocalFileReference` as key are having their tokens issued/validated using the file path as hashing key - instead of the contents. The HMAC hashing functions take any string as input and, since users can issue and validate tokens, users are lead to believe that everything works properly. Versions 3.4.6, 4.0.4, and 4.1.5 have been patched to always load the file contents, deprecated the `Lcobucci\JWT\Signer\Key\LocalFileReference`, and suggest `Lcobucci\JWT\Signer\Key\InMemory` as the alternative. As a workaround, use `Lcobucci\JWT\Signer\Key\InMemory` instead of `Lcobucci\JWT\Signer\Key\LocalFileReference` to create the instances of one's keys. |
| jitsi-meet-electron (aka Jitsi Meet Electron) before 2.3.0 calls the Electron shell.openExternal function without verifying that the URL is for an http or https resource, in some circumstances. |
| Nagios XI versions prior to 2024R1.2.2 contain a host header injection vulnerability. The application trusts the user-supplied HTTP Host header when constructing absolute URLs without sufficient validation. An unauthenticated, remote attacker can supply a crafted Host header to poison generated links or responses, which may facilitate phishing of credentials, account recovery link hijacking, and web cache poisoning. |
| An insufficient verification of data authenticity vulnerability exists in BIG-IP APM Access Policy endpoint inspection that may allow an attacker to bypass endpoint inspection checks for VPN connection initiated thru BIG-IP APM browser network access VPN client for Windows, macOS and Linux.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. |
| A vulnerability has been identified in SICAM GridEdge (Classic) (All versions < V2.6.6). The affected software does not apply cross-origin resource sharing (CORS) restrictions for critical operations. In case an attacker tricks a legitimate user into accessing a special resource a malicious request could be executed. |
| A flaw was found in the Open Virtual Network (OVN). In OVN clusters where BFD is used between hypervisors for high availability, an attacker can inject specially crafted BFD packets from inside unprivileged workloads, including virtual machines or containers, that can trigger a denial of service. |
| A flaw was found in Booth, a cluster ticket manager. If a specially-crafted hash is passed to gcry_md_get_algo_dlen(), it may allow an invalid HMAC to be accepted by the Booth server. |
| Under certain circumstances, BIND is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache.
This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1. |
| Improper authentication in the API authentication middleware of HCL DevOps Loop allows authentication tokens to be accepted without proper validation of their expiration and cryptographic signature. As a result, an attacker could potentially use expired or tampered tokens to gain unauthorized access to sensitive resources and perform actions with elevated privileges. |
