Total
95313 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-43742 | 2025-08-20 | N/A | N/A | ||
| A reflected cross-site scripting (XSS) vulnerability in the Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q1.0 through 2025.Q1.3, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.1 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.14 and 7.4 GA through update 92 allows an remote non-authenticated attacker to inject JavaScript in web content for friendly urls. | |||||
| CVE-2025-43750 | 2025-08-20 | N/A | N/A | ||
| Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q1.0 through 2025.Q1.1, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.1 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.19 and 7.4 GA through update 92 allows remote unauthenticated users (guests) to upload files via the form attachment field without proper validation, enabling extension obfuscation and bypassing MIME type checks. | |||||
| CVE-2025-8449 | 2025-08-20 | N/A | N/A | ||
| CWE-400: Uncontrolled Resource Consumption vulnerability exists that could cause a denial of service when an authenticated user sends a specially crafted request to a specific endpoint from within the BMS network. | |||||
| CVE-2025-43749 | 2025-08-20 | N/A | N/A | ||
| Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q1.0 through 2025.Q1.1, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.1 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.14 and 7.4 GA through update 92 allows unauthenticated users (guests) to access via URL files uploaded in the form and stored in document_library | |||||
| CVE-2013-5714 | 2 Videowhisper, Wordpress | 3 Live Streaming Integration Plugin, Videowhisper Live Streaming Integration, Wordpress | 2025-08-20 | 4.3 MEDIUM | N/A |
| Multiple cross-site scripting (XSS) vulnerabilities in ls/htmlchat.php in the VideoWhisper Live Streaming Integration plugin 4.25.3 and possibly earlier for WordPress allow remote attackers to inject arbitrary web script or HTML via the (1) name or (2) message parameter. NOTE: some of these details are obtained from third party information. | |||||
| CVE-2014-1907 | 2 Videowhisper, Wordpress | 3 Live Streaming Integration Plugin, Videowhisper Live Streaming Integration, Wordpress | 2025-08-20 | 6.4 MEDIUM | N/A |
| Multiple directory traversal vulnerabilities in the VideoWhisper Live Streaming Integration plugin before 4.29.5 for WordPress allow remote attackers to (1) read arbitrary files via a .. (dot dot) in the s parameter to ls/rtmp_login.php or (2) delete arbitrary files via a .. (dot dot) in the s parameter to ls/rtmp_logout.php. | |||||
| CVE-2014-1906 | 1 Videowhisper | 2 Live Streaming Integration Plugin, Videowhisper Live Streaming Integration | 2025-08-20 | 4.3 MEDIUM | N/A |
| Multiple cross-site scripting (XSS) vulnerabilities in the VideoWhisper Live Streaming Integration plugin before 4.29.5 for WordPress allow remote attackers to inject arbitrary web script or HTML via the (1) m parameter to lb_status.php; (2) msg parameter to vc_chatlog.php; n parameter to (3) channel.php, (4) htmlchat.php, (5) video.php, or (6) videotext.php; (7) message parameter to lb_logout.php; or ct parameter to (8) lb_status.php or (9) v_status.php in ls/. | |||||
| CVE-2025-57748 | 2025-08-20 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57747 | 2025-08-20 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57746 | 2025-08-20 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57745 | 2025-08-20 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57744 | 2025-08-20 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57743 | 2025-08-20 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-57742 | 2025-08-20 | N/A | N/A | ||
| Rejected reason: Not used | |||||
| CVE-2025-55153 | 2025-08-19 | N/A | N/A | ||
| Rejected reason: This CVE is a duplicate of another CVE. | |||||
| CVE-2025-8782 | 2025-08-19 | N/A | N/A | ||
| Rejected reason: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. Reason: This candidate was issued in error. Notes: All references and descriptions in this candidate have been removed to prevent accidental usage. | |||||
| CVE-2025-43740 | 2025-08-19 | N/A | N/A | ||
| A Stored cross-site scripting vulnerability in the Liferay Portal 7.4.3.120 through 7.4.3.132, and Liferay DXP 2025.Q2.0 through 2025.Q2.8, 2025.Q1.0 through 2025.Q1.15, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.1 through 2024.Q3.13, 2024.Q2.1 through 2024.Q2.13 and 2024.Q1.9 through 2024.Q1.19 allows an remote authenticated attacker to inject JavaScript through the message boards feature available via the web interface. | |||||
| 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-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 | |||||