Base de CVEs

SvelteKit is a framework for rapidly developing robust, performant web applications using Svelte. Prior to 2.57.1, redirect, when called from inside the handle server hook with a location parameter containing characters that are invalid in a HTTP header, will cause an unhandled TypeError. This could result in DoS on some platforms, especially if the location passed to redirect contains unsanitized user input. This vulnerability is fixed in 2.57.1.

Wasmtime is a runtime for WebAssembly. Starting with Wasmtime 39.0.0, the `component-model-async` feature became the default, which brought with it a new implementation of `[Typed]Func::call_async` which made it capable of calling async-typed guest export functions. However, that implementation had a bug leading to a panic under certain circumstances: First, the host embedding calls `[Typed]Func::call_async` on a function exported by a component, polling the returned `Future` once. Second, the component function yields control to the async runtime (e.g. Tokio), e.g. due to a call to host function registered using `LinkerInstance::func_wrap_async` which yields, or due an epoch interruption. Third, the host embedding drops the `Future` after polling it once. This leaves the component instance in a non-reenterable state since the call never had a chance to complete. Fourth, the host embedding calls `[Typed]Func::call_async` again, polling the returned `Future`. Since the component instance cannot be entered at this point, the call traps, but not before allocating a task and thread for the call. Fifth, the host embedding ignores the trap and drops the `Future`. This panics due to the runtime attempting to dispose of the task created above, which panics since the thread has not yet exited. When a host embedder using the affected versions of Wasmtime calls `wasmtime::component::[Typed]Func::call_async` on a guest export and then drops the returned future without waiting for it to resolve, and then does so again with the same component instance, Wasmtime will panic. Embeddings that have the `component-model-async` compile-time feature disabled are unaffected. Wasmtime 40.0.4 and 41.0.4 have been patched to fix this issue. Versions 42.0.0 and later are not affected. If an embedding is not actually using any component-model-async features then disabling the `component-model-async` Cargo feature can work around this issue. This issue can also be worked around by either ensuring every `call_async` future is awaited until it completes or refraining from using the `Store` again after dropping a not-yet-resolved `call_async` future.

An Improper Handling of Exceptional Conditions vulnerability in the packet forwarding engine (PFE) of Juniper Networks Junos OS on SRX Series allows an unauthenticated network-based attacker sending a specific ICMP packet through a GRE tunnel to cause the PFE to crash and restart. When PowerMode IPsec (PMI) and GRE performance acceleration are enabled and the device receives a specific ICMP packet, a crash occurs in the SRX PFE, resulting in traffic loss. PMI is enabled by default, and GRE performance acceleration can be enabled by running the configuration command shown below. PMI is a mode of operation that provides IPsec performance improvements using Vector Packet Processing. Note that PMI with GRE performance acceleration is only supported on specific SRX platforms. This issue affects Junos OS on the SRX Series: * all versions before 21.4R3-S12,  * from 22.4 before 22.4R3-S8,  * from 23.2 before 23.2R2-S5,  * from 23.4 before 23.4R2-S5,  * from 24.2 before 24.2R2-S3,  * from 24.4 before 24.4R2-S1,  * from 25.2 before 25.2R1-S1, 25.2R2.

matrix-sdk-base is the base component to build a Matrix client library. Versions 0.14.1 and prior are unable to handle responses that include custom m.room.join_rules values due to a serialization bug. This can be exploited to cause a denial-of-service condition, if a user is invited to a room with non-standard join rules, the crate's sync process will stall, preventing further processing for all rooms. This is fixed in version 0.16.0.

A security issue exists within the Studio 5000 Logix Designer add-on profile (AOP) for the ArmorStart Classic distributed motor controller, resulting in denial-of-service. This vulnerability is possible due to the input of invalid values into Component Object Model (COM) methods.

there is a possible way to bypass due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.

In libtirpc before 1.3.3rc1, remote attackers could exhaust the file descriptors of a process that uses libtirpc because idle TCP connections are mishandled. This can, in turn, lead to an svc_run infinite loop without accepting new connections.

Inappropriate implementation in V8 in Google Chrome prior to 95.0.4638.69 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

selectExpander in select.c in SQLite 3.30.1 proceeds with WITH stack unwinding even after a parsing error.

Unbound before 1.9.4 accesses uninitialized memory, which allows remote attackers to trigger a crash via a crafted NOTIFY query. The source IP address of the query must match an access-control rule.

A vulnerability in the Bidirectional Forwarding Detection (BFD) offload implementation of Cisco Catalyst 4500 Series Switches and Cisco Catalyst 4500-X Series Switches could allow an unauthenticated, remote attacker to cause a crash of the iosd process, causing a denial of service (DoS) condition. The vulnerability is due to insufficient error handling when the BFD header in a BFD packet is incomplete. An attacker could exploit this vulnerability by sending a crafted BFD message to or across an affected switch. A successful exploit could allow the attacker to trigger a reload of the system. This vulnerability affects Catalyst 4500 Supervisor Engine 6-E (K5), Catalyst 4500 Supervisor Engine 6L-E (K10), Catalyst 4500 Supervisor Engine 7-E (K10), Catalyst 4500 Supervisor Engine 7L-E (K10), Catalyst 4500E Supervisor Engine 8-E (K10), Catalyst 4500E Supervisor Engine 8L-E (K10), Catalyst 4500E Supervisor Engine 9-E (K10), Catalyst 4500-X Series Switches (K10), Catalyst 4900M Switch (K5), Catalyst 4948E Ethernet Switch (K5). Cisco Bug IDs: CSCvc40729.

The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.