vLLM 0.10.1 before 0.31.0 Cohere2 Vision DoS via max_patches

vLLM from 0.10.1 before 0.31.0 forwards a request-controlled mm_processor_kwargs.max_patches value to the Hugging Face processor for Cohere2 Vision models without a server-side upper bound, causing quadratic CPU work during multimodal preprocessing. Remote clients can send small image chat-completion requests with large, varying max_patches values to bypass the LRU cache, exhaust preprocessing workers, and deny service to other clients.

Fragment with another data representation releases an Application Relationship

P-Net before 1.0.4 releases the Application Relationship of an RPC session, without the abort procedure, when a fragment of a request has another data representation (endianness) than the first fragment of the call. The application is not told that the Application Relationship is gone, the cyclic data stops, and the resources of the Application Relationship are left referencing a cleared structure. Another host can then connect in its place. A host with ADJACENT network access that has observed the activity UUID of the connection, which is sent in clear in every RPC request, can do this with one PDU.

rails-html-sanitizer: Possible regular expression denial of service with certain configurations

rails-html-sanitizer is responsible for sanitizing HTML fragments in Rails applications. From 1.0.3 through 1.7.1, Rails::HTML::PermitScrubber checks SVG href and xlink:href local references with a pattern whose line-start anchor and whitespace class cause an all-whitespace value to be rescanned from each line start. An attacker who supplies HTML can cause quadratic CPU consumption when an application customizes its allowed tags to include an SVG reference element such as use and permits href or xlink:href. The default allowed tag configuration is not affected. CRuby 3.2 and later uses linear-time regular expression matching for this pattern, while CRuby 3.1 and earlier and JRuby are affected. This issue is fixed in version 1.7.2.

CPU exhaustion via a truncated gRPC message on streaming RPCs in elixir-grpc grpc_server

Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in elixir-grpc grpc_server and grpc allows unauthenticated attackers to occupy a BEAM scheduler indefinitely via a client-streaming or bidirectional-streaming request whose body ends inside a gRPC message. GRPC.Server.Adapters.Cowboy.read_stream/1 (grpc_server/lib/grpc/server/adapters/cowboy.ex, and the Cowboy adapter in grpc before the package split) asks for more data whenever the buffer does not hold a complete message. Once the request body has ended, every further read returns an empty chunk, so the buffer never changes and the function retries without end. A single 5-byte length prefix sent with END_STREAM keeps one scheduler busy for as long as the connection stays open, and repeated requests exhaust all schedulers. This issue affects grpc_server: from 1.0.0 before 1.1.0; grpc: from 0.3.1 before 1.0.0.

BACnet Stack: Uncontrolled recursion in Timer object writeback path leads to remote server stack overflow

BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to version 1.5.1, there is a remotely reachable denial-of-service vulnerability in bacnet-stack affecting the default demo server built from the unmodified apps/server/main.c. This issue has been patched in version 1.5.1.

Memory exhaustion via compressed Erlang terms in the elixir-grpc Erlpack codec

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in elixir-grpc grpc_core and grpc allows unauthenticated attackers to exhaust server memory via a compressed Erlang external term in a gRPC message body. GRPC.Codec.Erlpack.decode/2 (grpc_core/lib/grpc/codec/erlpack.ex, and lib/grpc/codec/erlpack.ex before the package split) passes the message body to :erlang.binary_to_term/2. That function inflates a compressed term in full before it returns. The codec sets no limit on the decoded size, and its type checks run only on the decoded term. The server's max_body_size limit counts the compressed bytes of the request. A request with Content-Type: application/grpc+erlpack can therefore make the server allocate a term much larger than the request body. This issue affects grpc: from 0.4.0 before 1.0.0; grpc_core: from 1.0.0 before 1.1.0.

A uncontrolled resource consumption vulnerability in Fortinet FortiMail 8.0.0 through 8.0.1, FortiMail 7.6.0 through 7.6.6, FortiMail 7.4.0 through 7.4.6 may allow a remote unauthenticated attacker to cause a denial of service via repeated unauthenticated POST requests.

Denial of Service via Maliciously Compressed Spreadsheet File in Fileorbis's FileOrbis NextGen FileServer

Improper handling of highly compressed data (data amplification) vulnerability in Fileorbis Bilişim Hizmetleri Ticaret Anonim Şirketi FileOrbis NextGen FileServer allows Sustained Client Engagement. This issue affects FileOrbis NextGen FileServer: before 12.7.

Libmodulemd: libmodulemd: missing decompressed-size limit when parsing compressed yaml

A flaw was found in libmodulemd. In builds with rpmio support enabled, compressed modulemd YAML is decompressed through a custom read handler that does not enforce a cumulative decompressed-size limit before parsing. An attacker who can supply a highly compressible compressed YAML file can cause excessive CPU and memory consumption, resulting in a denial of service.

Openshift/oauth-server: openshift/oauth-server: quadratic-time dos via accept-language header underscore bypass on unauthenticated login endpoints

A flaw was found in openshift/oauth-server. The OAuth login and error page endpoints pass the unauthenticated Accept-Language header to golang.org/x/text/language.ParseAcceptLanguage() without input validation. A bypass of the CVE-2022-32149 mitigation exists: the upstream guard counts only '-' characters but the internal BCP 47 scanner aliases '_' to '-' after the guard check. An unauthenticated attacker can send a crafted Accept-Language header using '_' separators to trigger quadratic-time parsing, consuming excessive CPU and denying authentication to all cluster users.

In DecodeHeaderComponent of SipStack.cpp, there is a possible way to trigger stack exhaustion via unbounded mutual recursion due to a resource exhaustion. This could lead to remote denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

Krb5: mit krb5 kdc unauthenticated cpu dos via quadratic asn.1 sequence of decoding

decode_sequence_of() in lib/krb5/asn.1/asn1_encode.c in MIT Kerberos 5 (aka krb5) 1.11 and later grows the decoded element array one entry at a time, which allows remote attackers to cause a denial of service (CPU consumption in the KDC) by sending an unauthenticated AS-REQ or TGS-REQ with a large number of elements in a SEQUENCE OF field over TCP.

Seraphinite Accelerator < 2.29.24 - Subscriber+ DoS via seraph_accel_State Update

The Seraphinite Accelerator WordPress plugin before 2.29.24 does not perform a capability check on one of its state-update AJAX actions, allowing authenticated users such as subscribers to write a malformed value that causes an uncaught error on every subsequent admin page load, making the entire admin area inaccessible to all administrators (denial of service).

fast-xml-parser: Quadratic CPU consumption scanning unterminated stop-node tags

fast-xml-parser allows users to process XML from JS object without C/C++ based libraries or callbacks. Prior to 5.12.0, when the non-default stopNodes option is enabled, readStopNodeData() in OrderedObjParser.js calls readTagExp() for each less-than character in an unterminated stop-node body and repeatedly rescans the remaining input while looking for a closing greater-than character. An attacker who supplies XML containing many tag fragments without a later closing character can cause quadratic rescanning before parsing fails, blocking a Node.js event loop and causing CPU-exhaustion denial of service. This issue is fixed in version 5.12.0.

Zephyr PTP: unvalidated Delay_Resp message interval lets an on-link peer wedge the PTP thread and flood the network

The IEEE 1588 (PTP) port implementation in subsys/net/lib/ptp/port.c adopted the logMessageInterval field of a received Delay_Resp message without any validation. port_delay_resp_msg_process() stored the raw wire value (a full-range int8_t) into port_ds.log_min_delay_req_interval, and that value is later used as a shift count by port_timer_set_timeout() when the Delay_Req timer is armed. Values below about -30 truncate the computed timeout to zero, and values with a magnitude of 64 or more perform an undefined shift of a uint64_t; the standards-defined "not applicable" encoding 0x7F fell into the latter case as well. PTP messages are received over unauthenticated link-local traffic (UDP multicast on 224.0.1.129, IPv6 multicast, or raw IEEE 802.3), and the handler accepts a Delay_Resp from any sender as long as the port is a time receiver using the end-to-end delay mechanism and the message echoes the port identity and a pending sequence id — both of which the victim itself broadcasts in its Delay_Req. Any node on the same link can therefore inject a single crafted Delay_Resp, or simply become the time transmitter and advertise the bogus interval. Once the delay timer is armed with a zero timeout, the cooperative PTP thread re-arms and retransmits a Delay_Req on every tick. Each transmission takes a buffer from the fixed CONFIG_PTP_MSG_POLL_SIZE message slab (default 10) and holds it on port->delay_req_list for three seconds, so the slab is emptied within milliseconds and ptp_msg_alloc() then blocks with K_FOREVER inside the only thread that frees those buffers — permanently stalling time synchronization until reboot. Where a transmit-timestamp callback on another thread keeps recycling buffers, the result is instead a sustained multicast Delay_Req flood and continuous CPU consumption. There is no memory corruption and no disclosure of data; the impact is availability of the PTP subsystem and of the local network segment. The fix rejects intervals outside a representable range and treats 0x7F as "not applicable" as required by IEEE 1588-2019 Table 42. The equivalent unchecked adoption of logMessageInterval from Sync messages in port_sync_msg_process(), a weaker variant of the same issue, is fixed by the companion change 334bf57f416f (#118150), which applies the same range check, ignores the field for unicast Sync messages and treats 0x7F as not applicable.

NLTK before 3.10.4 CPU Denial of Service via ConllCorpusReader srl_instances

NLTK before 3.10.4 contains a quadratic-time denial of service vulnerability in ConllCorpusReader._get_srl_instances that allows remote attackers to exhaust CPU through nested span rescans. Attackers can supply a crafted CoNLL SRL corpus with many predicates and span columns, placing the head span last, to pin a core for minutes.

NLTK before 3.10.4 Quadratic CPU Denial of Service via Tree.chomsky_normal_form

NLTK before 3.10.4 contains a denial of service vulnerability in Tree.chomsky_normal_form that allows remote attackers to exhaust CPU through quadratic-time right-factor binarization using list.pop(0). Attackers can supply a wide flat treebank tree parsed by Tree.fromstring to force tens of seconds of single-threaded CPU consumption, blocking the processing thread.

NLTK before 3.10.4 Quadratic-Time Denial of Service via CCG Lexicon fromstring

NLTK before 3.10.4 contains a denial of service vulnerability in the CCG lexicon parser fromstring that allows remote attackers to exhaust CPU by supplying wide inputs. Attackers can submit lexicon text with long flat bracket bodies or operator chains, triggering quadratic string re-slicing in matchBrackets and augParseCategory that blocks worker threads.

NLTK from 3.2.5 before 3.10.4 CPU Exhaustion via TreebankWordTokenizer.span_tokenize

NLTK from 3.2.5 before 3.10.4 contains an algorithmic complexity vulnerability in TreebankWordTokenizer.span_tokenize that allows remote attackers to cause quadratic CPU consumption through repeated list.pop(0) calls. Attackers can submit long runs of double-quote characters to services span-tokenizing untrusted text, exhausting a CPU core and degrading availability.

NLTK from 3.6 before 3.10.4 Quadratic CPU Exhaustion via LegalitySyllableTokenizer.tokenize

NLTK from 3.6 before 3.10.4 contains an algorithmic complexity vulnerability in LegalitySyllableTokenizer.tokenize that allows remote attackers to exhaust CPU by supplying long all-vowel tokens. Attackers can submit a token such as a long run of vowels, causing the unguarded onset reversal loop to perform quadratic work and deny service to syllabification components.