Export limit exceeded: 16700 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (16700 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-46408 | 1 Givanz | 1 Vvveb | 2026-10-26 | 7.6 High |
| Vvveb is a powerful and easy to use CMS with page builder to build websites, blogs or ecommerce stores. Prior to 1.0.8.3, the checkout endpoint accepts a user-controlled cart_id and uses it to enter the payment flow without verifying cart ownership. A logged-in attacker can therefore reuse another user's cart data in their own checkout session. This vulnerability is fixed in 1.0.8.3. | ||||
| CVE-2026-46806 | 1 Oracle | 1 Webcenter Content | 2026-10-25 | 8.2 High |
| Vulnerability in the Oracle WebCenter Content product of Oracle Fusion Middleware (component: Content Server). The supported version that is affected is 14.1.2.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle WebCenter Content. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle WebCenter Content, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle WebCenter Content accessible data as well as unauthorized update, insert or delete access to some of Oracle WebCenter Content accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N). | ||||
| CVE-2026-25253 | 1 Openclaw | 1 Openclaw | 2026-10-25 | 8.8 High |
| OpenClaw (aka clawdbot or Moltbot) before 2026.1.29 obtains a gatewayUrl value from a query string and automatically makes a WebSocket connection without prompting, sending a token value. | ||||
| CVE-2026-109194 | 2 Red Hat, Redhat | 3 Red Hat Quay 3, Quay, Red Hat Quay 3 | 2026-10-25 | 6.4 Medium |
| A flaw was found in Red Hat Quay. The build trigger management application programming interface (API) fails to verify whether a requested trigger belongs to the specified repository. An authenticated user with administrative access to any repository can view, modify, or permanently delete build triggers and associated write tokens of another repository if they know the victim trigger's universally unique identifier (UUID). | ||||
| CVE-2026-53904 | 1 Mycomplianceoffice | 1 Mco | 2026-10-25 | 7.1 High |
| MCO is vulnerable to Account Denial of Service due to improper implementation of password reset functionality. Each password reset request invalidates previously set password as well as previously issued temporary passwords, furthermore, password resets are not limited in any way. An attacker who provides victim's email and answer to their security question, can successfully initiate the reset process and continuously invalidate credentials, effectively locking the victim out of their account. Answering security questions has a limited number of tries which lowers the risk of this vulnerability. Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions. | ||||
| CVE-2026-53903 | 1 Mycomplianceoffice | 2 Mco, Mycomplianceoffice | 2026-10-25 | 8.1 High |
| MCO is vulnerable to an Insecure Direct Object Reference (IDOR) vulnerability in the /customer/servlet/mco/webapi/trading-document/fetchPdfStatement endpoint. The application does not properly validate whether an authenticated user is authorized to access a requested document, allowing direct retrieval based on a user-supplied identifier. An attacker can access trading documents belonging to other users by providing a valid document ID. Although exploitation requires guessing the identifier, predictable ID patterns enable feasible enumeration, leading to unauthorized disclosure of sensitive information. Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 25.3.3.1 but may also affect other versions. | ||||
| CVE-2026-56308 | 1 Cap-go | 1 Cap-go | 2026-10-25 | 7.3 High |
| Capgo before 12.128.2 allows email address changes without requiring current password re-authentication or verification of the existing email address. An attacker with access to a valid session cookie or authenticated browser can change the account email to gain control of account recovery and bypass multi-factor authentication protections. | ||||
| CVE-2026-44383 | 1 Hydro-québec | 1 Le Circuit Electrique Charging Station Backend | 2026-10-25 | 7.5 High |
| Multiple connections to the backend using the same charging station ID are allowed, which could allow an attacker to deploy multiple instances of malicious OCPP clients to overwhelm the backend. | ||||
| CVE-2026-83872 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-25 | 7.8 High |
| Incorrect conversion between numeric types in Windows TCP/IP allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-52841 | 1 Alextselegidis | 1 Easyappointments | 2026-10-24 | 3.1 Low |
| Easy!Appointments is a self hosted appointment scheduler. In versions prior to 1.6.0, `Google::oauth` at `application/controllers/Google.php:278` stores its URL-supplied `provider_id` in the session, and `oauth_callback` saves the issued Google OAuth token against that row without checking the caller owns the provider. Any logged-in backend user (admin, provider, or secretary) rebinds a peer provider's Google sync to a Google account they control. The peer's appointments then sync into the attacker's calendar with each customer's name and email attached as attendee data. Version 1.6.0 patches the issue. | ||||
| CVE-2026-46485 | 1 Lissy93 | 1 Dashy | 2026-10-24 | 8.2 High |
| Dashy is a self-hostable personal dashboard. Prior to 4.0.8, Dashy deployments using OIDC can allow unauthenticated users or non-admin authenticated users to write changes to the main config.yaml through the config-saving functionality despite configured permissions, allowing unauthorized modification of dashboard configuration and potential service disruption. This issue is fixed in version 4.0.8. | ||||
| CVE-2026-21762 | 1 Hcltech | 1 Devops Loop | 2026-10-24 | 3.7 Low |
| HCL DevOps Loop is affected by missing HTTP security headers. Missing security headers may reduce browser protections against common web-based attacks such as clickjacking, MIME-type sniffing, and cross-site scripting. | ||||
| CVE-2026-98965 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-24 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: ice: Restore Ordered MMIO Writes for Tx Doorbells The DQL accounting state which tracks the number of bytes queued for the NIC to transmit, namely dql->num_queued, is updated by the ICE driver when it invokes __netdev_tx_sent_queue(). Subsequently the driver updates the hardware queue tail allowing the NIC to begin processing the work queue. The queue accounting update should be ordered before the NIC begins transmitting descriptors. The transmit path currently updates the hardware doorbell using writel_relaxed(), which (on arm64) does not provide the same ordering guarantees between writes to normal memory and writes to MMIO registers that writel() does. This introduces a potential race where the NIC begins transmitting descriptors before the dql->num_queued update is globally visible. If the NIC finishes before the update is observed by dql_completed(), it detects an invalid state where more bytes have been completed than have been queued. When this happens the following BUG_ON is triggered. BUG_ON(count > num_queued - dql->num_completed); This has been observed and manifests as the following crash (note that the trace has been trimmed) in an environment with sustained network load that uses an Intel Corporation Ethernet Controller E810-XXV for SFP (rev 02) on an arm64 machine. Replacing writel_relaxed() with writel() in a test kernel eliminated the crash in the user's workload, which previously reproduced the issue reliably. kernel BUG at lib/dynamic_queue_limits.c:99 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x268/0x2a0 lr : ice_clean_tx_irq+0x1d4/0x620 [ice] Call trace: dql_completed+0x268/0x2a0 (P) ice_napi_poll+0x94/0x520 [ice] __napi_poll+0x48/0x3f0 net_rx_action+0x194/0x420 This restores the behaviour prior to commit ccde82e90946 ("ice: add E830 Earliest TxTime First Offload support"), which changed the notification mechanism from writel() to writel_relaxed(). | ||||
| CVE-2026-98975 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-24 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: xfs: stop exchanging reflink flags when exchanging mappings When an exchange covers both files from offset 0 to i_disk_size, xmi_can_exchange_reflink_flags() assumes every mapping moved and hands the reflink flag over to the other file. That assumption is wrong. A file can still own shared blocks past i_disk_size, e.g. after EXCHANGE_RANGE_TO_EOF sets a smaller size without unmapping anything. The flag is cleared anyway, and the next write to such a block happens in place instead of CoW, corrupting the other file that shares it. Commit a23eca88448e ("xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN") fixed one instance of this. Rather than add another special case, stop moving the flags. xfs_exchmaps_ensure_reflink() already sets the flag on both inodes before the exchange, so both just keep it. Nothing sets CLEAR_INO{1,2}_REFLINK anymore. Intents logged by older kernels may still carry them; recovery already masks them off, so they stay in the log format mask and are ignored. XFS_IOC_SWAPEXT has the same problem: it moves the reflink flag from one inode to the other along with the extents. Just removing that is not enough here: the exchange path flags both inodes up front in xfs_exchmaps_ensure_reflink(), but swapext has no such step, so the inode receiving the shared extents would be left without the flag. Set it on both inodes instead, and make sure both have a CoW fork, since an inode with the reflink flag is expected to have one. The flag now stays until FALLOC_FL_UNSHARE_RANGE, xfs_scrub, or a truncate to zero removes it. | ||||
| CVE-2026-98959 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-24 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix xattr replace when multiple xattrs are packed in the same item If we have a btrfs_dir_item item that packs multiple xattrs and then we replace the value of one of them (with the setxattr(2) family of syscalls) with another value of a different size, we end up not having a fully initialized btrfs_dir_item, resulting in a corruption that the tree checker will detect at extent buffer writeback time. This is because in btrfs_setxattr() when we find a btrfs_dir_item with multiple xattrs (due to the crc32c hash of their name being the same) we delete one of the xattr items (btrfs_dir_item) and then insert a new one, but the deletion and insertion results in shifting existing data in the leaf and therefore when the new value of a xattr has a different size, the new btrfs_dir_item is placed in a leaf section that was not initialized and we only copy the value's data and set the value's length in the new btrfs_dir_item, without setting the name, the name's length, the key (which must be all zeroes for xattrs), flags (BTRFS_FT_XATTR) and transaction ID. The following script reproduces the issue: $ cat test.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi mkfs.btrfs -f $DEV mount $DEV $MNT touch $MNT/testfile # Add two xattrs that, on btrfs, have the same hash (crc32c) for their # name and therefore are packed into the same btrfs_dir_item. setfattr -n user.foobar -v 123 $MNT/testfile setfattr -n user.WvG1c1Td -v qwerty $MNT/testfile # Verify the xattrs are present. echo "xattrs before:" getfattr --absolute-names --dump $MNT/testfile # Now replace the value of the foobar xattr with a significantly larger # value. setfattr -n user.foobar -v abcdefghijklmnopqrstuvwxyz $MNT/testfile # Check the xattrs have the expected values. echo "xattrs after:" getfattr --absolute-names --dump $MNT/testfile umount $MNT Running it: $ ./test.sh (...) xattrs before: # file: /mnt/sdi/testfile user.WvG1c1Td="qwerty" user.foobar="123" xattrs after: # file: /mnt/sdi/testfile user.WvG1c1Td="qwerty" So the "user.foobar" xattr is missing and there was a transaction abort when unmounting the fs with the following traces in dmesg: $ dmesg [869800.159271] BTRFS warning (device sdi): access to eb bytenr 30474240 len 16384 out of range start 16015 len 25964 [869800.159293] ------------[ cut here ]------------ [869800.159296] WARNING: fs/btrfs/extent_io.c:4408 at report_eb_range+0x44/0x60 [btrfs], CPU#8: getfattr/2605179 [869800.168961] Modules linked in: btrfs dm_thin_pool (...) [869800.190527] CPU: 8 UID: 0 PID: 2605179 Comm: getfattr Tainted: G W 7.3.0-rc3-btrfs-next-244+ #1 PREEMPT(full) [869800.193726] Tainted: [W]=WARN [869800.194502] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [869800.197576] RIP: 0010:report_eb_range+0x44/0x60 [btrfs] [869800.198985] Code: 48 8b 7b 18 (...) [869800.203531] RSP: 0018:ffffce4541937d58 EFLAGS: 00010246 [869800.204609] RAX: 0000000000000000 RBX: ffff8dde054b8738 RCX: 0000000000000000 [869800.206137] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffc04c92a0 [869800.207645] RBP: 0000000000003e8f R08: 0000000000000000 R09: 3fffffffffefffff [869800.226175] R10: ffffce4541937a88 R11: 0000000000000003 R12: 000000000000656c [869800.227594] R13: ffff8dde14be800f R14: 000000000000656c R15: 0000000000000069 [869800.229097] FS: 00007f59023bb780(0000) GS:ffff8de5788ed000(0000) knlGS:0000000000000000 [869800.231137] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [869800.232321] CR2: 0000558dc45e6a78 CR3: 0000000765b16004 CR4: 0000000000370ef0 [869800.233783] Call Trace: [869800.234330] <TASK> [869800.234791] read_extent_buffer+0x4d/0x100 [btrfs] [869800.235898] btrfs_listxattr+0x199/0x240 [btrfs] [869800.236912] vfs_listxattr+0x51/0 ---truncated--- | ||||
| CVE-2026-113489 | 2026-10-24 | 4.3 Medium | ||
| The GeoDirectory WordPress plugin before 2.8.194 does not verify that a referenced attachment belongs to the listing being saved, allowing users with Subscriber-level access and above to modify the title, caption, moderation status and featured flag of images belonging to other users' listings, and to claim another user's image as their own featured image. | ||||
| CVE-2026-67179 | 1 Genkit-ai | 1 Genkit | 2026-10-24 | 7.8 High |
| Genkit does not properly validate host request headers. Any host on the developer's network, and any website the developer visits (via DNS rebinding), can reach POST /api/runAction on the Dev UI server (default port 4000) and execute any registered Genkit action and read the result. Fixed on 2026-06-18. | ||||
| CVE-2026-66274 | 1 Apache | 1 Qpid Proton-j | 2026-10-24 | 7.5 High |
| A pre-authentication attacker could leverage type nesting to cause a StackOverflowError potentially leading to denial of service. This issue affects Apache Qpid Proton-J: through 0.34.1. Users are recommended to upgrade to version 0.35.0, which fixes the issue. | ||||
| CVE-2026-67590 | 1 Apache | 2 Qpid Proton-j, Qpid Protonj2 | 2026-10-24 | 7.5 High |
| A pre-authentication attacker could leverage type nesting to cause a StackOverflowError potentially leading to denial of service. This issue affects Apache Qpid ProtonJ2: through 1.1.0. Users are recommended to upgrade to version 1.2.0, which fixes the issue. | ||||
| CVE-2026-67552 | 1 Apache | 2 Qpid Proton-dotnet, Qpid Proton Dotnet | 2026-10-24 | 7.5 High |
| A pre-authentication attacker could leverage type nesting to cause a StackOverflowError potentially leading to denial of service. This issue affects Apache Qpid Proton-Dotnet through 1.0.0. Users are recommended to upgrade to version 1.1.0, which fixes the issue | ||||