Export limit exceeded: 107873 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (107873 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-116134 | 1 Libwww-perl | 1 Http-body | 2026-10-29 | 7.5 High |
| HTTP::Body versions before 1.23_01 for Perl allow memory exhaustion via an unbounded multipart part header block. The multipart parser takes everything up to the first blank line after a boundary as the part's header block, with no limit on its size or number of lines. Every line is stored in the part's header hash, so a block of short lines costs about 60 bytes of memory per input byte. A remote attacker can exhaust worker memory with a single request. | ||||
| CVE-2026-116132 | 1 Libwww-perl | 1 Http-body | 2026-10-29 | 7.5 High |
| HTTP::Body versions before 1.23_01 for Perl leave the temporary file of an incomplete multipart upload on disk. The multipart parser creates a temporary file as soon as a file part starts, but adds it to the upload list only when the part completes. Uploads are only ever deleted from that list, by the cleanup option or by the caller, so a body that ends inside a file part leaves its temporary file where nothing can find it. A remote attacker can fill the temporary directory by repeating such requests, leaving one file behind for each. | ||||
| CVE-2025-47761 | 1 Fortinet | 2 Forticlient, Forticlientwindows | 2026-10-29 | 7.1 High |
| An Exposed IOCTL with Insufficient Access Control vulnerability [CWE-782] vulnerability in Fortinet FortiClientWindows 7.4.0 through 7.4.3, FortiClientWindows 7.2.0 through 7.2.9 may allow an authenticated local user to execute unauthorized code via fortips driver. Success of the attack would require bypassing the Windows memory protections such as Heap integrity and HSP. In addition, it requires a valid and running VPN IPSec connection. | ||||
| CVE-2026-110985 | 1 Apache | 1 Kafka | 2026-10-29 | 8.1 High |
| A Kafka broker using SASL/OAUTHBEARER with the default validator (sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from configuration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the JWT signature. When that URL is unset (the default) and no verification key resolver is supplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not verify the JWT signature, algorithm, or issuer - and the broker starts with no warning or error. This is the residual of CVE-2026-33557, whose fix restored signature verification only on the path where the JWKS endpoint URL is set. Impact: A broker in this state accepts any structurally valid JWT, including "alg":"none" tokens. An unauthenticated remote attacker who can reach the listener can forge a token asserting any principal - including configured superusers - and gain full access to the cluster. Only brokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a custom verification key resolver) are affected; brokers that set the URL verify signatures and are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here no signature is verified at all. Mitigation (all affected versions, no upgrade required): Set sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses OAuthBearerValidatorCallbackHandler, or configure a signature-verifying sasl.oauthbearer.jwt.validator.class. Resolution: From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the non-verifying ClientJwtValidator fails to start with a ConfigException instead of running without signature verification (secure by default). | ||||
| CVE-2026-111551 | 1 Apache | 1 Kafka | 2026-10-29 | 7.5 High |
| Several Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer, with no check against the bytes actually available. A small crafted input can therefore declare a very large size and force a multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext (header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length, which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde). Impact: An attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the affected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected. The reachable surface depends on the path: writing a crafted record to a Streams application's internal changelog or repartition topics, or committing crafted offset metadata to its consumer group (Streams internal paths); writing a crafted record to any topic that a consumer reads with ListSerde (ListDeserializer); or, as a member of a Streams consumer group, returning crafted assignment data when elected leader (AssignmentInfo). Because a crafted record remains in its topic, the error can recur on restart. The record size limit (max.message.bytes) does not help, because the allocation is driven by a size field rather than by the input's length. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is enabled, restrict write access to each application's internal topics and consumer group to its own principal, and restrict who can produce to topics that are consumed with ListSerde. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths validate the declared size against the remaining input before allocating and reject input that fails the check. | ||||
| CVE-2026-111108 | 1 Apache | 1 Kafka | 2026-10-29 | 7.5 High |
| Apache Kafka's code-generated protocol readers pre-size an array's collection from the element count declared by the sender. That count is checked only against the bytes remaining in the request buffer, which assumes about one byte per element; because most elements need several bytes, a request can declare far more elements than the buffer holds and still pass. For a keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +1), so a request of a few tens of megabytes can force a heap allocation several times larger before any element is read. The pattern is emitted into every generated reader, so it affects all Kafka API types with an array field. Impact: Request parsing happens before any authorization check. On a listener that does not require authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent requests that each declare a very large= array length and allocate many times their wire size in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification). On listeners that require authentication, the attacker needs valid credentials but no specific ACL, since parsing precedes authorization.. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand, and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000). | ||||
| CVE-2026-85874 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-29 | 7.8 High |
| Use after free in Windows Message Queuing Queue Manager allows an authorized attacker to execute code locally. | ||||
| CVE-2026-85884 | 1 Microsoft | 8 Windows 11 24h2, Windows 11 24h2, Windows 11 25h2 and 5 more | 2026-10-29 | 7.8 High |
| Missing authentication for critical function in Windows Health and Optimized Experiences Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-83845 | 1 Microsoft | 17 Windows 10 21h2, Windows 10 21h2, Windows 10 22h2 and 14 more | 2026-10-29 | 8.4 High |
| Improper privilege management in Windows Internet (wininet.dll) allows an authorized attacker to perform spoofing locally. | ||||
| CVE-2026-83848 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-29 | 7.8 High |
| Untrusted pointer dereference in Windows COM+ Event System Service allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-99016 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: riscv: futex: untag the user pointer before the atomic access access_ok() checks untagged_addr(uaddr), but arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic() hand the raw uaddr to the inline asm amoswap/amoadd/.../lr.w+sc.w through the "+m" (*uaddr) operand. When the tagged address ABI is enabled (CONFIG_RISCV_ISA_SUPM, prctl PR_SET_TAGGED_ADDR_CTRL with PMLEN != 0), those two addresses differ: a user pointer whose top PMLEN bits hold a tag passes access_ok() after untagging, but the atomic is then performed on the still-tagged raw address. Supervisor-mode data accesses are not subject to the U-mode pointer masking (that is governed by menvcfg.PMM, which the kernel does not set), so hardware does not strip the tag for the kernel's own access. With Sv57 and PMLEN=16 the tag bits overlap the canonical-address bits, so a tagged pointer can name a canonical kernel virtual address (e.g. in the linear map) whose untagged form is a valid user address. An unprivileged process can thus make FUTEX_WAKE_OP perform an atomic read-modify-write on an arbitrary kernel address, with the matching FUTEX_OP_CMP_* result serving as a read oracle. get_user()/put_user()/raw_copy_{to,from}_user() already untag the pointer after the access_ok() check; do the same in the futex helpers so the atomic operates on the address that was actually validated. | ||||
| CVE-2026-99030 | 1 Linux | 2 Linux, Linux Kernel | 2026-10-29 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits() When skb_copy_and_csum_bits() reaches unreadable frags it returns 0 after copying only the linear part, and the rest of the caller's buffer is left as it was. The callers copy into a buffer that is about to go out on the wire: an ICMP error quoting the offending packet, or a driver's TX bounce buffer in skb_copy_and_csum_dev(). Neither buffer is zeroed beforehand, so whatever was in memory there gets sent. Zero the part of the buffer we didn't fill. The checksum usually won't match the data any more, so the receiver will usually drop the packet, but either way it no longer carries anything it shouldn't. Only zero for a positive @len, a negative one from a broken caller must not turn into a huge memset(). | ||||
| CVE-2026-83850 | 1 Microsoft | 28 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 25 more | 2026-10-29 | 7.8 High |
| Heap-based buffer overflow in Microsoft Windows Search Component allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-83851 | 1 Microsoft | 20 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 17 more | 2026-10-29 | 8.8 High |
| Heap-based buffer overflow in Windows Partition Management Driver allows an unauthorized attacker to elevate privileges over a network. | ||||
| CVE-2026-83852 | 1 Microsoft | 10 Windows 11 24h2, Windows 11 24h2, Windows 11 25h2 and 7 more | 2026-10-29 | 7 High |
| Use after free in Windows Bind Filter Driver allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-114616 | 1 Authlib | 1 Authlib | 2026-10-29 | 7.4 High |
| Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.9.1, Authlib's OctKey.import_key() and HMAC signing and verification path accept zero-length key material. If an application's secret lookup can return an empty string or empty bytes, a remote attacker can compute the deterministic HS256, HS384, or HS512 signature for arbitrary token claims and have Authlib treat the token as authentic. This issue is fixed in version 1.9.1. | ||||
| CVE-2026-114615 | 1 Authlib | 1 Authlib | 2026-10-29 | 7.4 High |
| Authlib is a Python library which builds OAuth and OpenID Connect servers. From 1.3.1 until 1.9.0, OctKey.import_key() checks asymmetric-key markers only at byte zero while Authlib's PEM loaders accept leading whitespace, comments, or a byte-order mark. In deployments that use the documented mixed algorithm registry and already configure verification with PEM or certificate bytes containing such a prefix, an unauthenticated attacker who knows those same public-key bytes can use them as an HMAC secret and forge HS256 tokens with arbitrary identity or authorization claims. This is a bypass of the remediation for CVE-2024-37568. The module-level jwt object reaches OctKey.import_key() in authlib/jose/rfc7518/oct_key.py, where POSSIBLE_UNSAFE_KEYS fails to identify prefixed asymmetric key material. This issue is fixed in version 1.9.0. | ||||
| CVE-2026-112457 | 1 Apple | 1 Macos | 2026-10-29 | 7.1 High |
| A double free issue was addressed with improved memory management. This issue is fixed in macOS Golden Gate 27.2, macOS Sequoia 15.8.2, macOS Tahoe 26.7.2. An attacker on the local network may be able to cause unexpected system termination or corrupt process memory. | ||||
| CVE-2026-112427 | 1 Apple | 1 Macos | 2026-10-29 | 8.1 High |
| An authentication issue was addressed with improved state management. This issue is fixed in macOS Golden Gate 27.2. A remote attacker may be able to cause arbitrary code execution. | ||||
| CVE-2026-114724 | 1 Roundcube | 1 Webmail | 2026-10-29 | 7.4 High |
| Roundcube Webmail before 1.6.20 and 1.7.x before 1.7.5 contains an object injection primitive in rcube_session::unserialize(). A session key prefixed with “!” was treated as having no value, and the reconstructed serialized string was emitted with a key but no corresponding value, desynchronizing the remainder of the input so that following session data was interpreted as a serialized value. This yields a PHP object injection primitive for an attacker able to influence stored session data. Upstream fixed this in the commit “Fix object injection primitive in rcube_session::unserialize() via “!”-prefixed session keys”, which rejects such keys. | ||||