Total
673 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-35888 | 1 Amperecomputing | 6 Ampere Altra, Ampere Altra Firmware, Ampere Altra Max and 3 more | 2025-05-20 | 6.5 Medium |
| Ampere Altra and Ampere Altra Max devices through 2022-07-15 allow attacks via Hertzbleed, which is a power side-channel attack that extracts secret information from the CPU by correlating the power consumption with data being processed on the system. | ||||
| CVE-2024-5124 | 1 Gaizhenbiao | 1 Chuanhuchatgpt | 2025-05-20 | 7.5 High |
| A timing attack vulnerability exists in the gaizhenbiao/chuanhuchatgpt repository, specifically within the password comparison logic. The vulnerability is present in version 20240310 of the software, where passwords are compared using the '=' operator in Python. This method of comparison allows an attacker to guess passwords based on the timing of each character's comparison. The issue arises from the code segment that checks a password for a particular username, which can lead to the exposure of sensitive information to an unauthorized actor. An attacker exploiting this vulnerability could potentially guess user passwords, compromising the security of the system. | ||||
| CVE-2024-42174 | 1 Hcltech | 1 Dryice Myxalytics | 2025-05-16 | 3.7 Low |
| HCL MyXalytics is affected by username enumeration vulnerability. This allows a malicious user to perform enumeration of application users, and therefore compile a list of valid usernames. | ||||
| CVE-2024-25146 | 1 Liferay | 3 Digital Experience Platform, Dxp, Liferay Portal | 2025-05-15 | 5.3 Medium |
| Liferay Portal 7.2.0 through 7.4.1, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 18, and older unsupported versions returns with different responses depending on whether a site does not exist or if the user does not have permission to access the site, which allows remote attackers to discover the existence of sites by enumerating URLs. This vulnerability occurs if locale.prepend.friendly.url.style=2 and if a custom 404 page is used. | ||||
| CVE-2021-36201 | 1 Johnsoncontrols | 2 C-cure 9000, C-cure 9000 Firmware | 2025-05-15 | 4.3 Medium |
| Under certain circumstances a CCURE Portal user could enumerate user accounts in CCURE 9000 version 2.90 and prior versions. | ||||
| CVE-2017-13098 | 1 Bouncycastle | 1 Bc-java | 2025-05-12 | N/A |
| BouncyCastle TLS prior to version 1.0.3, when configured to use the JCE (Java Cryptography Extension) for cryptographic functions, provides a weak Bleichenbacher oracle when any TLS cipher suite using RSA key exchange is negotiated. An attacker can recover the private key from a vulnerable application. This vulnerability is referred to as "ROBOT." | ||||
| CVE-2022-43412 | 1 Jenkins | 1 Generic Webhook Trigger | 2025-05-08 | 5.3 Medium |
| Jenkins Generic Webhook Trigger Plugin 1.84.1 and earlier uses a non-constant time comparison function when checking whether the provided and expected webhook token are equal, potentially allowing attackers to use statistical methods to obtain a valid webhook token. | ||||
| CVE-2022-43411 | 1 Jenkins | 1 Gitlab | 2025-05-08 | 5.3 Medium |
| Jenkins GitLab Plugin 1.5.35 and earlier uses a non-constant time comparison function when checking whether the provided and expected webhook token are equal, potentially allowing attackers to use statistical methods to obtain a valid webhook token. | ||||
| CVE-2022-40084 | 1 Opencrx | 1 Opencrx | 2025-05-08 | 5.3 Medium |
| OpenCRX before v5.2.2 was discovered to be vulnerable to password enumeration due to the difference in error messages received during a password reset which could enable an attacker to determine if a username, email or ID is valid. | ||||
| CVE-2021-45925 | 1 Lannerinc | 2 Iac-ast2500a, Iac-ast2500a Firmware | 2025-05-07 | 5.3 Medium |
| Observable discrepancies in the login process allow an attacker to guess legitimate user names registered in the BMC. This issue affects: Lanner Inc IAC-AST2500A standard firmware version 1.10.0. | ||||
| CVE-2017-5715 | 8 Arm, Canonical, Debian and 5 more | 230 Cortex-a, Ubuntu Linux, Debian Linux and 227 more | 2025-05-06 | 5.6 Medium |
| Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis. | ||||
| CVE-2025-46720 | 2025-05-05 | 3.1 Low | ||
| Keystone is a content management system for Node.js. Prior to version 6.5.0, `{field}.isFilterable` access control can be bypassed in `update` and `delete` mutations by adding additional unique filters. These filters can be used as an oracle to probe the existence or value of otherwise unreadable fields. Specifically, when a mutation includes a `where` clause with multiple unique filters (e.g. `id` and `email`), Keystone will attempt to match records even if filtering by the latter fields would normally be rejected by `field.isFilterable` or `list.defaultIsFilterable`. This can allow malicious actors to infer the presence of a particular field value when a filter is successful in returning a result. This affects any project relying on the default or dynamic `isFilterable` behavior (at the list or field level) to prevent external users from using the filtering of fields as a discovery mechanism. While this access control is respected during `findMany` operations, it was not completely enforced during `update` and `delete` mutations when accepting more than one unique `where` values in filters. This has no impact on projects using `isFilterable: false` or `defaultIsFilterable: false` for sensitive fields, or for those who have otherwise omitted filtering by these fields from their GraphQL schema. This issue has been patched in `@keystone-6/core` version 6.5.0. To mitigate this issue in older versions where patching is not a viable pathway, set `isFilterable: false` statically for relevant fields to prevent filtering by them earlier in the access control pipeline (that is, don't use functions); set `{field}.graphql.omit.read: true` for relevant fields, which implicitly removes filtering by these fields from the GraphQL schema; and/or deny `update` and `delete` operations for the relevant lists completely. | ||||
| CVE-2022-24436 | 1 Intel | 1 * | 2025-05-05 | 6.5 Medium |
| Observable behavioral in power management throttling for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via network access. | ||||
| CVE-2022-21659 | 1 Dpgaspar | 1 Flask-appbuilder | 2025-05-05 | 5.3 Medium |
| Flask-AppBuilder is an application development framework, built on top of the Flask web framework. In affected versions there exists a user enumeration vulnerability. This vulnerability allows for a non authenticated user to enumerate existing accounts by timing the response time from the server when you are logging in. Users are advised to upgrade to version 3.4.4 as soon as possible. There are no known workarounds for this issue. | ||||
| CVE-2021-33149 | 1 Intel | 16 Atom Processors, Atom Processors Firmware, Celeron Processors and 13 more | 2025-05-05 | 5.5 Medium |
| Observable behavioral discrepancy in some Intel(R) Processors may allow an authorized user to potentially enable information disclosure via local access. | ||||
| CVE-2024-50102 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86: fix user address masking non-canonical speculation issue It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result: CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“ Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window. But that was true only up until Zen 5, which renames the AC bit [1]. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open. Note that this affects not just the new address masking, but also the regular valid_user_address() check used by access_ok(), and the asm version of the sign bit check in the get_user() helpers. It does not affect put_user() or clear_user() variants, since there's no speculative result to be used in a gadget for those operations. | ||||
| CVE-2024-47678 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation. | ||||
| CVE-2022-48730 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dma-buf: heaps: Fix potential spectre v1 gadget It appears like nr could be a Spectre v1 gadget as it's supplied by a user and used as an array index. Prevent the contents of kernel memory from being leaked to userspace via speculative execution by using array_index_nospec. [sumits: added fixes and cc: stable tags] | ||||
| CVE-2021-47226 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer Both Intel and AMD consider it to be architecturally valid for XRSTOR to fail with #PF but nonetheless change the register state. The actual conditions under which this might occur are unclear [1], but it seems plausible that this might be triggered if one sibling thread unmaps a page and invalidates the shared TLB while another sibling thread is executing XRSTOR on the page in question. __fpu__restore_sig() can execute XRSTOR while the hardware registers are preserved on behalf of a different victim task (using the fpu_fpregs_owner_ctx mechanism), and, in theory, XRSTOR could fail but modify the registers. If this happens, then there is a window in which __fpu__restore_sig() could schedule out and the victim task could schedule back in without reloading its own FPU registers. This would result in part of the FPU state that __fpu__restore_sig() was attempting to load leaking into the victim task's user-visible state. Invalidate preserved FPU registers on XRSTOR failure to prevent this situation from corrupting any state. [1] Frequent readers of the errata lists might imagine "complex microarchitectural conditions". | ||||
| CVE-2024-26221 | 1 Microsoft | 4 Windows Server 2016, Windows Server 2019, Windows Server 2022 and 1 more | 2025-05-03 | 7.2 High |
| Windows DNS Server Remote Code Execution Vulnerability | ||||