Export limit exceeded: 360533 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (360533 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-54513 | 1 Fasterxml | 1 Jackson-databind | 2026-06-24 | 8.1 High |
| jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.10.0 until 2.18.8, 2.21.4, and 3.1.4, BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() allowlists any array type based only on clazz.isArray(), without validating the array's component (element) type against the configured allowlist. A PTV built with allowIfSubTypeIsArray() plus an explicit concrete-type allowlist therefore still permits EvilType[] even though EvilType is not allowlisted. When Jackson deserializes the elements and no per-element type IDs are present, it instantiates the component type directly with no further PTV check, bypassing the allowlist. This vulnerability is fixed in 2.18.8, 2.21.4, and 3.1.4. | ||||
| CVE-2026-57282 | 2026-06-24 | 5 Medium | ||
| Jenkins Git client Plugin 6.6.0 and earlier does not correctly escape the workspace directory name when it is embedded into a generated SSH wrapper script, allowing attackers able to control the name of a build's working directory to execute arbitrary operating system commands on the agent. | ||||
| CVE-2026-57305 | 2026-06-24 | 5.4 Medium | ||
| A cross-site request forgery (CSRF) vulnerability in Jenkins Assembla Plugin 1.4 and earlier allows attackers to connect to an attacker-specified URL using an attacker-specified username and password. | ||||
| CVE-2026-57306 | 2026-06-24 | 4.2 Medium | ||
| A cross-site request forgery (CSRF) vulnerability in Jenkins Zowe zDevOps Plugin 1.1.3.50.ve350c9b_450b_1 and earlier allows attackers to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins. | ||||
| CVE-2026-46552 | 1 Nocodb | 1 Nocodb | 2026-06-24 | 5.8 Medium |
| NocoDB is software for building databases as spreadsheets. Prior to 2026.04.1, shared-base sessions were granted the same base-member capabilities as authenticated viewers. Using only the shared-base UUID (xc-shared-base-id), an attacker could enumerate base members and invite an arbitrary email into the base as a real member. The invited user could then redeem the invite via the normal signup flow and retain authenticated access even after the owner revoked the shared link. Shared-base sessions were mapped to ProjectRoles.VIEWER in packages/nocodb/src/strategies/base-view.strategy/base-view.strategy.ts, and packages/nocodb/src/utils/acl.ts granted baseUserList and userInvite to that role. The shared frontend (packages/nc-gui/composables/useApi/interceptors.ts) deliberately removed auth headers in favour of the shared-base header, but the ACL middleware did not distinguish shared sessions from genuine viewers. This vulnerability is fixed in 2026.04.1. | ||||
| CVE-2026-47377 | 1 Nocodb | 1 Nocodb | 2026-06-24 | N/A |
| NocoDB is software for building databases as spreadsheets. Prior to 2026.04.1, the client-side hashRedirect plugin called window.location.replace() on a path extracted from the URL hash fragment after only checking hashPath.startsWith('/'). Protocol-relative URLs (//attacker.com/…) also satisfy that check, so a crafted link silently redirected visitors to an attacker-controlled origin. This vulnerability is fixed in 2026.04.1. | ||||
| CVE-2026-47381 | 1 Nocodb | 1 Nocodb | 2026-06-24 | N/A |
| NocoDB is software for building databases as spreadsheets. Prior to 2026.05.1, a user in one workspace could exercise another workspace's integration through the testConnection endpoint by supplying its ID, because the integration was fetched in a bypass scope and the caller's permission check matched any base in any workspace. This vulnerability is fixed in 2026.05.1. | ||||
| CVE-2026-47388 | 1 Nocodb | 1 Nocodb | 2026-06-24 | N/A |
| NocoDB is software for building databases as spreadsheets. Prior to 2026.05.1, a low-privilege MCP token holder with knowledge of an attachment path could read any file in shared storage, including attachments belonging to other bases and workspaces, because the MCP readAttachment tool did not verify the file's ownership. This vulnerability is fixed in 2026.05.1. | ||||
| CVE-2026-53931 | 1 Nocodb | 1 Nocodb | 2026-06-24 | N/A |
| NocoDB is software for building databases as spreadsheets. Prior to 2026.05.1, the spreadsheet-import endpoint axiosRequestMake could be used as a generic HTTP proxy. Before the fix it was reachable unauthenticated, and its URL-extension allowlist was a regex tested against the full URL string, so URLs whose query string ended in .csv satisfies the gate even though the underlying request is for another file. This vulnerability is fixed in 2026.05.1. | ||||
| CVE-2026-48491 | 1 Traefik | 1 Traefik | 2026-06-24 | 9.1 Critical |
| Traefik is an HTTP reverse proxy and load balancer. From 3.7.0 until 3.7.3, there is a high severity vulnerability in Traefik's domain-fronting protection (SNICheck) that allows an unauthenticated client to bypass mutual TLS enforced through wildcard router TLSOptions. When a router uses a wildcard host rule such as Host(*.example.com) with stricter TLS options (for example RequireAndVerifyClientCert), SNICheck resolves the TLS options for the HTTP Host header using exact map lookups only and never applies wildcard matching. If another permissive SNI is served on the same entrypoint, an attacker can complete the TLS handshake under the permissive options and then send an HTTP Host header targeting the wildcard-protected backend, reaching it without presenting a client certificate. This affects the regular HTTPS / HTTP-2 path and does not require HTTP/3. This vulnerability is fixed in 3.7.3. | ||||
| CVE-2026-52845 | 1 Caddyserver | 1 Caddy | 2026-06-24 | 8.1 High |
| Caddy is an extensible server platform that uses TLS by default. Prior to 2.11.4, forward_auth copy_headers deletes the exact client-supplied identity header before copying the trusted value from the auth gateway. But when the request later goes through php_fastcgi, Caddy normalizes HTTP headers into CGI variables by replacing - with _. This lets a client send an underscore alias that survives the forward_auth delete step but becomes the same PHP/FastCGI variable. Result: a remote client can inject or sometimes override identity/group headers trusted by PHP/FastCGI applications behind Caddy. This vulnerability is fixed in 2.11.4. | ||||
| CVE-2026-54009 | 1 Open-webui | 1 Open-webui | 2026-06-24 | 6.5 Medium |
| Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.6, POST /api/chat/completions accepts an image_url.url value that, when it does NOT start with http://, https://, or data:image/, is interpreted as a file id and resolved against the global file table with no ownership check. an authenticated user can therefore set image_url.url to another user's file id, the server reads that file from disk, base64-encodes it, and injects the data URI into the LLM request. the user then prompts the LLM to describe / OCR the file and reads the content back. This vulnerability is fixed in 0.9.6. | ||||
| CVE-2026-54015 | 1 Open-webui | 1 Open-webui | 2026-06-24 | 6.4 Medium |
| Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.6, Open WebUI's prompt version-history endpoints authorize the prompt_id in the URL but then act on caller-supplied history IDs without verifying that the history row belongs to that prompt (history_entry.prompt_id == prompt.id). This affects /api/v1/prompts/id/{prompt_id}/history/diff, /api/v1/prompts/id/{prompt_id}/update/version, and /api/v1/prompts/id/{prompt_id}/history/{history_id}. An authenticated user with access to any prompt they control, plus a victim prompt_history.id, can read or delete another user's private prompt history. This vulnerability is fixed in 0.9.6. | ||||
| CVE-2026-52913 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called. | ||||
| CVE-2026-52914 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix fragment reassembly length accounting batman-adv keeps a running payload length for queued fragments and uses it to validate a fragment chain before reassembly. That accounting currently allows the accumulated fragment length to be truncated during updates. As a result, malformed fragment chains can bypass the intended validation and drive reassembly with inconsistent length state, leading to a local denial of service. Fix the accounting by storing the accumulated length in a length-typed field and rejecting update overflows before the existing validation logic runs. The fix was verified against the original reproducer and against valid fragment reassembly paths. | ||||
| CVE-2026-52921 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: stop hash:* range iteration at end The following hash set variants: hash:ip,mark hash:ip,port hash:ip,port,ip hash:ip,port,net iterate IPv4 ranges with a 32-bit iterator. The iterator must stop once the last address in the requested range has been processed. Advancing it once more can move the traversal state past the end of the request, so a later retry may continue from an unintended position. Handle the iterator increment explicitly at the end of the loop and stop once the upper bound has been processed. This keeps the existing retry behaviour intact for valid ranges while preventing traversal from continuing past the original boundary. | ||||
| CVE-2026-52923 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted. | ||||
| CVE-2026-52929 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions. | ||||
| CVE-2026-56114 | 1 Networkconfiguration | 1 Dhcpcd | 2026-06-24 | 5.3 Medium |
| dhcpcd through 10.3.2, fixed in commit 2f00c7b, contains a one-byte stack out-of-bounds write vulnerability in dhcp6_makemessage() in src/dhcp6.c that allows unauthenticated same-link attackers to write beyond a fixed local buffer by serializing an oversized RFC6603 OPTION_PD_EXCLUDE option body. Attackers can send a crafted DHCPv6 ADVERTISE message containing an IA_PD IAPREFIX /0 with a valid OPTION_PD_EXCLUDE using an exclude prefix length of /121 through /128 to trigger the out-of-bounds write and potentially corrupt adjacent stack memory. | ||||
| CVE-2026-24858 | 2 Fortinet, Siemens | 8 Fortianalyzer, Fortimanager, Fortinac-f and 5 more | 2026-06-24 | 9.4 Critical |
| An Authentication Bypass Using an Alternate Path or Channel vulnerability [CWE-288] vulnerability in Fortinet FortiAnalyzer 7.6.0 through 7.6.5, FortiAnalyzer 7.4.0 through 7.4.9, FortiAnalyzer 7.2.0 through 7.2.11, FortiAnalyzer 7.0.0 through 7.0.15, FortiManager 7.6.0 through 7.6.5, FortiManager 7.4.0 through 7.4.9, FortiManager 7.2.0 through 7.2.11, FortiManager 7.0.0 through 7.0.15, FortiNAC-F 7.6.3 through 7.6.5, FortiOS 7.6.0 through 7.6.5, FortiOS 7.4.0 through 7.4.10, FortiOS 7.2.0 through 7.2.12, FortiOS 7.0.0 through 7.0.18, FortiProxy 7.6.0 through 7.6.4, FortiProxy 7.4.0 through 7.4.12, FortiProxy 7.2.0 through 7.2.15, FortiProxy 7.0.0 through 7.0.22, FortiWeb 8.0.0 through 8.0.3, FortiWeb 7.6.0 through 7.6.6, FortiWeb 7.4.0 through 7.4.11 may allow an attacker with a FortiCloud account and a registered device to log into other devices registered to other accounts, if FortiCloud SSO authentication is enabled on those devices. | ||||