CVE Feed

SvelteKit (@sveltejs/kit) before 3.0.0 contains a cross-site scripting vulnerability in prerendered pages because a cache-control header value set via setHeaders is inserted without escaping into a <meta http-equiv="cache-control"> tag. An attacker who can influence that untrusted value at prerender time can break out of the content attribute and inject HTML or JavaScript that executes when users visit the page.

SvelteKit (@sveltejs/kit) before 3.0.0 contains an open redirect vulnerability in enhanced form actions (use:enhance) on routes accepting paths beginning with a double slash. Attackers can craft action paths starting with // that become protocol-relative URLs, causing non-redirect form results to navigate victims to attacker-controlled sites.

ArcadeDB before 26.10.1 contains a remote code execution vulnerability that allows authenticated users, including read-only reader role holders, to execute Groovy code because GremlinQueryEngine.command() lacks scripting authorization checks. Attackers can submit Gremlin commands to the POST /api/v1/command/{database} endpoint when the Groovy engine is enabled to run OS commands as the server process user.

ArcadeDB from 26.2.1 before 26.10.1 contains a missing authorization vulnerability in the Bolt protocol handler that lets authenticated users read other databases' schema metadata. Attackers with credentials for one database can set the db field in RUN or BEGIN messages and call db.labels() or SHOW INDEXES to enumerate unauthorized schemas.

ArcadeDB from 26.2.1 before 26.10.1 contains a missing authorization vulnerability in the Bolt protocol handler that allows authenticated users to enumerate all database names. Attackers with credentials for any single database can issue a SHOW DATABASES query over the Bolt port to reveal unauthorized database names, exposing tenant or project identifiers.

ArcadeDB from 26.8.1 before 26.10.1 contains an authorization bypass vulnerability that allows read-only users to modify edge type lightweight and unique schema flags without UPDATE_SCHEMA permission. Attackers can send a bare ALTER TYPE edgeType WITH lightweight = true command over the HTTP, gRPC, or Bolt command API to persistently alter edge storage declarations.

vLLM from 0.7.3 before 0.31.0 contains an uncontrolled resource consumption vulnerability that allows remote clients to control multimodal processor parameters by supplying per-request mm_processor_kwargs. Attackers can set large image size, patch count, crop count, or frame count values in Isaac, InternVL, H2OVL, and other processors to exhaust memory and terminate the shared server.

vLLM before 0.31.0 contains a cache aliasing vulnerability that allows authenticated attackers to collide shared cache keys by supplying caller-controlled values such as EXIF ImageID or cache_salt. Attackers can set a UUID EXIF ImageID to receive another request's cached processed media, or match cache_salt to a LoRA name to reuse first-block KV state.

vLLM from 0.7.3 before 0.31.0 forwards the request-supplied mm_processor_kwargs.code_revision to Transformers AutoProcessor.from_pretrained, letting clients select which revision of a model's dynamic processor code is imported when trust_remote_code is enabled. An attacker controlling a revision in the served model repository can send a multimodal request to the unauthenticated /tokenize endpoint to execute arbitrary Python in the vLLM API process.

vLLM after 0.24.0 and before 0.31.0 contains a memory exhaustion vulnerability in MOSS-Audio model serving that caches a processor for every distinct request-controlled mm_processor_kwargs value in an unbounded dictionary. Unauthenticated attackers can send distinct or oversized mel_config values to the /tokenize endpoint, which bypasses --api-key, to exhaust host memory and crash the API process.

vLLM before 0.31.0 skips the min_tokens <= max_tokens check for /inference/v1/generate requests with a null max_tokens, so the EngineCore input thread later dies on an uncaught VLLMValidationError while /health still returns 200. Unauthenticated remote attackers can send one request with an oversized min_tokens to hang all subsequent generation requests until manual restart.

vLLM before 0.31.0 uses a client-supplied multimodal uuid verbatim as cache identity with no consistency check on cache hits, allowing engine crashes. Unauthenticated attackers can desynchronize the P0/P1 processor caches to trigger a fatal token-placeholder mismatch, killing the entire serving instance until restarted.

WWBN AVideo before 24.0 contains a cross-site request forgery vulnerability in legacy endpoints like playlistStatus.php that bypass the .json.php-only autoCSRFGuard() check. Attackers can lure logged-in users to a page with an auto-submitting form to make private playlists public, remove playlist videos, or forge video suggestions.

vLLM before 0.31.0 contains a cross-request mask leak in InputBatch.condense() that allows remote attackers to constrain other clients' outputs by leaving stale allowed_token_ids rows. Attackers can submit concurrent constrained generate requests, including via unauthenticated /invocations, so recycled batch slots apply their token allowlist to victims' unrestricted requests.

FreeRDP from 2.0.0 before 3.32.0 contains an improper certificate validation vulnerability in its proxy that accepts untrusted target TLS certificates when no verification module is configured. Network-positioned attackers can intercept the proxy's outbound connection and present a self-signed, wrong-hostname certificate to impersonate the RDP target and receive proxied session data.

FreeRDP before 3.32.1 contains a heap-based buffer overflow in the server-side rdpsnd channel because an integer wraparound in rdpsnd_server_select_format() DVI_ADPCM block-alignment arithmetic bypasses validation. A malicious RDP client can send two SNDC_FORMATS PDUs with an nBlockAlign too small for nChannels, causing an unbounded heap write during server audio playback, potentially enabling code execution.

FreeRDP 3.0.0 before 3.32.0 contains a null-pointer dereference in the smartcard emulation backend that accepts a null per-reader name in SCardGetStatusChange requests. A malicious RDP server can send a crafted reader-state entry with a null szReader, causing strcmp or _wcscmp to crash the client process.

FreeRDP before 3.32.1 contains a heap out-of-bounds read vulnerability in the Android client that allows malicious RDP servers to read beyond surface buffers by supplying unvalidated mappedWidth and mappedHeight values. Attackers can send a crafted RDPGFX_MAP_SURFACE_TO_WINDOW_PDU with oversized dimensions, causing android_UpdateWindowFromSurface to copy heap memory beyond the allocation, leading to crashes or memory disclosure.

FreeRDP before 3.32.1 contains a heap-based out-of-bounds read in WinPR's clipboard PNG-to-CF_DIB synthesis because winpr_read_png_from_buffer() allocates a bit-packed buffer for PNGs with bit depth below 8, while winpr_bitmap_write_buffer() copies rows assuming one byte per pixel. A malicious RDP server can send a crafted low-bit-depth PNG clipboard payload that, when pasted by the victim, discloses megabytes of heap memory.

FreeRDP 3.32.0 contains a use-after-free vulnerability in the drdynvc channel that frees a pool-owned stream with the owned-stream deallocator when totalLength is smaller than the chunk size. A malicious RDP server can send a single well-formed Virtual Channel PDU to trigger the free and crash the client during teardown.

FreeRDP before 3.32.1 on Windows contains a heap out-of-bounds read in client_cli_present_gateway_message that passes a byte count as wide-character printf precision. A malicious RD Gateway can send pre-authentication consent or service messages, causing the client to read twice the buffer size, leaking heap memory or crashing.

Astral uv before 0.8.22 contains a path traversal vulnerability in source distribution (sdist) tar extraction that allows a specially crafted sequence of symlinks to redirect file writes outside the intended extraction prefix. Attackers can publish a malicious sdist that, when installed by a victim, writes arbitrary files to filesystem locations outside the installation prefix.

Vyper from 0.1.0b4 before 0.3.0 contains a memory corruption vulnerability caused by an incorrect stack tip pointer when internal function calls are performed inside arrays. Contracts placing internal calls in nested array elements, external call arguments, struct literals, or raw_log topics can have memory corrupted, producing incorrect contract behavior.

Vyper before 0.2.9 deploys forwarder proxies through the built-in create_forwarder_to function that report a fixed 4096-byte RETURNDATASIZE rather than the actual return data size. Calls through these proxies can yield corrupted data when a function returns more than 4096 bytes without return data sanitation, and fail strict return-size checks such as SafeERC20.safeTransfer.

Vyper from 0.2.13 before 0.2.15 allocates storage slots for @nonreentrant reentrancy locks at the same locations as contract storage variables. When a function using @nonreentrant is called, setting the lock overwrites the overlapping storage variable, corrupting contract state and breaking the contract's intended logic.

Vyper before 0.3.1 lacks a uint8 type, allowing interface return values declared as uint8, such as ERC20.decimals(), to be stored in uint256 variables without bounds checking. Malicious contracts can return values greater than 255 to manipulate or bypass contract logic that relies on these values.

Vyper from 0.1.0b10 before 0.2.3 generates incorrect code for a return statement inside a for loop in an internal function called two or more internal calls deep, producing an invalid jump destination (stack underflow). Affected contracts revert such calls unnecessarily, which in limited circumstances could enable denial of service against public contracts.

Vyper before 0.2.6 contains a call stack corruption vulnerability that causes incorrect function outputs when complex types with non-base members are passed as arguments. Contracts passing multi-dimensional arrays or structs to internal or external functions receive corrupted values because the compiler assumed each subtype size is 32.

Vyper from 0.1.0b4 before 0.3.0 contains a memory corruption vulnerability caused by an incorrect stack tip pointer when internal function calls appear inside tuples or nested calls. Contracts using such calls as tuple elements, call arguments, or builtin arguments like concat or ecrecover can return corrupted values or pass wrong arguments to external calls.

A vulnerability has been found in R6410418 Jackrong-llm-finetuning-guide up to ef2b17f2798cd18cd85375080c35a58397ad0d09. This vulnerability affects the function extract_mtp_heads of the file qwen-mtp-gguf/scripts/qwen_mtp_gguf_pipeline.py of the component MTP weight_map Handler. The manipulation of the argument shard_name leads to path traversal. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. This product is using a rolling release to provide continious delivery. Therefore, no version details for affected nor updated releases are available. The project was informed of the problem early through an issue report but has not responded yet.

A flaw has been found in R6410418 Jackrong-llm-finetuning-guide up to ef2b17f2798cd18cd85375080c35a58397ad0d09. This affects the function validate_indexed_tensors of the file qwen-mtp-gguf/scripts/qwen_mtp_gguf_pipeline.py. Executing a manipulation of the argument weight_map can lead to path traversal. The attack may be performed from remote. The exploit has been published and may be used. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. The project was informed of the problem early through an issue report but has not responded yet.

A vulnerability has been found in D-Link DHP-W610AV 1.02EUb03. The impacted element is the function login_prepare_hnap of the file etc/defnodes/defaultvalue.xml of the component HNAP Login. The manipulation of the argument Password leads to empty password in configuration file. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

storage/pkg/archive.ApplyLayer and ApplyUncompressedLayer may, when processing corrupt or malicious inputs, leak a file descriptor; unbounded repeated calls can exhaust the process’ file descriptor limit

A flaw in Node.js DNS resolution allows hostnames containing a NUL byte to be silently truncated by the dns.resolve*() functions and dns.reverse(). This is an incomplete fix of CVE-2026-48930, which only covered dns.lookup() and the net/tls host options. Because the name is passed to c-ares as a C string, resolving attacker.example\0.trusted.example queries attacker.example and returns its records without any error. Applications that validate a hostname, for example against a domain allowlist, and then resolve it with dns.resolve*() can act on records for a different name than the one they validated. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

A race condition in Epiphany allows a malicious website to bypass the TLS/SSL certificate warning page. Epiphany registers the main-world script message handler "tlsErrorPage" so its internal TLS error page can implement "Accept Risk and Proceed". The handler was registered immediately before loading the error page, leaving a brief window where the previously loaded untrusted origin could still call window.webkit.messageHandlers.tlsErrorPage.postMessage(...). The only authorization check compares a numeric WebKit page id that increments predictably; an attacker can burst-guess ids and approve a certificate exception with no user click. If a victim visits malicious site A that redirects to site B with an invalid certificate, site A can, for a few milliseconds, disable TLS certificate error warnings for host B until Epiphany is restarted, enabling man-in-the-middle or site spoofing for that host. Upstream report: https://gitlab.gnome.org/GNOME/epiphany/-/work_items/2978 Proof of concept: https://beford.net/poc/ssl_poc.html Fix: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/2245 (register handlers on LOAD_COMMITTED). No fixed release tagged yet; reporter and maintainer describe all current versions as affected. Maintainer notes the risky registration timing dates to commit 1da1caed (Epiphany 45.x era); before that the handlers were always registered and similarly reachable from web content.

A heap use-after-free in the gf_filter_pid_send_event_downstream function (/filter_core/filter_pid.c) of GPAC Project/MP4Box before 2.5 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.

A heap use-after-free in the gf_odf_ac4_cfg_clean_list function (/odf/descriptors.c) of GPAC Project/MP4Box before 2.5 allows attackers to cause a Denial of Service (DoS) via supplying a crafted AC4 file.

A heap use-after-free in the dasher_flush_segment function (/filters/dasher.c) of GPAC Project/MP4Box before 2.5 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.

A NULL pointer dereference in the dasher_insert_timeline_entry function (/filters/dasher.c) of GPAC Project/MP4Box before 2.5 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.

In the Linux kernel, the following vulnerability has been resolved: bpf: Infer zext_dst based on static register liveness analysis As reported in the thread [1], the verifier's 32-bit operations zero extension logic is broken. This logic is responsible for correct semantics of 32-bit operations on s390 architecture. According to BPF semantics, operation `w1 += 1` is supposed to zero extend the upper half of the register `r1`. On s390 the JIT relies on the verifier emitting explicit zero extension before such operations. The verifier attempts to minimize the amount of zero extensions inserted by tracking whether upper halves of the 64-bit registers are ever used. Previously such tracking worked as follows: - bpf_reg_state->subreg_def field was set by do_check_insn() for each operation defining lower but not the upper halves of the register. - Whenever an operation reading the whole register was verified, the verifier checked register's subreg_def and set bpf_insn_aux_data->zext_dst flag as true via a call to mark_insn_zext() function. - After the verification was complete, a special pass bpf_opt_subreg_zext_lo32_rnd_hi32() extended 32-bit operations with bpf_insn_aux_data->zext_dst set as true by adding explicit zero extension. Note that the logic above relies on bpf_reg_state->subreg_def, which is a property of a current verifier state. Before the commit [2] two additional steps happened: - The verifier tracked upper and lower register halves' liveness as flags REG_LIVE_READ{32,64} in bpf_reg_state->live. - The function propagate_liveness() called mark_insn_zext() in order to transfer the knowledge about which registers have their upper halves alive (and thus might require zero extension). The commit [2] removed the two steps described above, hence making possible a situation like below: - The register's upper half is set and is used on some verification path P1 and the register happens not to be marked as precise. - The checkpoint C is created while processing some instruction between register initialization and usage. - On some other verification path P2 the register's upper half is not initialized and that path ends hitting the checkpoint C. - In such a case the register's initialization on path P2 would lack zext_dst mark, making it possible for the program to inject an arbitrary value in the register's upper half. This commit replaces subreg_def based logic with computing zext_dst statically, as a part of the bpf_compute_live_registers() analysis: - The analysis now tracks usage of upper and lower halves of the registers separately. - If some instruction defines a 32-bit subregister, but not the whole register, *and* the upper half of the register is alive after that instruction, the instruction is marked as zext_dst. There is one notable drop in precision: whenever a BPF subprogram is called, all 64 bits of parameter registers are presumed to be used. The assumption is that such a drop in precision would not inflict a noticeable performance penalty. [1] https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/ [2] commit 107e16979905 ("bpf: disable and remove registers chain based liveness")

A flaw in Node.js TLS hostname verification can cause a server certificate to be validated against a different IP address than the one the client connected to, when the host is a non-canonical IPv4 literal with a leading zero, such as `0127.0.0.1`. `tls.checkServerIdentity()` normalizes the host following the WHATWG URL rules, which read a leading-zero octet as octal (`0127.0.0.1` becomes `87.0.0.1`), while the connection is made through the operating system resolver, which on some platforms such as macOS reads it as decimal (`127.0.0.1`). A server at the connected address can then be authenticated with a certificate issued for another IP address. This vulnerability affects Node.js **26.x**, **24.x**, and **22.x**.

A flaw in Node.js TLS hostname verification allows a certificate without a matching IP address SAN to authenticate a connection to an IPv4 address when the host is written with non-ASCII characters, such as fullwidth digits (`１２７.0.0.1`). `tls.checkServerIdentity()` did not recognize such hosts as IP addresses, even though they normalize and resolve to a regular IPv4 address, and matched them against the certificate DNS names and Common Name instead. A certificate containing `DNS:127.0.0.1` or `DNS:*.0.0.1` could therefore be accepted for an IP endpoint it was not issued for. This is a regression introduced after the fix for CVE-2026-48618. This vulnerability affects Node.js **26.x** and **24.x**.

An out-of-bounds read in gf_odf_ac4_cfg_dsi_v1 (/odf/descriptors.c) in GPAC Project/MP4Box before v26.07.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted AC4 file.

A NULL pointer dereference in the gf_ac4_presentation_ch_mode function (/media_tools/av_parsers.c) of GPAC Project/MP4Box before 2.5 allows attackers to cause a Denial of Service (DoS) via supplying a crafted AC4 file.

A BIND resolver that is configured with both a "redirect" zone and "qname-minimization strict" may abort with an assertion failure while processing the redirect. This issue affects BIND 9 versions 9.16.0 through 9.18.50, 9.20.0 through 9.20.29, 9.21.0 through 9.21.26, 9.16.8-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.29-S1.

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Copy BASE if service data matches EIR_BAA_SERVICE_UUID Copy the content of a Periodic Advertisement Report to BASE only if the service UUID is Basic Audio Announcement Service UUID.

A segmentation violation in the gf_isom_get_esd function (/isomedia/isom_read.c) of GPAC Project/MP4Box before 2.5 allows attackers to cause a Denial of Service (DoS) via supplying a crafted XML file.

A stack overflow in the gf_bifs_dec_node function (/bifs/field_decode.c) of GPAC Project/MP4Box before 2.5 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.

A segmentation violation in the check_media_profile function (/mp4box/mp4box.c) of GPAC Project/MP4Box before 2.5 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.

A segmentation violation in the GetESD function (/isomedia/track.c) of GPAC Project/MP4Box before 2.5 allows attackers to cause a Denial of Service (DoS) via supplying a crafted MP4 file.