Export limit exceeded: 394936 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (394936 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-73639 | 2026-09-18 | N/A | ||
| Imager::File::PNG versions from 1.003 before 1.004 for Perl write past the end of the row buffer reading a PNG with a tRNS transparency chunk in read_direct8. With a tRNS chunk, read_direct8() adds an alpha channel to the image it creates but still sizes the row buffer from the original channel count. libpng expands the transparency into that extra channel, so png_read_row() fills one channel more than the buffer holds, at one byte per sample, and writes width bytes past the end of the allocation. Palette images go to read_paletted() and 16-bit images to read_direct16(), which sizes its buffer from png_get_rowbytes() and allocates enough for the expanded row. The same reader ships bundled in the Imager distribution. Reading an attacker-supplied PNG through Imager->read() corrupts the heap, which can crash the process. | ||||
| CVE-2026-73638 | 2026-09-18 | N/A | ||
| Imager versions from 0.45_02 before 1.035 for Perl read outside the EXIF block via unchecked start offsets in tiff_load_ifd. tiff_load_ifd() validates an IFD entry's data by checking that `entry->offset + entry->size` stays within the EXIF block, and never checks the start offset itself. Where that sum is not the real end of the data, the check passes with the entry starting outside the block. Through 1.032 `entry->offset` is a plain int, so on the usual two's-complement implementations an offset with the high bit set converts to negative and the sum can land back inside the block. From 1.033 the field is a size_t and the addition wraps only where size_t is 32 bits. The IFD's own start offset is checked the same way and wraps where unsigned long is 32 bits, which includes 64-bit Windows. Any caller of Imager->read() on an attacker-supplied image may receive EXIF tags holding bytes from outside the block, or crash the process. | ||||
| CVE-2026-20307 | 2026-09-18 | 9.9 Critical | ||
| A vulnerability in the web-based management interface of Cisco ISE could allow an authenticated, remote attacker to execute arbitrary commands on the underlying operating system of an affected device. To exploit this vulnerability, the attacker must have at least low-privileged administrative credentials. This vulnerability is due to insecure deserialization of a user-supplied Java byte stream. An attacker could exploit this vulnerability by sending a crafted serialized Java object to the web-based management interface of an affected device. A successful exploit could allow the attacker to execute arbitrary code on the device and elevate privileges to root. In single-node deployments, successful exploitation of this vulnerability could cause the affected ISE node to become unavailable, resulting in a denial of service (DoS) condition. In that condition, endpoints that have not already authenticated would be unable to access the network until the node is restored. | ||||
| CVE-2026-81870 | 1 Opentelemetry | 1 Opentelemetry-go | 2026-09-18 | N/A |
| OpenTelemetry-Go is the Go implementation of OpenTelemetry. From version 1.5.0 to 1.44.0, sdk/trace.NewTracerProvider emits a TracerProvider created internal Info-level diagnostic event whose MarshalLog implementations recursively include span processor, exporter, and client configuration. Applications that call otel.SetLogger to enable OpenTelemetry internal Info logging can therefore record OTLP gRPC and HTTP collector endpoints, the OTLP HTTP Insecure flag, and complete Zipkin collector URLs. A person or system with access to those logs can learn internal collector topology and can recover credentials or tokens embedded in Zipkin URL user information or query strings. The default OpenTelemetry logger does not emit the event, and this path does not log OTLP authentication headers, TLS key material, or span payloads. This issue is fixed in version 1.45.0. | ||||
| CVE-2026-81871 | 1 Opentelemetry | 1 Opentelemetry-go | 2026-09-18 | N/A |
| OpenTelemetry-Go is the Go implementation of OpenTelemetry. Prior to version 0.21.0, the exporters/otlp/otlplog/otlploggrpc package loads OTEL_EXPORTER_OTLP_LOGS_CERTIFICATE, OTEL_EXPORTER_OTLP_CERTIFICATE, and related client certificate environment variables through loadEnvTLS into cfg.tlsCfg, but newGRPCDialOptions does not apply cfg.tlsCfg when creating gRPC transport credentials. The environment-only TLS path instead uses credentials.NewTLS with system roots and no configured client certificate, bypassing intended private CA pinning and mutual TLS unless the application also supplies WithTLSCredentials. A network attacker able to intercept or spoof the collector connection with a system-trusted certificate can read or alter log telemetry. This issue is fixed in version 0.21.0. | ||||
| CVE-2026-93313 | 1 Freedesktop | 1 Poppler | 2026-09-18 | 6.3 Medium |
| A vulnerability was found in Freedesktop Poppler 26.07.0. The impacted element is the function JBIG2Stream::readCodeTableSeg of the file poppler/JBIG2Stream.cc. Performing a manipulation results in integer overflow. The attack can be initiated remotely. The exploit has been made public and could be used. The patch is named eb87cf711563894649bd0c365baa479401dc6d51. To fix this issue, it is recommended to deploy a patch. | ||||
| CVE-2026-20211 | 2026-09-18 | 9.1 Critical | ||
| A vulnerability in Cisco ISE could allow an authenticated, remote attacker to execute arbitrary commands on the underlying operating system of an affected device. To exploit this vulnerability, the attacker must have valid high-privileged administrative credentials. This vulnerability is due to insecure deserialization of Java objects by the affected software. An attacker could exploit this vulnerability by sending a crafted serialized Java object to an affected device. A successful exploit could allow the attacker to obtain user-level access to the underlying operating system and then elevate privileges to root. In single-node deployments, successful exploitation of this vulnerability could cause the affected ISE node to become unavailable, resulting in a DoS condition. In that condition, endpoints that have not already authenticated would be unable to access the network until the node is restored. | ||||
| CVE-2026-76423 | 2026-09-18 | 10 Critical | ||
| A vulnerability in the REST API of Cisco ISE and Cisco ISE-PIC could allow an unauthenticated, remote attacker to gain administrative access to an affected device. This vulnerability is due to the REST API web service being exposed with insufficient authorization checks. An attacker could exploit this vulnerability by sending a crafted HTTP request to the exposed REST API port. A successful exploit could allow the attacker to read and modify ISE configuration and identity data with administrative privileges. | ||||
| CVE-2026-76424 | 2026-09-18 | 7.2 High | ||
| A vulnerability in the REST API of Cisco ISE could allow an authenticated, remote attacker to upload or copy arbitrary files on an affected device. This vulnerability is due to insufficient validation in file operations. An attacker could exploit this vulnerability by uploading a file with a crafted path. A successful exploit could allow the attacker to upload files to arbitrary locations and execute arbitrary commands as root on the affected device. To exploit this vulnerability, the attacker must have valid administrative credentials. | ||||
| CVE-2026-20283 | 2026-09-18 | 6.5 Medium | ||
| A vulnerability in the IPsec Open API endpoint of Cisco ISE could allow an authenticated, remote attacker to inject arbitrary commands on the underlying operating system. This vulnerability is due to insufficient validation of user-supplied input in IPsec Open API calls. An attacker could exploit this vulnerability by sending crafted input to the IPsec Open API endpoint on an affected device. A successful exploit could allow the attacker to execute arbitrary commands on the underlying operating system. To exploit this vulnerability, the attacker must have valid administrative credentials and the node must have more than one network interface, one of which must be configured as an active IPsec tunnel. Note: For CVE-2026-20283, Cisco has assigned a Security Impact Rating (SIR) of High rather than Medium as the score indicates. The reason is that it is easy to get to root from the achieved privilege level. | ||||
| CVE-2026-20287 | 2026-09-18 | 6.5 Medium | ||
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco Identity Services Engine (ISE) and Cisco ISE Passive Identity Connector (ISE-PIC) engineering teams have conducted a comprehensive internal security review. This review resulted in a software hardening release that addresses multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-20287 are related to improper privilege managment issues that are grouped under the Common Weakness Enumeration (CWE) Pillar CWE-269. | ||||
| CVE-2026-92763 | 1 Rundeck | 1 Rundeck | 2026-09-18 | 8.1 High |
| Rundeck through 6.2.1 fails to properly authorize the importConfig and importNodesSources parameters in the project archive import endpoint. Attackers with only the import action can replace project configuration files including security-relevant settings like node executors and SSH key paths that affect job execution. | ||||
| CVE-2026-61588 | 1 Djust-org | 1 Djust | 2026-09-18 | 6.5 Medium |
| djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, when a Django `Model` instance is assigned to a public view attribute, djust serialized it to the client with no sensitive-field denylist — sending fields such as `password` (the hash), privilege flags (e.g. `is_staff` / `is_superuser`), tokens, and other PII to the browser. Because exposing model objects to templates is a normal djust pattern, this could leak credentials/PII without the developer realizing the full object crossed the wire. This is fixed in djust 1.0.7. Model serialization applies a secure-by-default sensitive-field denylist (password/hash/token/secret-style fields and known privilege flags are withheld) with an identity-subset fallback. As a workaround, keep `Model` instances on `_private` attributes and expose only the specific fields needed, until patched. | ||||
| CVE-2026-61589 | 1 Djust-org | 1 Djust | 2026-09-18 | 6.3 Medium |
| djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, the WebSocket `handle_mount` and `ViewRuntime._build_request` rebuild an `HttpRequest` via `RequestFactory().get(...)` with no `HTTP_HOST`, so `request.get_host()` defaulted to `"testserver"` on the live path. Host/subdomain/domain `TenantResolver`s then misresolved the tenant — `None` on the live path while the HTTP path resolved correctly. With `STRICT_MODE=False` the tenant-scoped managers returned unscoped rows (cross-tenant disclosure); with the default they returned an empty queryset (broken tenancy). This is fixed in djust 1.0.7. The handshake Host is extracted from the ASGI scope, validated against `ALLOWED_HOSTS` (the same logic as the CSWSH Origin gate, parsed with Django's `split_domain_port` so malformed Hosts are rejected at the boundary), and propagated — with the TLS scheme — into the reconstructed request, so live-path tenant resolution matches HTTP exactly. There is no known workaround on the live path short of upgrading. Users are most exposed when combined with `STRICT_MODE=False`. | ||||
| CVE-2026-92839 | 1 Canva | 1 Canva | 2026-09-18 | 4.3 Medium |
| Canva Desktop before v1.125.0 performed double decoding in the deeplink handler. A threat actor could cause the application to load arbitrary same-origin content under the user’s session. | ||||
| CVE-2026-61592 | 1 Djust-org | 1 Djust | 2026-09-18 | 7.4 High |
| djust provides Phoenix LiveView-style reactive server-side rendering for Django with Rust-powered performance. Prior to version 1.0.7, SSE sessions were keyed solely by a client-chosen `session_id` with no binding to the authenticated user — a control the WebSocket transport has but that was dropped on SSE. An attacker who learns (or a victim who leaks) a `session_id` could connect to the message endpoint and dispatch event handlers that execute with the victim's identity and state. This is fixed in djust 1.0.7. Each SSE session is bound to its owning principal at creation and cross-principal access is rejected; SSE session creation is additionally capped per principal. As a workaround, disable the SSE transport. | ||||
| CVE-2026-93312 | 1 Freedesktop | 1 Poppler | 2026-09-18 | 4.3 Medium |
| A flaw has been found in Freedesktop Poppler 26.07.0. Impacted is the function JBIG2Stream::rewind of the file poppler/JBIG2Stream.cc. This manipulation causes null pointer dereference. It is possible to initiate the attack remotely. The exploit has been published and may be used. Upgrading to version 26.08.0 is recommended to address this issue. Patch name: 5e49250f13b0390edeb3f90eb4c02c9941f97067. Upgrading the affected component is advised. | ||||
| CVE-2026-89900 | 1 Linux | 1 Linux Kernel | 2026-09-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: media: cec: core: Fix kmemleak due to missed rc_free_device() call The commit dccc0c3ddf8f ("media: rc: fix race between unregister and urb/irq callbacks") removed the implicit call to rc_free_device() from rc_unregister_device(). However, the commit missed to remove the NULL assignment of adap->rc that is now causing rc_free_device() to never be called on an allocated rc device. kmemleak reports following after e.g. dw-hdmi unbind: unreferenced object 0xffff00010ac10000 (size 4096): comm "kworker/u16:1", pid 39, jiffies 4294897739 hex dump (first 32 bytes): 20 23 4b 0a 01 00 ff ff 08 00 c1 0a 01 00 ff ff #K............. 08 00 c1 0a 01 00 ff ff 00 00 00 00 00 00 00 00 ................ backtrace (crc e11baccc): kmemleak_alloc+0x38/0x44 __kmalloc_cache_noprof+0x4a8/0x5e0 rc_allocate_device+0x48/0x2a0 cec_allocate_adapter+0x3ac/0x800 dw_hdmi_cec_probe+0x264/0x634 platform_probe+0xc0/0x188 really_probe+0x4a4/0x8e0 __driver_probe_device+0x2f8/0x440 driver_probe_device+0x60/0x160 __device_attach_driver+0x1a0/0x2a0 bus_for_each_drv+0x100/0x1a0 __device_attach+0x174/0x350 device_initial_probe+0x90/0xb0 bus_probe_device+0x4c/0x120 device_add+0xdec/0x116c platform_device_add+0x354/0x598 Remove the assignment of adap->rc to NULL to let cec_delete_adapter() free the allocated rc device after last user of the cec device exits to fix the kmemleak. | ||||
| CVE-2026-89933 | 1 Linux | 1 Linux Kernel | 2026-09-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iio: pressure: dps310: fix NULL pointer dereference on ACPI probe When the device is enumerated through its ACPI HID (IFX3100), i2c_client_get_device_id() returns NULL: the ACPI-derived client name does not match the driver's i2c_device_id table. dps310_probe() then dereferences that NULL pointer in "iio->name = id->name" and crashes the kernel during probe. The IIO device name is always "dps310", so set it directly and drop the now-unused device-id lookup. | ||||
| CVE-2026-89996 | 1 Linux | 1 Linux Kernel | 2026-09-18 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/<name> remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/ | ||||