Total
4148 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-67228 | 1 Broadcom | 1 Rabbitmq Server | 2026-10-30 | N/A | 4.9 MEDIUM |
| RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, The runtime-parameters lookup path coerces the URL :component segment to an atom with rabbit_data_coercion:to_atom/1 in lookup_component/1 (deps/rabbit/src/rabbit_runtime_parameters.erl), creating a new atom for any previously unseen value. A safe helper, rabbit_registry:binary_to_type/1, which uses binary_to_existing_atom with a catch, already exists but is not used at this call site. lookup_component/1 calls rabbit_data_coercion:to_atom(Component) on the :component segment of the request URL, converting an attacker-supplied string into a new atom. Because the Erlang atom table is bounded and atoms are never garbage collected, an authorized policymaker issuing roughly one million requests with distinct component values can exhaust the atom table and crash the node, resulting in a denial of service. Preconditions include Exploitation requires policymaker privileges and roughly one million requests.. This issue is fixed in versions 4.2.7 and 4.3.1. | |||||
| CVE-2026-67238 | 1 Broadcom | 1 Rabbitmq Server | 2026-10-30 | N/A | 6.5 MEDIUM |
| RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, rabbit_pid_codec:decompose_from_binary/1 parses a caller-supplied ETF-encoded binary and calls binary_to_atom(Node, utf8) on the node-name field. It is reached from rabbit_volatile_queue:pid_from_name/2, which is invoked for any queue name / routing key beginning amq.rabbitmq.reply-to.. The CandidateNodes membership check happens after the atom is created, and the surrounding try/catch cannot reclaim atoms (they are never GC'd). binary_to_existing_atom is not used. Any authenticated AMQP client can crash the entire Erlang VM (all vhosts, all connections) with ~1M cheap requests. Preconditions include Authenticated AMQP 0-9-1 connection to any vhost No per-connection rate limit low enough to make ~1M operations infeasible. This issue is fixed in versions 4.2.7 and 4.3.1. | |||||
| CVE-2026-119206 | 2026-10-30 | N/A | N/A | ||
| pypdf is a free and open-source pure-python PDF library. Prior to 6.21.3, pypdf can take excessive time to retrieve page labels from a crafted PDF containing a flat page-label number tree with many ranges. The page_labels property resolves each page independently and repeatedly scans the same /Nums array from the beginning, causing work to grow with both the page count and the number of label ranges. This issue is fixed in version 6.21.3. | |||||
| CVE-2026-119204 | 2026-10-30 | N/A | N/A | ||
| pypdf is a free and open-source pure-python PDF library. Prior to 6.21.4, pypdf can consume excessive memory while parsing a crafted PDF page tree containing many shared resources. Page-tree flattening copies page dictionary and inherited resource entries without a document-wide entry budget, allowing the crafted resource structure to cause disproportionate allocations. This issue is fixed in version 6.21.4. | |||||
| CVE-2026-119208 | 2026-10-30 | N/A | N/A | ||
| pypdf is a free and open-source pure-python PDF library. Prior to 6.21.3, pypdf can consume excessive time and memory when an application accesses the page count of a crafted encrypted PDF whose page tree declares a forged /Count value. Even after successful decryption, page-count retrieval trusts the unvalidated declared count instead of walking the page tree, allowing the attacker-controlled value to drive excessive work and memory use. This issue is fixed in version 6.21.3. | |||||
| CVE-2026-118779 | 2026-10-30 | N/A | 7.5 HIGH | ||
| Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used pem.decode(), lib/pem.js, missing END line to process the relevant input or security decision. node-forge used polynomial-time regular expressions in pem.decode(), including when searching for a matching END line and parsing encapsulated headers. An unauthenticated attacker able to supply PEM input to any high-level parser could consume excessive CPU with a long malformed message and cause denial of service. This issue is fixed in version 1.4.1. | |||||
| CVE-2026-119207 | 2026-10-30 | N/A | N/A | ||
| pypdf is a free and open-source pure-python PDF library. Prior to 6.21.3, pypdf can consume excessive memory when strict mode loads a crafted invalid PDF dictionary. Nested parsing failures add repeated exception text to newly raised errors, allowing a small malformed dictionary to amplify into very large error messages. This issue is fixed in version 6.21.3. | |||||
| CVE-2026-96636 | 1 Python | 1 Pillow | 2026-10-30 | N/A | 6.5 MEDIUM |
| Pillow is a Python imaging library. Prior to 13.0.0, MpoImageFile.seek() and DcxImageFile.seek() reparse later MPO or DCX frames and replace self._size without rerunning Image._decompression_bomb_check(). A crafted multi-frame image can use a tiny first frame to pass Image.open() and then declare an over-limit later frame. Normal frame iteration through seek(), load(), or ImageSequence.Iterator can decode that frame and commit hundreds of megabytes or more, causing memory-exhaustion denial of service. This issue is fixed in version 13.0.0. | |||||
| CVE-2026-86019 | 2026-10-30 | N/A | N/A | ||
| Part-DB is an open source inventory management system for electronic components. Prior to version 2.13.2, Part-DB allows authenticated API users to bypass the configured maximum attachment file size by uploading attachments through the API using base64-encoded file data. The application enforces the configured attachment size limit for normal browser-based file uploads, but the API base64 upload path does not apply the same size validation. As a result, an authenticated user with API access and permission to create attachments can upload files larger than the configured maximum attachment size, potentially exhausting disk space and causing a denial of service. This issue has been patched in version 2.13.2. | |||||
| CVE-2026-78058 | 2026-10-30 | N/A | 7.5 HIGH | ||
| Uncontrolled resource consumption in the HTTP/2 (h2) receive path of Apache bRPC (version < 1.18.0) on all platforms allows a remote unauthenticated attacker to crash the server or grow its memory without bound by sending crafted HTTP/2 frames. Root Cause: The h2 parser, enabled by default on every bRPC server port and used by h2/gRPC clients, trusts the peer to respect receive-side limits that bRPC advertises but never enforces: 1. SETTINGS_MAX_CONCURRENT_STREAMS defaulted to unlimited and was never checked on the server, letting a peer pin an unbounded number of pending streams per connection (~100x memory amplification). 2. SETTINGS_MAX_HEADER_LIST_SIZE defaulted to unlimited and was never enforced; 1-byte HPACK indexed references amplify a small HEADERS frame ~4000x into an unbounded decoded header list ("HPACK bomb"), and a never-completed HEADERS/CONTINUATION block accumulates memory without limit. 3. Control-frame acks (PING/SETTINGS acks, RST_STREAM, GOAWAY, WINDOW_UPDATE) unconditionally bypassed the -socket_max_unwritten_bytes write cap, so a PING flood combined with withheld TCP reads grew the connection buffer without the documented bound. 4. The HPACK dynamic table size update was validated against the protocol default (4096) instead of the advertised SETTINGS_HEADER_TABLE_SIZE, which together with the dynamic-table queue/accounting issue can desynchronize the decoder and dereference NULL (crash). Affected scenarios: Any bRPC server serving HTTP/h2/gRPC to an untrusted network, and any bRPC h2/gRPC client connecting to an untrusted backend. The h2 parser runs before any Authenticator check on the shared port. How to fix: Upgrade bRPC, or apply the patch in https://github.com/apache/brpc/pull/3474. Note: After applying the fix the following limits are enforced by default: - max_concurrent_streams: 1024 per connection (4294967295 restores unlimited). - max_header_list_size: 1 MiB decoded size per stream (4294967295 restores unlimited; -h2_client_max_header_list_size for clients). - h2 control-frame acks respect -socket_max_unwritten_bytes (-h2_ack_ignore_eovercrowded restores the old behavior). Requests exceeding these limits are rejected (RST_STREAM(REFUSED_STREAM) or a connection error). | |||||
| CVE-2026-119284 | 2026-10-30 | N/A | N/A | ||
| joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.6, joserfc compact JWS deserialization calls bytes.split() before enforcing the existing aggregate segment-size limits. When attacker-controlled compact serialization bytes reach deserialize_compact(), the split creates copies of the header, payload, and signature segments before ExceededSizeError rejects them, causing an additional allocation approximately proportional to the supplied token. Requests that exhaust available process memory can therefore cause an availability failure even though signature verification fails. This issue is fixed in version 1.7.6. | |||||
| CVE-2026-119283 | 2026-10-30 | N/A | 7.5 HIGH | ||
| joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.5, joserfc.jwe.decrypt_json() accepts a JWE General JSON Serialization recipients array without a count limit and calls decrypt_cek() for every entry. An unauthenticated attacker who can submit a JWE to an endpoint using an RSA key-management algorithm can choose the number of private-key decryption operations performed by one request. The verify_all_recipients option does not reduce this work because the affected loop processes every recipient before consulting that setting, allowing repeated requests to exhaust service CPU without affecting confidentiality or integrity. This issue is fixed in version 1.7.5. | |||||
| CVE-2026-115585 | 2026-10-30 | N/A | N/A | ||
| pypdf is a free and open-source pure-python PDF library. Prior to 6.21.2, an incomplete remediation for repeated malformed cross-reference entries in GHSA-55h5-xmcq-c37v could still trigger a complete PDF stream reload during each recovery attempt even when a recovery cache was present, causing crafted cross-reference streams to produce long runtimes. This issue is fixed in version 6.21.2. | |||||
| CVE-2026-113795 | 2026-10-30 | N/A | N/A | ||
| pypdf is a free and open-source pure-python PDF library. Prior to 6.20.0, accessing a crafted PDF stream with a large number of filters or multiple filters that pass around large amounts of data can cause large memory consumption. This issue is fixed in version 6.20.0. | |||||
| CVE-2026-113791 | 2026-10-30 | N/A | N/A | ||
| pypdf is a free and open-source pure-python PDF library. Prior to 6.21.0, an attacker can craft a PDF containing a content stream with many small operations, causing parsing to consume large amounts of memory. This issue is fixed in version 6.21.0. | |||||
| CVE-2026-101432 | 1 Oracle | 1 Peoplesoft Enterprise Peopletools | 2026-10-30 | N/A | 5.3 MEDIUM |
| Vulnerability in the PeopleSoft Enterprise PeopleTools product of Oracle PeopleSoft (component: Test Framework). Supported versions that are affected are 8.61-8.63. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where PeopleSoft Enterprise PeopleTools executes to compromise PeopleSoft Enterprise PeopleTools. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of PeopleSoft Enterprise PeopleTools accessible data as well as unauthorized read access to a subset of PeopleSoft Enterprise PeopleTools accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of PeopleSoft Enterprise PeopleTools. CVSS 3.1 Base Score 5.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L). | |||||
| CVE-2026-101415 | 1 Oracle | 1 Peoplesoft Enterprise Peopletools | 2026-10-30 | N/A | 3.1 LOW |
| Vulnerability in the PeopleSoft Enterprise PeopleTools product of Oracle PeopleSoft (component: Analytic Server). Supported versions that are affected are 8.61-8.63. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise PeopleTools. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of PeopleSoft Enterprise PeopleTools. CVSS 3.1 Base Score 3.1 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L). | |||||
| CVE-2026-101412 | 1 Oracle | 1 Peoplesoft Enterprise Peopletools | 2026-10-30 | N/A | 5.8 MEDIUM |
| Vulnerability in the PeopleSoft Enterprise PeopleTools product of Oracle PeopleSoft (component: Analytic Server). Supported versions that are affected are 8.61-8.63. Difficult to exploit vulnerability allows low privileged attacker with logon to the infrastructure where PeopleSoft Enterprise PeopleTools executes to compromise PeopleSoft Enterprise PeopleTools. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all PeopleSoft Enterprise PeopleTools accessible data as well as unauthorized read access to a subset of PeopleSoft Enterprise PeopleTools accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of PeopleSoft Enterprise PeopleTools. CVSS 3.1 Base Score 5.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:L). | |||||
| CVE-2026-86147 | 2026-10-30 | N/A | 7.5 HIGH | ||
| External control of file name or path and uncontrolled resource consumption in Apache bRPC (version < 1.18.0) on all platforms allows remote attackers who can reach the builtin service port to create directories and truncate/overwrite files with the privileges of the server process, or to hold the process-wide CPU/contention profiler for an arbitrarily long time. Root Cause: 1. The builtin /flags service allows gflags carrying a validator to be modified at runtime via ?setvalue=. The bvar/mbvar dump path gflags (bvar_dump_file, bvar_dump_tabs, mbvar_dump_file) were registered with an accept-anything validator whose only purpose was to wake the dumping thread. A remote attacker could therefore repoint the dump path (e.g. GET /flags/bvar_dump_file?setvalue=/victim/dir/target followed by GET /flags/bvar_dump?setvalue=true, or the equivalent for mbvar_dump_file, which is used verbatim without a forced suffix), making the dumping thread recursively create directories and open/truncate files at attacker-chosen locations. Tab names in bvar_dump_tabs were appended to the path without sanitization, allowing '..' to escape the configured directory. 2. The /pprof builtin service did not clamp the ?seconds= parameter to FLAGS_max_profiling_seconds (a limit that /hotspots enforced). A single request such as ?seconds=2147483647 made the handler sleep for decades while holding the process-wide gperftools CPU profiler or bthread contention profiler, so /hotspots/cpu and /hotspots/contention returned 503 for everyone else during that time. Affected Scenarios: Any Apache bRPC server exposing the builtin services (enabled by default on the same port as normal RPC traffic) to untrusted networks. How to Fix: (Choose one of the following options) 1. Upgrade bRPC to version 1.18.0, which fixes this issue. 2. Apply this patch: https://github.com/apache/brpc/pull/3523 Note: After the fix, bvar_dump_file, bvar_dump_tabs and mbvar_dump_file can no longer be modified at runtime through the /flags builtin service. They can still be changed programmatically via google::SetCommandLineOption(), taking effect on the next dump cycle. The profiling duration of /pprof is now capped by the -max_profiling_seconds gflag (default 300 seconds), which can be adjusted by the server owner. | |||||
| CVE-2026-81755 | 2026-10-30 | N/A | 7.5 HIGH | ||
| Uncontrolled resource consumption in the streaming RPC component of Apache bRPC (version < 1.18.0) allows a remote attacker to exhaust server memory and cause denial of service by sending a single RPC request that declares an excessive number of streams. Root Cause: In the streaming RPC feature, a client can declare multiple streams in one RPC request by putting extra stream identifiers into the repeated field `stream_settings.extra_stream_ids` of the RPC meta. On the server side, `StreamAccept` creates one response stream for every stream identifier declared by the request, without limiting the number of streams accepted in a single RPC. The request body size is only bounded by `max_body_size` (default 64MB), which is enough to carry millions of stream identifiers. Each accepted stream allocates its own bthread execution queue and associated resources, so a single crafted request can make the server create a huge number of streams and exhaust memory, leading to denial of service. Affected Scenarios: Use a bRPC server that serves streaming RPC and calls `StreamAccept` to accept streams from untrusted clients. How to Fix: (Choose one of the following options) 1. Upgrade bRPC to the 1.18.0 version. 2. Apply this patch: https://github.com/apache/brpc/pull/3493 Note: The fix adds a new gflag `stream_max_streams_per_request` with a default value of 64. Requests declaring more streams than the limit are rejected before any response stream is created. Applications that legitimately need to accept more than 64 streams in one RPC must raise this flag; otherwise such requests will fail after applying the fix. | |||||