Export limit exceeded: 403579 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (403579 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-18179 | 2 Ibm, Redhat | 3 Financial Transaction Manager, Financial Transaction Manager Ftmfor Redhat Openshift, Openshift | 2026-10-07 | 6.5 Medium |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to clear active chat sessions due to improper authorization. | ||||
| CVE-2026-18180 | 2 Ibm, Redhat | 3 Financial Transaction Manager, Financial Transaction Manager Ftmfor Redhat Openshift, Openshift | 2026-10-07 | 6.5 Medium |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote authenticated attacker to obtain sensitive information due to SQL injection. | ||||
| CVE-2026-49885 | 1 Google | 1 Android | 2026-10-07 | 7.8 High |
| In rw_t4t_update_file of rw_t4t.cc, there is a possible out-of-bounds write due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-18181 | 2 Ibm, Redhat | 3 Financial Transaction Manager, Financial Transaction Manager Ftmfor Redhat Openshift, Openshift | 2026-10-07 | 8.1 High |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to bypass authentication and access sensitive information due to a hard-coded cryptographic key. | ||||
| CVE-2026-18184 | 2 Ibm, Redhat | 3 Financial Transaction Manager, Financial Transaction Manager Ftmfor Redhat Openshift, Openshift | 2026-10-07 | 7.4 High |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to obtain sensitive information due to an XML external entity (XXE) injection flaw. | ||||
| CVE-2026-18185 | 2 Ibm, Redhat | 3 Financial Transaction Manager, Financial Transaction Manager Ftmfor Redhat Openshift, Openshift | 2026-10-07 | 7.3 High |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to access sensitive information and modify system configurations due to missing authentication for a critical function. | ||||
| CVE-2026-18490 | 2 Ibm, Redhat | 4 Financial Transaction Manager, Financial Transaction Manager (ftm) for Redhat Openshift, Financial Transaction Manager Ftmfor Redhat Openshift and 1 more | 2026-10-07 | 8.8 High |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift is vulnerable to unauthenticated remote code execution via Java native deserialization on the PayDir Business Rules Manager RMI SSL endpoint (BrmRMISSLServerSocketFactory.java:95, EP8). An adjacent-network attacker can deliver a crafted serialized payload to achieve arbitrary code execution, exposing all PayDir credentials and enabling manipulation of payment business rules. | ||||
| CVE-2026-18505 | 2 Ibm, Redhat | 3 Financial Transaction Manager, Financial Transaction Manager Ftmfor Redhat Openshift, Openshift | 2026-10-07 | 5.4 Medium |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift is vulnerable to open redirect in the PMP `HostHeaderFilter` (`HostHeaderFilter.java:151`). An unauthenticated attacker can craft a request with a manipulated `Host` header to redirect authenticated operators to attacker-controlled sites, enabling credential phishing. | ||||
| CVE-2026-18872 | 2 Ibm, Redhat | 3 Financial Transaction Manager, Financial Transaction Manager Ftmfor Redhat Openshift, Openshift | 2026-10-07 | 9.3 Critical |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift is vulnerable to stored cross-site scripting (CWE-79) in the FTM UI NetworkAcknowledgement React component (NetworkAcknowledgement.jsx:42). A malicious actor can inject script into stored network acknowledgement data that executes in authenticated operator browsers, enabling session hijacking and unauthorized operator-level payment actions. | ||||
| CVE-2026-18875 | 2 Ibm, Redhat | 3 Financial Transaction Manager, Financial Transaction Manager Ftmfor Redhat Openshift, Openshift | 2026-10-07 | 7.3 High |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift is vulnerable to RAG poisoning via unauthenticated runbook upsert (CWE-74) in the FTM AI agent server (api.vectordb.runbooks.js:51). An unauthenticated attacker can insert malicious runbook content into the agent's vector database to steer AI-driven MCP tool calls, potentially triggering unauthorized payment actions or exfiltrating payment data. | ||||
| CVE-2026-19087 | 2 Ibm, Redhat | 3 Financial Transaction Manager, Financial Transaction Manager Ftmfor Redhat Openshift, Openshift | 2026-10-07 | 4.4 Medium |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a local attacker to achieve privilege escalation within the container due to improper privilege management. | ||||
| CVE-2026-19179 | 2 Ibm, Redhat | 3 Financial Transaction Manager, Financial Transaction Manager Ftmfor Redhat Openshift, Openshift | 2026-10-07 | 8.2 High |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to manipulate database queries due to improper neutralization of special elements in a boolean expression. | ||||
| CVE-2026-19267 | 2 Ibm, Redhat | 3 Financial Transaction Manager, Financial Transaction Manager Ftmfor Redhat Openshift, Openshift | 2026-10-07 | 6.2 Medium |
| IBM Financial Transaction Manager (FTM) for RedHat OpenShift is vulnerable to missing authentication on the Business Rules Manager commands REST endpoint (`CommandsResource.java:31`). A local actor can invoke unauthenticated commands to cause resource exhaustionand halt business-rule management functions. | ||||
| CVE-2026-98254 | 1 Linux | 1 Linux Kernel | 2026-10-07 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: swiotlb: use the adjusted address for the highmem page lookup swiotlb_bounce() reads the page frame number from the slot's recorded orig_addr, then advances orig_addr by tlb_offset to reach the address the caller asked about. The highmem branch mixes the two: the offset within the page comes from the adjusted address, the page from the value before it. Once the adjustment crosses a page boundary the pair no longer describes one location, and the whole copy lands one page below the intended one for a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE writes the device data over the wrong page and leaves the intended one stale, DMA_TO_DEVICE feeds the device from a page the mapping may not cover. Partial syncs through dma_sync_single_range_for_*() are what make tlb_offset non-zero. The branch test is picked the same way, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path then hands a highmem address to phys_to_virt(). Take both from orig_addr once it is final and keep pfn in the branch that uses it. PhysHighMem() asks the question straight from the address, as dma-debug already does. | ||||
| CVE-2026-98369 | 1 Linux | 1 Linux Kernel | 2026-10-07 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: xfrm: add missing rcu_read_lock(), skb_dst_force() and dev_hold() for xfrm_trans_reinject() syzbot reported a suspicious RCU usage warning in ip6_pkt_drop(): WARNING: suspicious RCU usage in ip6_pkt_drop include/net/addrconf.h:389 suspicious rcu_dereference_check() usage! Call Trace: __in6_dev_get_safely include/net/addrconf.h:389 [inline] ip6_pkt_drop+0x596/0x610 net/ipv6/route.c:4620 ip6_pkt_discard+0x1c/0x30 net/ipv6/route.c:4651 xfrm_trans_reinject+0x324/0x630 net/xfrm/xfrm_input.c:806 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0xa47/0xfb0 kernel/workqueue.c:3486 When commit 4f4920669d21 ("xfrm: Reinject transport-mode packets through workqueue") converted xfrm_trans_reinject from a tasklet to a workqueue, the reinjection loop ceased running in softirq context. Workqueue workers run in process context where local_bh_disable() does not enter an RCU read-side critical section under CONFIG_PREEMPT_RCU. Because finish callbacks (such as ip6_rcv_finish) expect to run under an RCU read lock (performing route lookups, l3mdev lookups, and accessing RCU-protected data structures), invoking them in workqueue context without rcu_read_lock() triggers RCU lockdep warnings. Furthermore, packets queued to the workqueue via xfrm_trans_queue_net() may carry non-refcounted (noref) dst entries (e.g. from ip_route_input_noref). Additionally, on netdevice unregistration, dst_dev_put() replaces dst->dev with blackhole_netdev, so dst entries do not keep skb->dev alive while queued in the workqueue. Fix these issues by: 1. Calling skb_dst_force(skb) in xfrm_trans_queue_net() while still in the caller's RCU section to ensure dst is reference-counted before queuing. 2. Holding a reference on skb->dev via dev_hold()/dev_put() across workqueue deferral so skb->dev remains valid during finish() callback processing. 3. Acquiring rcu_read_lock() around the finish callback invocation loop in xfrm_trans_reinject(). | ||||
| CVE-2026-106354 | 1 Google | 1 Chrome | 2026-10-07 | 4.3 Medium |
| Improper resource exposure in Extensions in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-96400 | 1 Gitea | 1 Gitea | 2026-10-07 | 4.3 Medium |
| With `[migrations] ALLOWED_DOMAINS` set to a matching entry such as `*` or a hostname wildcard, Gitea's migration URL validation could permit reserved and link-local addresses, such as `169.254.169.254`, even when `ALLOW_LOCALNETWORKS = false`. The local-network block list did not cover these ranges, and a hostname matching the allow list was accepted regardless of its resolved address. A user who can start migrations on such an instance could reach these addresses from the Gitea server; the default empty `ALLOWED_DOMAINS` configuration is not affected. | ||||
| CVE-2026-93026 | 1 Veeam | 1 Backup And Replication | 2026-10-07 | N/A |
| This vulnerability in Veeam Backup & Replication allows a Backup Viewer to modify the Enterprise Manager master key and stored antivirus update credentials. | ||||
| CVE-2026-89182 | 1 Gitea | 1 Gitea | 2026-10-07 | 5.4 Medium |
| With `[repository] FORCE_PRIVATE = true`, Gitea creates new repositories as private, but the post-receive hook still applied the `repo.private=false` push option to an empty repository created by push. Any user who can create repositories could make their new repository public in violation of the instance policy. The default configuration is not affected. | ||||
| CVE-2026-83742 | 1 Wolfssl | 1 Wolfssh | 2026-10-07 | N/A |
| Unsigned integer underflow in wstrncat() in src/port.c in wolfSSL wolfSSH from v1.4.11 through v1.5.0 on non-Windows platforms allows an authenticated remote attacker to write one out-of-bounds null byte past the end of a stack buffer by sending a crafted SFTP path. wolfSSH_RealPath() in src/ssh.c appends each path component with a remaining-size bound (outSz - curSz) rather than the full destination size, so once the accumulated path reaches half the output buffer the size_t computation n - strlen(s1) - 1 wraps to near SIZE_MAX. The strncat() call is then effectively unbounded and copies the whole component; when that component exactly fills the remainder of the buffer, its terminating null is written one byte past the end. The caller's own length check keeps the copied data inside the buffer, so the overflow is limited to that single null byte, which may corrupt an adjacent stack value and crash the process. Applications that call the public wolfSSH_RealPath() with an output buffer smaller than the input path are additionally exposed to an unbounded copy, because the word32 expression outSz - segSz in that length check also wraps. | ||||