Export limit exceeded: 19879 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 19879 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (19879 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-29071 | 1 Arista | 1 Cloudvision Portal | 2026-06-02 | 4 Medium |
| This advisory documents an internally found vulnerability in the on premises deployment model of Arista CloudVision Portal (CVP) where under a certain set of conditions, user passwords can be leaked in the Audit and System logs. The impact of this vulnerability is that the CVP user login passwords might be leaked to other authenticated users. | ||||
| CVE-2021-46678 | 1 Pandorafms | 1 Pandora Fms | 2026-06-02 | 4 Medium |
| A XSS vulnerability exist in Pandora FMS version 756 and below, that allows an attacker to perform javascript code executions via the service name field. | ||||
| CVE-2021-46680 | 1 Pandorafms | 1 Pandora Fms | 2026-06-02 | 4 Medium |
| A XSS vulnerability exist in Pandora FMS version 756 and below, that allows an attacker to perform javascript code executions via the module form name field. | ||||
| CVE-2021-46677 | 1 Pandorafms | 1 Pandora Fms | 2026-06-02 | 4 Medium |
| A XSS vulnerability exist in Pandora FMS version 756 and below, that allows an attacker to perform javascript code executions via the event filter name field. | ||||
| CVE-2021-46676 | 1 Pandorafms | 1 Pandora Fms | 2026-06-02 | 4 Medium |
| A XSS vulnerability exist in Pandora FMS version 756 and below, that allows an attacker to perform javascript code executions via the transactional maps name field. | ||||
| CVE-2021-46679 | 1 Pandorafms | 1 Pandora Fms | 2026-06-02 | 4 Medium |
| A XSS vulnerability exist in Pandora FMS version 756 and below, that allows an attacker to perform javascript code executions via service elements. | ||||
| CVE-2021-46681 | 1 Artica | 1 Pandora Fms | 2026-06-02 | 4 Medium |
| A XSS vulnerability exist in Pandora FMS version 756 and below, that allows an attacker to perform javascript code executions via module massive operation name field. | ||||
| CVE-2022-34768 | 1 Supersmart | 1 Supersmart.me - Walk Through | 2026-06-02 | 6.5 Medium |
| insert HTML / js code inside input how to get to the vulnerable input : Workers > worker nickname > inject in this input the code. | ||||
| CVE-2024-7872 | 1 Extremepacs | 1 Extreme Xds | 2026-06-02 | 7.6 High |
| Insertion of Sensitive Information Into Sent Data vulnerability in ExtremePACS Extreme XDS allows Retrieve Embedded Sensitive Data. This issue affects Extreme XDS: before 3933. | ||||
| CVE-2024-11142 | 1 Proticaret | 1 Proticaret | 2026-06-02 | 8.8 High |
| Cross-Site Request Forgery (CSRF) vulnerability in Gosoft Software Proticaret E-Commerce allows Cross Site Request Forgery. This issue affects Proticaret E-Commerce: before v6.0 NOTE: According to the vendor, fixing process is still ongoing for v4.05. | ||||
| CVE-2024-11216 | 2026-06-02 | 7.6 High | ||
| Authorization Bypass Through User-Controlled Key, Exposure of Private Personal Information to an Unauthorized Actor vulnerability in PozitifIK Pik Online allows Account Footprinting, Session Hijacking. This issue affects Pik Online: before 3.1.5. | ||||
| CVE-2024-12097 | 2026-06-02 | 9.8 Critical | ||
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Boceksoft Informatics E-Travel allows SQL Injection. This issue affects E-Travel: before 15.12.2024. | ||||
| CVE-2026-44420 | 1 Freerdp | 1 Freerdp | 2026-06-02 | 8.8 High |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.26.0, a malicious RDP client can trigger a heap-buffer-overflow write in FreeRDP's server-side clipboard (cliprdr) channel by sending a CB_CLIP_CAPS PDU with a too-small capabilitySetLength. This can crash the server process (remote DoS) and may be exploitable for code execution because it corrupts heap memory. This vulnerability is fixed in 3.26.0. | ||||
| CVE-2026-44825 | 1 Apache | 1 Solr | 2026-06-01 | 8.1 High |
| Hardcoded credentials in the Basic Authentication setup tool (bin/solr auth enable) in Apache Solr versions 9.4.0 through 9.10.1 and 10.0.0 allows a remote attacker to gain full administrative access to the cluster via publicly known default credentials installed silently alongside the user-specified account. As an immediate workaround without upgrading, delete the template users (superadmin, admin, search, index) from security.json or change their passwords. The future, not yet released, versions 9.11.0 and 10.1.0 will not be vulnerable, and it will be enough to upgrade to solve the issue. Not affected: * Clusters where bin/solr auth enable was not used to bootstrap BasicAuth * Clusters where template users have been assigned strong passwords after bootstrap | ||||
| CVE-2026-44421 | 1 Freerdp | 1 Freerdp | 2026-06-01 | 8.8 High |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.26.0, a malicious RDP server can trigger a heap-buffer-overflow write in the FreeRDP client by sending crafted RDPGFX PDUs. The bug is in gdi_CacheToSurface: it validates a destination rectangle that is clamped to UINT16_MAX, but then performs the copy using the original cacheEntry->width/height. This can cause a large out-of-bounds heap write and may lead to client crashes or code execution. This bug is reachable from a malicious RDP server, but only when the client has RDPGFX enabled. This vulnerability is fixed in 3.26.0. | ||||
| CVE-2026-44422 | 1 Freerdp | 1 Freerdp | 2026-06-01 | 7.5 High |
| FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.26.0, FreeRDP's RDPEAR NDR parser accepts one non-null NDR pointer ref-id for multiple logical pointer fields without tracking the pointed object's expected NDR type or ownership. When the same ref-id is reused across two pointer fields, the parser assigns the same heap object to both output fields. The generic destructor later walks each field independently and destroys/frees both pointers. This causes a malicious-server-triggerable heap use-after-free / double-free in the FreeRDP client's RDPEAR authentication-redirection path. This vulnerability is fixed in 3.26.0. | ||||
| CVE-2025-23366 | 1 Redhat | 4 Hal Management Console, Jboss Data Grid, Jboss Enterprise Application Platform and 1 more | 2026-06-01 | 6.5 Medium |
| A flaw was found in the HAL Console in the Wildfly component, which does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output used as a web page that is served to other users. The attacker must be authenticated as a user that belongs to management groups “SuperUser”, “Admin”, or “Maintainer”. | ||||
| CVE-2026-46385 | 1 Iskorotkov | 1 Avro | 2026-06-01 | 7.5 High |
| iskorotkov/avro is a fast Go Avro codec. Prior to 2.33.0, the Avro array and map decoders looped over an attacker-controlled block-count value without checking the underlying reader's error state inside the loop body. Reader.ReadBlockHeader returns the count as a Go int, which is 64-bit on amd64 / arm64 targets — so a producer can declare a block of up to math.MaxInt64 (~9.2 × 10¹⁸) elements followed by EOF (or any truncated payload), and the decoder will attempt that many no-op iterations before propagating the error. The realistic ceiling is "indefinite until the worker is killed externally" — a single hostile payload pins a CPU core until the process is OOM-killed, deadline-cancelled, or terminated. Remote, unauthenticated denial-of-service. This vulnerability is fixed in 2.33.0. | ||||
| CVE-2026-31676 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test. | ||||
| CVE-2026-23394 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: af_unix: Give up GC if MSG_PEEK intervened. Igor Ushakov reported that GC purged the receive queue of an alive socket due to a race with MSG_PEEK with a nice repro. This is the exact same issue previously fixed by commit cbcf01128d0a ("af_unix: fix garbage collect vs MSG_PEEK"). After GC was replaced with the current algorithm, the cited commit removed the locking dance in unix_peek_fds() and reintroduced the same issue. The problem is that MSG_PEEK bumps a file refcount without interacting with GC. Consider an SCC containing sk-A and sk-B, where sk-A is close()d but can be recv()ed via sk-B. The bad thing happens if sk-A is recv()ed with MSG_PEEK from sk-B and sk-B is close()d while GC is checking unix_vertex_dead() for sk-A and sk-B. GC thread User thread --------- ----------- unix_vertex_dead(sk-A) -> true <------. \ `------ recv(sk-B, MSG_PEEK) invalidate !! -> sk-A's file refcount : 1 -> 2 close(sk-B) -> sk-B's file refcount : 2 -> 1 unix_vertex_dead(sk-B) -> true Initially, sk-A's file refcount is 1 by the inflight fd in sk-B recvq. GC thinks sk-A is dead because the file refcount is the same as the number of its inflight fds. However, sk-A's file refcount is bumped silently by MSG_PEEK, which invalidates the previous evaluation. At this moment, sk-B's file refcount is 2; one by the open fd, and one by the inflight fd in sk-A. The subsequent close() releases one refcount by the former. Finally, GC incorrectly concludes that both sk-A and sk-B are dead. One option is to restore the locking dance in unix_peek_fds(), but we can resolve this more elegantly thanks to the new algorithm. The point is that the issue does not occur without the subsequent close() and we actually do not need to synchronise MSG_PEEK with the dead SCC detection. When the issue occurs, close() and GC touch the same file refcount. If GC sees the refcount being decremented by close(), it can just give up garbage-collecting the SCC. Therefore, we only need to signal the race during MSG_PEEK with a proper memory barrier to make it visible to the GC. Let's use seqcount_t to notify GC when MSG_PEEK occurs and let it defer the SCC to the next run. This way no locking is needed on the MSG_PEEK side, and we can avoid imposing a penalty on every MSG_PEEK unnecessarily. Note that we can retry within unix_scc_dead() if MSG_PEEK is detected, but we do not do so to avoid hung task splat from abusive MSG_PEEK calls. | ||||