Total
495 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2006-5170 | 3 Debian, Fedoraproject, Redhat | 8 Debian Linux, Fedora Core, Enterprise Linux and 5 more | 2024-11-21 | 7.5 HIGH | N/A |
| pam_ldap in nss_ldap on Red Hat Enterprise Linux 4, Fedora Core 3 and earlier, and possibly other distributions does not return an error condition when an LDAP directory server responds with a PasswordPolicyResponse control response, which causes the pam_authenticate function to return a success code even if authentication has failed, as originally reported for xscreensaver. | |||||
| CVE-2024-50202 | 1 Linux | 1 Linux Kernel | 2024-11-19 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together. | |||||
| CVE-2024-8376 | 1 Eclipse | 1 Mosquitto | 2024-11-15 | N/A | 7.5 HIGH |
| In Eclipse Mosquitto up to version 2.0.18a, an attacker can achieve memory leaking, segmentation fault or heap-use-after-free by sending specific sequences of "CONNECT", "DISCONNECT", "SUBSCRIBE", "UNSUBSCRIBE" and "PUBLISH" packets. | |||||
| CVE-2024-9413 | 2024-11-15 | N/A | N/A | ||
| The transport_message_handler function in SCP-Firmware release versions 2.11.0-2.15.0 does not properly handle errors, potentially allowing an Application Processor (AP) to cause a buffer overflow in System Control Processor (SCP) firmware. | |||||
| CVE-2024-51502 | 2024-11-05 | N/A | N/A | ||
| loona is an experimental, HTTP/1.1 and HTTP/2 implementation in Rust on top of io-uring. `loona-hpack` suffers from the same vulnerability as the original `hpack` as documented in issue #11. All users who try to decode untrusted input using the Decoder are vulnerable to this exploit. This issue has been addressed in release version 0.4.3. All users are advised to upgrade. There are no known workarounds for this vulnerability. | |||||
| CVE-2024-51744 | 2024-11-05 | N/A | 3.1 LOW | ||
| golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above. | |||||
| CVE-2024-3152 | 1 Mintplexlabs | 1 Anythingllm | 2024-11-04 | N/A | 8.8 HIGH |
| mintplex-labs/anything-llm is vulnerable to multiple security issues due to improper input validation in several endpoints. An attacker can exploit these vulnerabilities to escalate privileges from a default user role to an admin role, read and delete arbitrary files on the system, and perform Server-Side Request Forgery (SSRF) attacks. The vulnerabilities are present in the `/request-token`, `/workspace/:slug/thread/:threadSlug/update`, `/system/remove-logo`, `/system/logo`, and collector's `/process` endpoints. These issues are due to the application's failure to properly validate user input before passing it to `prisma` functions and other critical operations. Affected versions include the latest version prior to 1.0.0. | |||||
| CVE-2024-3150 | 1 Mintplexlabs | 1 Anythingllm | 2024-11-04 | N/A | 8.8 HIGH |
| In mintplex-labs/anything-llm, a vulnerability exists in the thread update process that allows users with Default or Manager roles to escalate their privileges to Administrator. The issue arises from improper input validation when handling HTTP POST requests to the endpoint `/workspace/:slug/thread/:threadSlug/update`. Specifically, the application fails to validate or check user input before passing it to the `workspace_thread` Prisma model for execution. This oversight allows attackers to craft a Prisma relation query operation that manipulates the `users` model to change a user's role to admin. Successful exploitation grants attackers the highest level of user privileges, enabling them to see and perform all actions within the system. | |||||
| CVE-2024-50001 | 1 Linux | 1 Linux Kernel | 2024-10-30 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure. | |||||
| CVE-2024-50002 | 1 Linux | 1 Linux Kernel | 2024-10-30 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; }; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer. | |||||
| CVE-2023-5824 | 2 Redhat, Squid-cache | 2 Enterprise Linux, Squid | 2024-10-24 | N/A | 7.5 HIGH |
| A flaw was found in Squid. The limits applied for validation of HTTP response headers are applied before caching. However, Squid may grow a cached HTTP response header beyond the configured maximum size, causing a stall or crash of the worker process when a large header is retrieved from the disk cache, resulting in a denial of service. | |||||
| CVE-2023-34348 | 1 Aveva | 1 Pi Server | 2024-10-21 | N/A | 7.5 HIGH |
| AVEVA PI Server versions 2023 and 2018 SP3 P05 and prior contain a vulnerability that could allow an unauthenticated user to remotely crash the PI Message Subsystem of a PI Server, resulting in a denial-of-service condition. | |||||
| CVE-2021-42142 | 1 Contiki-ng | 1 Tinydtls | 2024-10-21 | N/A | 9.8 CRITICAL |
| An issue was discovered in Contiki-NG tinyDTLS through master branch 53a0d97. DTLS servers mishandle the early use of a large epoch number. This vulnerability allows remote attackers to cause a denial of service and false-positive packet drops. | |||||
| CVE-2024-47491 | 2024-10-17 | N/A | 5.9 MEDIUM | ||
| An Improper Handling of Exceptional Conditions vulnerability in the Routing Protocol Daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows a network-based, unauthenticated attacker to cause Denial of Service (DoS). When a BGP UPDATE with malformed path attribute is received over an established BGP session, rpd crashes and restarts. Continuous receipt of a BGP UPDATE with a specifically malformed path attribute will create a sustained Denial of Service (DoS) condition for impacted devices. While this issue affects systems running 32-bit and 64-bit systems, the probability of impact on 64-bit system is extremely low. According to KB25803 https://supportportal.juniper.net/s/article/Junos-How-to-check-if-Junos-OS-is-64-or-32-bit-on-a-router , customers can confirm 32-bit or 64-bit system via the ' show version detail ' command: lab@router> show version detail| match 32 JUNOS 32-bit kernel Software Suite lab@router> show version detail| match 64 JUNOS 64-bit kernel Software Suite This issue affects: Juniper Networks Junos OS: * All versions before 21.4R3-S8, * from 22.2 before 22.2R3-S4, * from 22.4 before 22.4R3-S3, * from 23.2 before 23.2R2-S1, * from 23.4 before 23.4R1-S2, 23.4R2. Juniper Networks Junos OS Evolved: * All versions before 21.4R3-S8-EVO, * from 22.2 before 22.2R3-S4-EVO, * from 22.4 before 22.4R3-S3-EVO, * from 23.2 before 23.2R2-S1-EVO, * from 23.4 before 23.4R1-S2-EVO, 23.4R2-EVO. | |||||
| CVE-2024-47767 | 1 Enalean | 1 Tuleap | 2024-10-17 | N/A | 4.3 MEDIUM |
| Tuleap is a tool for end to end traceability of application and system developments. Prior to Tuleap Community Edition 15.13.99.113, Tuleap Enterprise Edition 15.13-5, and Tuleap Enterprise Edition 15.12-5, users might see tracker names they should not have access to. Tuleap Community Edition 15.13.99.113, Tuleap Enterprise Edition 15.13-5, and Tuleap Enterprise Edition 15.12-8 fix this issue. | |||||
| CVE-2024-47766 | 1 Enalean | 1 Tuleap | 2024-10-17 | N/A | 4.9 MEDIUM |
| Tuleap is a tool for end to end traceability of application and system developments. Prior to Tuleap Community Edition 15.13.99.110, Tuleap Enterprise Edition 15.13-5, and Tuleap Enterprise Edition 15.12-5, administrators of a project can access the content of trackers with permissions restrictions of project they are members of but not admin via the cross tracker search widget. Tuleap Community Edition 15.13.99.110, Tuleap Enterprise Edition 15.13-5, and Tuleap Enterprise Edition 15.12-8 fix this issue. | |||||
| CVE-2024-46988 | 1 Enalean | 1 Tuleap | 2024-10-16 | N/A | 5.7 MEDIUM |
| Tuleap is a tool for end to end traceability of application and system developments. Prior to Tuleap Community Edition 15.13.99.40, Tuleap Enterprise Edition 15.13-3, and Tuleap Enterprise Edition 15.12-6, users might receive email notification with information they should not have access to. Tuleap Community Edition 15.13.99.40, Tuleap Enterprise Edition 15.13-3, and Tuleap Enterprise Edition 15.12-6 fix this issue. | |||||
| CVE-2024-36730 | 1 Oneflow | 1 Oneflow | 2024-10-15 | N/A | 7.5 HIGH |
| Improper input validation in OneFlow-Inc. Oneflow v0.9.1 allows attackers to cause a Denial of Service (DoS) via inputting negative values into the oneflow.zeros/ones parameter. | |||||
| CVE-2024-47489 | 2024-10-15 | N/A | 5.8 MEDIUM | ||
| An Improper Handling of Exceptional Conditions vulnerability in the Packet Forwarding Engine (pfe) of the Juniper Networks Junos OS Evolved on ACX Series devices allows an unauthenticated, network based attacker sending specific transit protocol traffic to cause a partial Denial of Service (DoS) to downstream devices. Receipt of specific transit protocol packets is incorrectly processed by the Routing Engine (RE), filling up the DDoS protection queue which is shared between routing protocols. This influx of transit protocol packets causes DDoS protection violations, resulting in protocol flaps which can affect connectivity to networking devices. This issue affects both IPv4 and IPv6. This issue does not require any specific routing protocol to be configured or enabled. The following commands can be used to monitor the DDoS protection queue: labuser@re0> show evo-pfemand host pkt-stats ?? labuser@re0> show host-path ddos all-policers This issue affects Junos OS Evolved: * All versions before 21.4R3-S8-EVO, * from 22.2 before 22.2R3-S4-EVO, * from 22.3 before 22.3R3-S4-EVO, * from 22.4 before 22.4R3-S3-EVO, * from 23.2 before 23.2R2-EVO, * from 23.4 before 23.4R1-S1-EVO, 23.4R2-EVO, * from 24.2 before 24.2R2-EVO. | |||||
| CVE-2024-39547 | 2024-10-15 | N/A | 7.5 HIGH | ||
| An Improper Handling of Exceptional Conditions vulnerability in the rpd-server of Juniper Networks Junos OS and Junos OS Evolved within cRPD allows an unauthenticated network-based attacker sending crafted TCP traffic to the routing engine (RE) to cause a CPU-based Denial of Service (DoS). If specially crafted TCP traffic is received by the control plane, or a TCP session terminates unexpectedly, it will cause increased control plane CPU utilization by the rpd-server process. While not explicitly required, the impact is more severe when RIB sharding is enabled. Task accounting shows unexpected reads by the RPD Server jobs for shards: user@junos> show task accounting detail ... read:RPD Server.0.0.0.0+780.192.168.0.78+48886 TOT:00000003.00379787 MAX:00000000.00080516 RUNS: 233888\ read:RPD Server.0.0.0.0+780.192.168.0.78+49144 TOT:00000004.00007565 MAX:00000000.00080360 RUNS: 233888\ read:RPD Server.0.0.0.0+780.192.168.0.78+49694 TOT:00000003.00600584 MAX:00000000.00080463 RUNS: 233888\ read:RPD Server.0.0.0.0+780.192.168.0.78+50246 TOT:00000004.00346998 MAX:00000000.00080338 RUNS: 233888\ This issue affects: Junos OS with cRPD: * All versions before 21.2R3-S8, * 21.4 before 21.4R3-S7, * 22.1 before 22.1R3-S6, * 22.2 before 22.2R3-S4, * 22.3 before 22.3R3-S3, * 22.4 before 22.4R3-S2, * 23.2 before 23.2R2-S2, * 24.2 before 24.2R2; Junos OS Evolved with cRPD: * All versions before 21.4R3-S7-EVO, * 22.2 before 22.2R3-S4-EVO, * 22.3 before 22.3R3-S3-EVO, * 22.4 before 22.4R3-S2-EVO, * 23.2 before 23.2R2-EVO. | |||||