Total
306695 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-1274 | 1 Autodesk | 1 Revit | 2025-08-19 | N/A | 7.8 HIGH |
| A maliciously crafted RCS file, when parsed through Autodesk Revit, can force an Out-of-Bounds Write vulnerability. A malicious actor may leverage this vulnerability to cause a crash, cause data corruption, or execute arbitrary code in the context of the current process. | |||||
| CVE-2025-1273 | 1 Autodesk | 1 Revit | 2025-08-19 | N/A | 7.8 HIGH |
| A maliciously crafted PDF file, when linked or imported into Autodesk applications, can force a Heap-Based Overflow vulnerability. A malicious actor can leverage this vulnerability to cause a crash, read sensitive data, or execute arbitrary code in the context of the current process. | |||||
| CVE-2025-27071 | 1 Qualcomm | 68 Fastconnect 6800, Fastconnect 6800 Firmware, Fastconnect 6900 and 65 more | 2025-08-19 | N/A | 7.3 HIGH |
| Memory corruption while processing specific files in Powerline Communication Firmware. | |||||
| CVE-2025-27076 | 1 Qualcomm | 90 Aqt1000, Aqt1000 Firmware, Fastconnect 6200 and 87 more | 2025-08-19 | N/A | 7.8 HIGH |
| Memory corruption while processing simultaneous requests via escape path. | |||||
| CVE-2024-49785 | 1 Ibm | 2 Watsonx.ai, Watsonx.ai On Cloud Pak For Data | 2025-08-19 | N/A | 5.4 MEDIUM |
| IBM watsonx.ai 1.1 through 2.0.3 and IBM watsonx.ai on Cloud Pak for Data 4.8 through 5.0.3 is vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. | |||||
| CVE-2025-49797 | 2025-08-19 | N/A | 7.8 HIGH | ||
| Multiple Brother driver installers for Windows contain a privilege escalation vulnerability. If exploited, an arbitrary program may be executed with the administrative privilege. As for the details of affected product names, model numbers, and versions, refer to the information provided by the respective vendors listed under [References]. | |||||
| CVE-2025-7867 | 1 Portabilis | 1 I-educar | 2025-08-19 | 4.0 MEDIUM | 3.5 LOW |
| A vulnerability has been found in Portabilis i-Educar 2.9.0/2.10.0. This vulnerability affects unknown code of the file /intranet/agenda.php of the component Agenda Module. The manipulation of the argument novo_titulo/novo_descricao leads to cross site scripting. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2025-38349 | 2025-08-19 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. That's very wrong, because it can lead to a use-after-free. That pattern is actually fine for the very last reference, because the code in question will delay the actual call to "ep_free(ep)" until after it has unlocked the mutex. But it's wrong for the much subtler "next to last" case when somebody *else* may also be dropping their reference and free the ep while we're still using the mutex. Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion. A mutex "unlock" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up. See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics: "mutex_unlock() may access the mutex structure even after it has internally released the lock already - so it's not safe for another context to acquire the mutex and assume that the mutex_unlock() context is not using the structure anymore" So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops _their_ reference and releases the 'ep' as it now has no users - all while the mutex_unlock() is still accessing it. Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole _point_ of refcounts: unlike mutexes, they are inherently about object lifetimes). | |||||
| CVE-2025-8734 | 2025-08-19 | 1.7 LOW | 3.3 LOW | ||
| A vulnerability has been found in GNU Bison up to 3.8.2. This impacts the function code_free of the file src/scan-code.c. The manipulation leads to double free. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The actual existence of this vulnerability is currently in question. The issue could not be reproduced from a GNU Bison 3.8.2 tarball run in a Fedora 42 container. | |||||
| CVE-2025-8733 | 2025-08-19 | 1.7 LOW | 3.3 LOW | ||
| A flaw has been found in GNU Bison up to 3.8.2. This affects the function __obstack_vprintf_internal of the file obprintf.c. Executing manipulation can lead to reachable assertion. The attack requires local access. The exploit has been published and may be used. It is still unclear if this vulnerability genuinely exists. The issue could not be reproduced from a GNU Bison 3.8.2 tarball run in a Fedora 42 container. | |||||
| CVE-2025-57725 | 2025-08-19 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57724 | 2025-08-19 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57723 | 2025-08-19 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57722 | 2025-08-19 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57721 | 2025-08-19 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57720 | 2025-08-19 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57719 | 2025-08-19 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57718 | 2025-08-19 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57717 | 2025-08-19 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2024-3094 | 1 Tukaani | 1 Xz | 2025-08-19 | N/A | 10.0 CRITICAL |
| Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting and modifying the data interaction with this library. | |||||